- ベストアンサー
セッションとGCに付いての検証
- セッションとGCについての検証を行っています。セッションを1時間に1200本3秒毎にWSHを利用して張っています。
- GCはスクリプトの実行終了時に処理が走ると思われます。マイクロタイムのdiffはセッションを純粋に張った時間しか求められません。
- GCのトラフィックを図るための手段はないか検討しています。環境はphp4.3とLinuxです。
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
>上記のようなケースの場合で、session.gc_probabilityを100%にすると、 >G.Cが行われるのは、スタートしてから、30分後になって、G.C対象は始めの10分に張った >セッションと言うことになりますよね？ 100%だと実際は毎回、gcがcallされますが、セッションファイルの修正時刻と比較して削除されず、見かけ上は変化無しと言うことです。 ソースを追う限り、削除が遅れるケースはあっても早まるケースを想定できません。 (ext/session/mod_files.c:ps_files_cleanup_dir()) お役にたてず申し訳ない。
その他の回答 (2)
GCは何時開始されるかは、 ソースを読めばわかります。 該当する部分は、 php-4.x.x/ext/session/session.c の中の、 php_sesion_start()関数です。 なお、ドキュメントに記載があるかと言うと 十分ではありませんが、GCの発生率を決定付ける パラメータとしての記載ならあります。 php.iniのディレクティブ一覧が該当します。
補足
有難うございます。 ソースコードを読んでみました。 また、マンモス本にもセッションが開始されたときにガーベッジコレクション（以下G.C）が 開始されてその確率はsession.gc_probabilityが決めるとかいてありました。 有難うございます。 ついでに、もうひとつ聞いていいですか？ ・セッションのライフタイムを30分 ・セッションを2秒に一回発生させてそれを40分間セッションを張りつづける 上記のようなケースの場合で、session.gc_probabilityを100%にすると、 G.Cが行われるのは、スタートしてから、30分後になって、G.C対象は始めの10分に張った セッションと言うことになりますよね？ となると、10間に張るセッション数は300件なので テスト終了後のセッションファイルは 40分（1200本）-10分（300本）=900本 になるはずなんですが、なぜか、残った、セッションファイル数は800本ぐらいですし、 G.Cが発生したのも、正確に30分後ではありませんでした、（2分ぐらい早かった） もし、このような現象に対して、思い当たる節があれば教えていただきたいのですが・・・ 因みにこの現象はsession.gc_probabilityを100%,75%,50%,25%,1%にしても見受けられました。 ただし、1%の場合のみ、大体実行から、30分後にG.Cが発生してくれました。 宜しくお願い致します
GCは、garbage collectinのことですよね? PHPのgcは、どのタイミングで実施されるかと言えば、 明示的なセッションの開始session_start()を呼ぶか 暗黙のセッション開始session_register()が呼ばれた 際に php.iniで設定してある session.gc_probability = 1 session.gc_dividend = 1000 により決定されます。 この場合、gc_probability/gc_dividendの1000分の1 (0.1%)の確率で、実行されます。 単純に計るのではなく、複数のRequestの時間を loggingし、まったくgcを行わなかった場合との 比較をとらなければ、gcによる負荷は計測出来ない でしょう。 トラフィックは負荷の間違いですよね。
補足
回答有難うございます。 senberoさんは、ガーベッジコレクション（以下GC）がセッションの開始直後にphp.ini の設定により確率が決定されて行われるとありますが、それは、ドキュメント に明示的に記述されていたのでしょうか？私の調査不足かもしれませんが、 そのようなことが記述されていなかったような気がします。 信用してはいけないと思いますが、海外のサイトの掲示板を見ていて、 GCは、スクリプトの実行終了後と記述されてあった気がします・・・。 宜しくお願い致します。 ＞トラフィックは負荷の間違いですよね。 おっしゃる通りです。申し訳ありません。
補足
>100%だと実際は毎回、gcがcallされますが、セッションファイルの修正時刻 >と比較して削除されず、見かけ上は変化無しと言うことです おっしゃるとおりです。言葉足らずで変な誤解を与えてしまいました。 >ソースを追う限り、削除が遅れるケースはあっても早まるケースを想定できません。 そうですか・・・・ ちょっと、テスト方法を再度見直してみます。 いろいろ有難うございました。