備忘録（PHP): 2008年3月アーカイブ

先日、PHP処理でのタイムアウトについて書きましたが、捕捉です。
タイムアウト処理うんぬんの前に、PHP側及びApache側での設定で強制的にタイムアウトになります。
【php.ini】
max_execution_time = 300
// ３００秒でタイムアウト
【PHP】
set_time_limit(300);
//３００秒でタイムアウト
【httpd.conf】
Timeout 300
//３００秒でタイムアウト
KeepAliveTImeout 300
//３００秒でタイムアウト

上記の設定は０にすればタイムアウトしない設定になります。
ちなみに、わたしの場合上記設定でもダメな場合がありました。
構成としては拠点Bからサーバ設置場所Aという状態で、拠点Bから拠点Aへのアクセスの際にどんなに対策をしてもタイムアウトになっていました。
原因は、ファイアーウォールでした。
ファイヤーウォール側でセッションのタイムアウトを設定していてアウトでした。
参考までに。

PHPでWEBアプリを開発しているとある壁にぶち当たりました。
それはWEBブラウザのタイムアウト制限です。
データベースと連携している性質上データの件数が肥大するに伴い処理時間が
超過していきます。
データベース構築時点での設計ミスもありますが、やはり限界があるのではないでしょうか？

最初は、php.iniやApacheの設定をいじっていましたが頭打ちをするところまできました。
いろいろと調べてみると、WEBサーバからのデータが一定時間ないとWEBブラウザは接続が切断されたものとして判断してしまうようです。
だったら、細かく途中経過のデータを送ってあげればいいのでは？
と単純な考えでソースの埋め込み開始。
//出力バッファOFF
ob_end_clean();
 
// IEはこれがいるらしいので
echo str_pad('',256);
flush();

// あとは要所要所に途中経過コメントを出力
echo "コメント";
flush();

これで、数時間にわたる処理がとりあえず実行できるようになりました。

数時間に渡る処理自体が問題との声がありそうですが・・・・。

とあるWEBシステムで「ページが表示できない」という表示になってしまうというトラブルがありました。

始めはApacheが落ちた？と思っていましたが正常に稼動中。

サーバのメモリ？それも異常がない。

毎回ではなくたまになるらしいのですが、原因がさっぱり。

とりあえずApacheのアクセスログとエラーログを確認してみることに。

エラーログに次のエラーがたまに記載されていました。

FATAL:  emalloc():  Unable to allocate xx bytes

調べてみるとメモリの確保に失敗しているらしいのですが、このエラーが出るときに「ページが表示できません」となるみたいです。

処理を見直してみても、メモリを浪費しているような内容でもないし。

暫定的にphp.iniのmemory_limitを拡張して設定で回避。

ＰＨＰで処理をしているときに、データ量がある一定を超えたあたりから極端に処理速度が遅くなってきました。

処理の流れとしては、

１．ＭｙＳＱＬよりデータの抽出

２．抽出したデータを全て配列ａに格納

３．配列ａに対して処理をして別の配列ｂに格納

という処理です。

データ量が数万、数十万件あたりまでは問題なかったのですが、百万件近くになったときに著しく処理が遅くなってきました。

まず、各箇所で処理時間を計測してみました。

すると、３の処理をしているときに徐々に処理時間が遅くなってくることが分かりました。

？？と思っていろいろと検討してみた結果、まず１のMySQLの結果リソースの解放をする。

その次の３で配列aについても解放をする。

データが少ないときはとりあえず乗り切れているんでしょうけど、データが肥大化するに伴い今回のようなことが発生することが分かりました。

恐らく、「そんなことは設計段階で把握しておかないと」って怒られそうですが、また一つ勉強になりました。

「使わないものは、片づけをする」←人として基本ですよね。