[php] nginx php-fpm「セッションロック」の問題

nginx + php-fpm 環境展開の記事:

http://blog.s135.com/nginx_php_v6/

php-fpm に関する Baidu 百科事典の紹介:

http://baike.baidu .com /view/4168033.htm

実際にこの環境を使用しているときに、著者が奇妙な問題に遭遇しました。 問題の具体的な説明は次のとおりです。

同時にブラウザが Web サイトから php ページをリクエストすると、それが起動します。ページは、実行を開始する前に、前のページが応答を取得するまで待つ必要があります。

この問題は、Web サイト上の特定のページのバックエンド インターフェイスに問題があり、タイムアウト メカニズムが設定されていなかったため、ページの応答が非常に遅くなったために発見されました。 このページを待機している間は、このページが戻るまで他の Web サイトのページを開くことはできません。

調査の結果、Web サイトは独自の mvc フレームワークを使用しており、フレームワークのアクションが実行される前に session_start() がデフォルトで実行されるため、問題はセッションにロックされていました。 以前はApache上でWebサイトを展開していたため問題はなかったが、危険性も潜んでいた。この問題は、企業の Web サーバー環境が nginx 環境に移行されたときに発生するはずです。

具体的な理由は明らかではありませんが、確かなことは、セッションと nginx+php-fpm 環境の組み合わせで問題が発生するということです (実験により既に判明しています)。

解決策は、フレームワークを変更し、デフォルトで開かれているセッションを閉じ、SESSION を必要とするアクション クラスのコンストラクターでセッションを開くことです。ただし、そのようなページが並行している場合でも、「セッション」は残ります。 lock" [著者 専門的な名前が思いつきません。この問題の原因を知っている方がいらっしゃいましたら、アドバイスをお願いします。ただし、この種のページは、当社の Web サイトのほんの一部に過ぎません。

これは一時的な解決策です。

Zhang Yan の記事で紹介されている nginx+php-fpm 環境のパフォーマンスは非常に優れていますが、比較的新しいソリューションであるため、従来の Apache + php-cgi のソリューションと比較すると、いくつかの小さな問題がある可能性があります。

この記事があなたのお役に立てば幸いです。