ミスター・タイム・トゥ・ファースト・バイトの奇妙な事件

私はに基づいてLinode 1024 VPSでウェブサーバーを持っています

• Ubuntu 11.10
• Nginx 1.0.5
• PHP 5.3.6（PHP-FPM、APCを使用）
• ワニス3.0.2

また、WordPress 3.3.1に基づいたブログもいくつかあります。それらの1つは、サーバーをテストするための既定の構成、テーマ、および "Hello World"投稿を含む単純なブログです。もう1つは、ほぼ1万件の投稿と1万件以上のコメントを含む、他のサーバーから複製されたブログです。このブログには、1日あたり5kのユニークユーザーがいます。

サーバーは、テストブログの abテストで良い数値を出しますが、クローンブログと同じテストを行うことは不可能です：abテストはサーバーのロードが多すぎるため、プロセスを停止する必要があります。この本当に悪い結果。

htopは、通常の動作では「通常」の負荷も示しますが、abテスト中は通常の大きな負荷を示します。

別の奇妙なことが起こっています（私にとって最も重要なことです）：最初のバイトまでの時間が非常に長いですが、その後、サイトの読み込みが非常に速くなります。これはtools.pingdom.comなどのサービスで簡単にテストでき、この結果が得られます。「待機時間」を意味する黄色の領域に注意してください。

なんでこんなことが起こっているの？考えられるアイデア：

• 不正なPHP-FPM設定
• Linode DNSの応答時間はひどいです。ナンセンス-テストブログはDNSをうまく解決し、TTFBは素晴らしい
• 悪いNginx設定

誰かがさらに情報を必要とする場合に備えて、

• ここに、現在のクローンブログnginx構成ファイル （/etc/nginx/sites-available/muycomputerpro.com）があります。
• ここに、現在のmy.cnf構成（/etc/mysql/my.cnf）があります（現時点では、キャッシュではなく、これは過去のTTFBに影響を与えていません）
• ここには、現在のPHP-FPM構成（/etc/php5/fpm/pool.d/www.conf）があります

第一に、これは答えではなく、診断的なアプローチです。

これは決して包括的なものではありません-またはそれに近いものでさえ、単なる出発点です。

最初のバイトまでの時間

最初のバイトまでの時間（TTFB）にはいくつかの要素があります。

• DNSルックアップ：ドメインのIPアドレスを検索します（改善の可能性：より多数/分散/応答DNSサーバー）
• 接続時間：サーバーへのソケットを開き、接続をネゴシエートします（通常の値は「ping」時間前後である必要があります-通常は往復が必要です-キープアライブは後続の要求に役立つはずです）
• 待機中：最初のバイトを送信する前に初期処理が必要です（これは、改善が必要な場所です-動的コンテンツにとって最も重要です）。

ApacheBenchの出力を見ると、次のこともわかります。

• 処理：これは、待機+コンテンツの完全な転送の合計です（転送時間が、受信したデータの量をダウンロードするのに予想される時間よりも大幅に長い場合、さらなる処理（受信した最初のバイトの後）が発生します（たとえば、ページが使用可能なコンテンツをフラッシュする）

コンポーネントを排除するための比較

例外はほとんどありませんが、問題はバックエンド処理にあります。これは通常、非常に複雑/非効率的なコード、またはMySQLの構成が不適切であることに起因します。

この問題に対処する良い方法は、セットアップのさまざまな側面を排除する一連の比較を使用することです。適切な比較は、問題を絞り込むのに役立つように、可能な限り一定に保つ必要があります。現在、次の比較を提供しています：

1. 古いサーバーと新しいサーバーで実行されている同一の（複製された）サイト：
   • 違い：サーバー
   • 結果：古いサーバーは高速です。新しいサーバーが遅い
   • 注：ここで必要なのは、使用されるスタック（Nginxなど）とハードウェア（より強力なマシンであるため古いサーバーの方が速いかどうか）の観点から、これらのサーバーの違いを定量化することです。
   • 結論：コードは正しいセットアップで高速に実行できる可能性があります
2. 新しいサーバー上のテストサイトとフルサイト
   • 違い：コンテンツ、テーマ、プラグインなど
   • 結果：テストサイトは高速、フルサイトは低速
   • 注：理論的には、このテストは、DNS、ネットワーク、さらにはnginx / php / mysqlのセットアップなど、セットアップの多くの側面を排除するのに役立ちますが、完全に「公平」ではありません。
   • 結論：余分なコンテンツがパフォーマンスに大きな影響を与えている

