普遍的な問題：約25秒の無活動後の最初の要求は、後続の要求（約1/10秒）よりも常に遅い（約1秒）

Question

WordPressを使い始めてから気づいたことです。 WPインストールが私の共有ホスティングアカウントにあるか（他のプロバイダを試していないか）、またはローカルのLAMPセットアップにあるかどうかは関係ないという意味で、これは普遍的な問題です。

1つの投稿、1つのページ、およびdefauktテーマを備えた真新しい、きれいなWordPress - または何百もの投稿、重いテーマおよびたくさんのプラグインを持つ古いWP ...は違いを生じません。

現在絶叫の速いローカル仮想マシン（高速SSD、CentOS 6.2、Softaculous、標準のApacheおよびMySQLを搭載したi7-3930k、他では何も動作していません）で作業しているシナリオは次のようになります。

初回のロード、フロントエンドまたはバックエンドのページ：約1秒の遅れ。
同じまたは任意の他のページ（フロントエンドまたはバックエンド）をその後２５秒以内にロードする：実質的に瞬間的な応答。
25秒待って、リロードし、1秒の遅延が戻ってきた

この25秒の間隔は、私の忍耐の範囲内で私ができた最も良い測定についてです、しかしそれはかなり良い正確さと再現性を得ました。

さらなる観察：

同じＬＡＭＰ上の異なる設備は互いに「分離」されている、すなわち１つのサイトをロードしてから別のサイトをロードしても、後者を速くロードすることはできない。
私の現在の「解決策」は20秒ごとに自分自身をリロードするダミーページでタブを開くことです

他の誰かがこの問題に気付きましたか？どうなり得るか？私はこのことを追跡するのを助けるためにあらゆるそして詳細を提供して嬉しいです。皆さん、ありがとうございました！

EAMann · Answer

何が起こっているかを正確に確認するためにあなたの箱を見ないで、遅さのいくつかの潜在的な道はここにあります：

潜在的な原因

アパッチ

Apacheは通常単一のhttpdプロセスが常にバックグラウンドで実行されるように構成されています。リクエストがネットワーク経由で届くと、リクエストを処理するために新しいhttpdプロセスを起動します。要求が終了すると、新しいhttpdプロセスはしばらく待機し、マスタープロセスは追加の要求があればそこに渡します。

一定の非アクティブ期間の後、子プロセスはシャットダウンします。つまり、マスタープロセスは次の要求が来たときにメモリを再割り当てし、新しいプロセスを起動する必要があります。

「しばらく」や「一定の期間」などの用語を使用します。これらはすべてサーバーで構成可能なオプションだからです。 StartServersディレクティブを使用して、座っている子プロセスの数を管理できます。また、MinSpareThreadsおよびMaxSpareThreadsディレクティブを検討することも検討してください。これらのディレクティブは、「要求の急増を処理するアイドルスレッドの数」を管理します。

これらのディレクティブの詳細は、マニュアル内で入手できます。

PHP

Apacheと同様、PHPは、サーバーへのインストール方法に応じて、さまざまな方法で構成できます。 Apacheで最も人気のある2つは、CGIスクリプトとしてとApacheモジュールとしてです。

CGIスクリプトとして、PHPは別のプロセスとして実行されます。 Apacheのように、通常はリクエストを処理するために1つまたは2つのインスタンスを使用しますが、一定時間非アクティブになるとシステムのメモリを解放するためにオフになります。

Apacheモジュールとして、PHPはApache自体にコンパイルされるため、httpdの無料インスタンスがある場合は常にalso PHPハンドラーがありますセットアップ。しかし、上記のApacheシステムで説明したように、これらの余分なインスタンスは、Apacheを設定してアクティブにしない限り、表示されなくなります。

Mod_php vs PHP as CGI here の詳細情報があります。

MySQL

ただし、ここでの最大の問題はMySQLです。他のほとんどのデータベースと同様に、MySQLはデータをディスクに保存しますが、クエリの結果をメモリ内キャッシュに保持して、検索を少し高速化します。表示される可能性が高いのは、MySQLが約25秒後に離れてしまい、データを再度必要としないと判断した結果です。

基本的なクエリのキャッシュは、サーバーがデータの永続化にSSDを使用しているサイトであっても、トラフィックの多いサイトでは信じられないほど効率的です。残念ながら、キャッシュが停止する（または、相互に構成されたタイムアウトしきい値に達する）という問題が発生している可能性があり、その後の要求ではファイルシステムからデータを再フェッチする必要があります。

クエリキャッシュの詳細については、 MySQLドキュメントをご覧ください。

緩和

サーバー構成

システム管理者でない場合は、ボックスとTweakの設定を確認するために数時間契約することをお勧めします。新しいスタックをシェルフからインストールすることは、通常、誰にとっても問題ありません（そして、バニラのキャッシュされていないサーバーでの〜1秒のページ読み込みは恥ずべきことではありません）。ただし、デフォルト構成は、万能のシナリオではありません。ハードウェアを最大限に活用するためにスタックを構成する専門家を手元に置いておくことは、十分に費用がかかります。

フロントエンドキャッシング

ページが変更されていない場合は、フロントエンドキャッシュを使用して、レンダリングされたページを保存し、それらをすばやく提供できます。 Batcache 、たとえば、サーバー上のMemcachedを使用してレンダリングされたページを保存しますin-memory。これは、後続のリクエストが、WordPressを使用して、データベースからデータを再取得し、構築し直します。

WP Super Cache は同様の処理を行いますが、代わりにレンダリングされたページを静的なHTMLファイルとして保存し、訪問者がWordPressを解析する代わりにそれを取得します。ページロードのボトルネックは、SSDの速度+ホストが提供する帯域幅になります。