私は Windows Server 2016 で IIS を使用しており、ほぼ同一の 2 台のサーバーで MySQL と PHP を使用しています。最近、2 台のサーバーのうちの 1 台で速度低下が発生していることに気づきましたが、これはサイトがスクリプトの複数のインスタンスを同時に実行しようとしたときにのみ発生します。どうやら、それらは互いにスタックしているようです。
完璧な例として、私の検索ページがあります。ユーザーが検索クエリを入力すると、最後のキー押下から少なくとも 200 ミリ秒の遅延がある限り、キーアップ (2 番目の文字の後) ごとに検索が実行されます。したがって、速く入力すると最後に 1 回の検索しか実行されませんが、遅い入力者 (キー押下の間に 200 ミリ秒以上待つ人) の場合は、検索結果への複数の呼び出しがトリガーされます。このスクリーンショットを参照してください。
悪いサーバー
保留中のリクエストがすべてあることに注目してください。このスクリーンショットでは、最初のリクエストが 19.08 秒で終了しました。明らかに長すぎます。すべてが完了するまでに、単純な結果セットを返すのに 15 秒以上かかります。
悪いサーバー
これらのクエリは、MySQL Workbench で実行した場合、また、この問題が発生していない他のサーバーで実行した場合も、ほんの一瞬しかかからないことに注意してください。このスクリーンショット (正常なサーバーから) では、まったく同じ検索が 4 分の 1 秒で返されます。
良いサーバー
どうやら (不良サーバーでは) 何らかの理由で同時に実行できないようです。1 つの検索だけを実行すると (1 つの検索だけをトリガーできるほど速く入力すると) すぐに結果が返されますが、このように複数実行すると、交通渋滞のようにすべてが停止します。原因は何でしょうか?
次のスクリーンショットは、不良サーバー上で 1 回だけ検索を実行した場合の結果を示しています。ご覧のとおり、非常に高速に結果が返されます。つまり、問題は同じスクリプトを複数同時に実行した場合にのみ発生します。
悪いサーバー
最近、不良サーバーにいくつか変更を加えましたが、私が覚えている限りでは、より大きなファイルのアップロードを可能にする変更のみ加えました。
- PHPではpost_max_size = 500Mに増やしました
- PHPではupload_max_filesizeを500Mに増やしました
- IISではUploadReadAheadSizeを49152000に増やしました
- IISでは、コンテンツの最大許容長を300000000に増やしました。
このサーバーに、私が覚えていない他の変更を加えた可能性もあります。
一時的な修正
検索時にキーを押す間隔を長くすることでこの問題を軽減できます。実際にこれを実行したところ、遅延が 800 ミリ秒に長くなり、入力が遅い人でもこの問題に気付かなくなりました。しかし、これは一時的な解決策に過ぎず、サイトの他の領域にも影響する根本的な問題には対処していません。
私が試したこと
これまでのところ、IIS 構成、MySQL 構成 (my.ini)、PHP 構成 (php.ini) は、両方のサーバーで重要な点 (少なくとも私にとって明らかな点) においてすべて同一であることを確認しました。また、この検索で実行している選択ステートメントを MySQL Workbench で実行すると、両方のサーバーで同様に実行されることも確認しました。この問題が発生しているのは、Web アプリのみです。
念のため、大きなファイルのアップロード用に IIS に加えた 2 つの変更を一時的に元に戻しましたが、何も変わりませんでした。
また、LeanSentry をダウンロードしてインストールしましたが、これは 1 日に 1 回か 2 回、サイトでブロックされたリクエストが検出されたことを警告します。ここで表示されている内容はまさにそれだと思いますが、残念ながら LeanSentry は PHP ではなく ASP ページの問題の原因を正確に特定できます。つまり、基本的に問題があることを確認するだけで、それ以上の支援は提供できません。
その他の症状
複数のレポートを同時に開くと、同様の問題が発生します。1 つのレポートの読み込みが完了するまで待ってから次のレポートを開くと、すべてのレポートがすぐに読み込まれますが、アプリで複数のレポートを一度に開くように強制すると、すべてのレポートが停止します。
このボトルネックの問題の原因は何でしょうか?
答え1
ここで問題が起きているのは IIS サーバーではないと思います。検索するたびにコード内で新しい呼び出しを要求しており、PHP スクリプト内の何かに時間がかかっているようです。
新しいリクエストを送信するたびに、新しい PHP インスタンスがブロックされ、PHP のインスタンスが不足するとクラッシュします。
検索 PHP ファイル内で何を行っているかは分かりませんが、検索のために SQL サーバーか何かを呼び出していると思います。コード内で検索クエリをコメントアウトして、同じテストを実行してみませんか?
今のところ、私ができる限りの推測をしているだけですが、SQL データベースで正規表現または類似の関数を使用しているようです。行数が多いと呼び出しが非常に遅くなり、頻繁にハングアップする原因になります。
しかし、またしても私があなたに行うように指示したテストの結果を知るのが遅すぎると思います。
答え2
結局、HTML レンダリングがハングアップの原因となっていました。検索結果が長い場合、ブラウザがすべての HTML をレンダリングするのに長い時間がかかり、その間、次のリクエストを処理できませんでした。
検索結果を 50 行に制限することでこの問題を解決しました。これで HTML がほぼ瞬時にレンダリングされ、次のリクエストが実行できるようになりました。つまり、リクエストをブロックしていたのは IIS ではなく、ブラウザーでした。