web-dev-qa-db-ja.com

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

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

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

WordPress 3.3.1に基づいたブログがいくつかあります。3.3.1。それらの1つは、サーバーをテストするためのデフォルトの設定、テーマ、および「Hello World」投稿のみのプレーンなブログです。もう1つは、他のサーバーからクローンを作成したブログで、投稿数は1万近く、コメント数は1万を超えています。

サーバーは テストブログ のabテストで適切な数値を示していますが、クローンされたブログで同じテストを実行することは不可能です。abテストはサーバーに負荷をかけすぎているため、プロセスを停止する必要があります、とにかくabを表示する これは本当に悪い結果です 。

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

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

なぜこうなった？考えられるアイデア：

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

誰かがもっと情報が必要な場合に備えて、

  • ここにあなたは現在クローンされたブログを持っています nginx config file （/ etc/nginx/sites-available/muycomputerpro.com）
  • ここに current my.cnf config （/ etc/mysql/my.cnf）があります（私は今のところキャッシュしていませんが、これは過去のTTFBに影響を与えていません）
  • ここに 現在のPHP-FPM構成 （/ etc/php5/fpm/pool.d/www.conf）があります。
nginxwordpressvarnishphp-fpm
14
javipas

まず、これは答えではなく、診断アプローチです。

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

最初のバイトまでの時間

最初のバイトまでの時間（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で最適化することはあまりありません。

  • ワーカーの設定=＃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キャッシュを設定します。
  • キャッシュするようにコードを設定します（例：Wordpress W3TCなどのプラグインを使用））
  • Nginxを使用すると、FastCGIキャッシングをセットアップできますが、ワニスを使用しているため、これは回避するのが最善です。
  • Varnishなどのキャッシングレイヤーをセットアップします（既に実行済みです）。これが機能していることを確認します（たとえば、varnishstatを使用して、読み取り 高いヒット率を達成する ）。
  • サイトのコンポーネントのキャッシュを追加します-例：該当する場合はMemCached

アプリケーションとハードウェアの制限を考えると、バックエンドの使用を最小限に抑えるために、バックエンドのパフォーマンスをそれほど向上させることができない場合があります（ただし、それがキャッシュの目的です）。

さらに読む

24
cyberx86