理想的なテストでは、サイト全体を複製し、1つの記事と関連するコメントを除くすべてのコンテンツを削除します。このテストのポイントは、大量のコンテンツが問題であるか、セットアップの他の側面（wordpressプラグイン、テーマなど）が原因であるかを最終的に判断することです。基本的に、同じ（新しい）サーバー上の同じサイトのパフォーマンスを比較します-同じページをロードする（同じ長さなど）-唯一の違いはサイトコンテンツ全体です（たとえば、一部のプラグインがコンテンツの増加に合わせて拡張できます）。

何も変更せずに、実行できる他の比較がいくつかあります。

• リモート対ローカルからテスト-これは、ネットワーク、遅延、DNSなどが原因であるかどうかを識別するのに役立ちます
  • あなたはすでに（ある程度）これを行っており、ほとんどがネットワークの問題がないと結論付けています。
• Varnish（つまりポート80）とnginx（ポート8080）を直接経由してテストします。テスト間で構成を変更しないようにしてください。正しいポートを使用してください。これにより、ニスの影響がわかります。Varnishはキャッシングレイヤーであるため、最初のリクエスト以降のすべてのリクエストを非常に迅速に処理する必要があります-基本的に、バックエンドと動的ページの生成に必要な処理をバイパスし、キャッシュされたコピーを非常に迅速に処理する必要があります。
  • これを（ローカルではなく）行い、ワニスがパフォーマンスに大きなプラスの影響を与えることを実証しました。

バックエンドの調整

この時点までに、問題を発見したか、バックエンドにあると結論付ける必要があります。これにより、Nginx、PHP、またはMySQLが残ります。

（ -の間、私はあなたのボトルネックはCPU、RAM、またはI / Oであるかどうかを知るために、それは常に便利であること、ここで言及すべきであるsar、top、iostat、vmstat、free、などあなたがこの上でいくつかの結論を出すことができるはずです。）

Nginx

Nginxはリクエストを取得し、静的コンテンツを提供するか、リクエストをPHP-FPMに移行するだけです。通常、Nginxで最適化することはあまりありません。

• Set workers =＃CPUコア
• キープアライブを有効にします（10〜15の値が適切です）。
• 不要なログを無効にする
• 必要に応じてバッファサイズを増やす
• if文を避けます（可能な場合は正規表現の代わりに静的名を使用し、不要な拡張子を削除します）

理想的には、テストブログとクローンブログの構成が同じである場合、その場合は、問題としてNginxを効果的に排除できます。

応用

コードの問題を特定しようとしている場合（たとえば、遅いプラグインなど）、遅いログが開始する場所です。

• MySQLスローログとPHP-FPMスローログを有効にしてベンチマークを実行し、何が遅くなるかを確認します。

MySQL

• キャッシュを増やし、mysqltuner.plを実行して、適切な開始点を取得します。

PHP

• 不要な拡張機能を無効にし、
• register_globals、magic_quotes _ *、expose_php、register_argc_argv、always_populate_raw_post_dataを無効にします。
• memory_limitを増やします
• open_basedirとsafe_modeはパフォーマンスに大きな影響を与えますが、防御の追加レイヤーを提供することもできます。それらの有無にかかわらずテストして、パフォーマンスへの影響が許容できるかどうかを判断します。

PHP-FPM

• pm。*値を調整します-高負荷に対処するために値を増やします

htopの結果がphp-fpmがCPUの大部分を消費していることを示していることに注意してください。問題はこれに直接関係しているようです。

キャッシング

可能性のあるボトルネックをそれぞれ最適化したら、キャッシュを開始します。

• opCodeキャッシュ（APC）が既にあります-動作していることを確認します（テストファイルが付属しています）-キャッシュヒット率を確認し、可能であればディスクではなくメモリにAPCキャッシュを用意します。
• キャッシュするコードをセットアップします（例：W3TCなどのWordpress用プラグインを使用）
• nginxを使用すると、FastCGIキャッシングをセットアップできますが、Varnishがあるため、これを避けるのが最善です。
• Varnishなどのキャッシングレイヤーをセットアップします（既に実行済みです）-動作していることを確認します（例：varnishstatを使用し、Achieving a high Hitrateを読んでください）
• サイトのコンポーネントのキャッシュを追加します-該当する場合、MemCachedなど

アプリケーションとハードウェアの制限を考えると、バックエンドのパフォーマンスをそれほど改善できない場合があります-ただし、それがキャッシュのポイントである-バックエンドの使用を最小限に抑えるためです。

参考文献

• PHPのパフォーマンスチューニング
• PHPの最適化
• 高負荷のためのNginxの最適化