PHP 最適化のごった煮

WBOY
WBOYオリジナル
2016-06-23 13:36:31739ブラウズ

PHP の最適化に関する記事では、効率的なコードの書き方を説明することがよくありますが、この記事では、この問題を別の角度から議論し、最適化の目的も達成できるように効率的な環境を構成する方法を説明することを目的としています。憂鬱なニュースは、大多数の PHP プログラマーがプールの値を無視していることです。ここで説明するプールは、データベース接続プールなどのことを指しますが、PHP では複数のプールを同時に起動できます。各プールは、互いの主権と領域の整合性を尊重しません。互いに内政干渉する。

-pool

メリットは何ですか?デフォルトでは、PHP では 1 つのプールのみが有効になっており、すべてのリクエストはこのプールで実行されます。特定のリクエストが混雑すると、プール全体が炎上する可能性があります。複数のプールが有効になっている場合は、リクエストを異なるプールに分類して実行できます。混雑などの状況が発生した場合にのみ影響します。これにより、障害の範囲が制御されます。

listen

Nginx と PHP は別のサーバーにデプロイできますが、実際のアプリケーションでは、ほとんどの人が同じサーバーにデプロイすることに慣れているため、2 つのオプションがあります: 1 つは TCP、もう 1 つはUnixソケットです。

-listen Unix Socket は TCP と比較して、TCP スリーウェイ ハンドシェイクなどの一部のリンクを省略しているため、比較的効率的ですが、Unix Socket を使用する場合、それに相当する信頼性がないことに注意してください。 TCP 保証メカニズムなので、バックログと somaxconn を大きく設定することが最善です。そうしないと、同時実行性が高くなると不安定になります。

pm

プロセス管理は、動的と静的に分けられます。動的モードでは通常、最初に少数のプロセスが開始され、その後リクエストの数に応じてプロセスの数がリアルタイムで調整されます。この利点はリソースの節約であることは明らかですが、もちろん欠点も明らかです。一度大量のリクエストが発生すると、システムはビジー状態になり、新しいプロセスを FORK する必要があり、必然的にパフォーマンスに影響します。同様に、静的モードでは十分な数のプロセスを一度に FORK し、リクエストの量に関係なく変更されません。動的モードと比較して、静的モードはより多くのリソースを消費しますが、同時リクエストが多い場合でも高価な FORK を実行する必要はありません。

-pm トラフィックの多い Web サイトの場合、サーバー リソースが逼迫していない限り、静的モードが最適な選択であることは間違いありません。

pm.max_children

PHP プロセスはいくつ起動するのが適切ですか?自分自身の答えを与える前に、次の記事を読んでください:

php-fpm の max_chindren に関するいくつかの誤解

PHP ワーカーは常に CPU の数と等しい必要があります 1 つの CPU は、特定の時点で 1 つのリクエストしか処理できません。リクエストの数が CPU の数よりも多い場合、CPU は複数のタスクのスケジューリングを伴うため、必然的にパフォーマンスの一部を消費します。プロセスの数は CPU の数と同じである必要があり、各プロセスが専用の CPU に対応するため、コンテキスト切り替えの効率損失を最小限に抑えることができます。ただし、この結論が正しいのは、リクエストが CPU 集中型である場合に限られます。現時点では、データベース クエリなどの IO の存在が避けられないため、この結論には疑問があります。これにより、CPU は時間のかなりの部分を待機状態で費やすことになり、これは無駄な状態です。このとき、プロセスの数が CPU の数を超えている場合、IO が発生すると、CPU は実行を継続するために他のリクエストに切り替える機会が得られますが、これにより一定のコンテキスト切り替えのオーバーヘッドが発生しますが、これよりもはるかに優れています。 WAIT 状態に陥っています。

どのくらいが適切ですか?この問題を明確にするには、CPU に注意を払うだけでなく、メモリの状況にも注意を払う必要があります:

  • -PHP Memory
  • 上に示すように、top コマンドの結果のメモリ関連の列は次のとおりです。それぞれ VIRT、RES、SHR。 VIRT はメモリ使用量の理論値を表します。通常、RES はメモリ使用量の実際の値を表しますが、これには SHR によって表示される値である共有メモリが含まれています。単一の PHP プロセスが独立して占有する実際のメモリ サイズは「RES ? SHR」に等しく、通常は約 10M です。この計算に基づくと、理論的には 1G メモリで約 100 個の PHP プロセスをサポートでき、10G メモリで約 1,000 個の PHP プロセスをサポートできます。もちろん、多ければ多いほど良いと考えるのは失礼ではありません。PHP のステータス インターフェイスと組み合わせて、アクティブな接続数を監視して調整するのが最善です。
  • 声明:
    この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。