NGINX による PHP 7 パフォーマンスの最大化、パート 1: Web サービスとキャッシュ

はじめに – PHP で NGINX を使用する方法

PHP は、サーバー側 Web アプリケーションを作成する最も一般的な方法であり、約80% の市場シェアを占めています。 (ASP.net は大きく離れて 2 位、Java はさらに離れて 3 位です。)

PHP の世界には多数の PHP フレームワークが含まれており、最も人気のあるものには Laravel、Phalcon、Symfony 2 などがあります。 PHP は、 WordPressやDrupalなどの人気のコンテンツ管理システム (CMS) の基盤でもあります。 (最新の Drupal リリースである Drupal 8 には、 Symfony 2 の重要な統合が含まれています。

現在、PHP チームは PHP 5 の導入から 10 年以上経って、新しいバージョンであるPHP 7 をリリースしています。 この間、Web の使用と Web サイトに対する需要はともに飛躍的に増加しました。 PHP はこの急速な成長に貢献してきましたが、PHP が実現した成長によって、PHP の限界も浮き彫りになりました。

PHP は強力で柔軟性が高いとよく言われますが、パフォーマンスの問題が発生することがあります。 PHP ベースのサイトは、トラフィック数が数回倍増しただけで簡単に「壁にぶつかる」可能性があります。 サイトがビジネス目標や運用目標を達成し始めると、トラフィック量が増加するたびにサイトがクラッシュし始めます。

何千もの PHP ベースのアプリケーションでは、比較的単純な変更をいくつか行うだけでパフォーマンスを向上させることができます。 これらには、 memcachedなどのツールを使用したキャッシュ、データベースのチューニング、 NGINX Open SourceおよびNGINX Plusを使用したリバース プロキシと負荷分散が含まれます。 NGINX によりアプリの応答性が大幅に向上し、ユーザー数とトラフィック数の桁違いの増加に対応できるようになりました。

このブログ投稿は、PHP 7 を使用する Web サイトのパフォーマンスを最大化する方法に関する 2 部構成のシリーズの第 1 部です。 ここでは、PHP 7 へのアップグレード、Web サーバー ソフトウェアとしての NGINX Open Source または NGINX Plus の実装、URL の書き換え (リクエストを適切に処理するために必要)、静的ファイルのキャッシュ、動的ファイルのキャッシュ (アプリケーション キャッシュまたはマイクロキャッシュとも呼ばれます) に焦点を当てます。

次のブログ投稿では、リバース プロキシ サーバーの追加、複数のアプリケーション サーバーへの移行、複数のサーバー間の負荷分散、負荷分散中のセッション永続性のサポート、SSL/TLS や関連する HTTP/2 プロトコルなどのセキュリティ プロトコルの終了など、追加サーバーで実行できる手順に焦点を当てます。

PHP が壁にぶつかる理由

PHP アプリケーションが行き詰まるのはなぜでしょうか? 同じ理由で、あらゆるアプリケーション サーバー ソフトウェアが壁にぶつかります。 ユーザーからのリクエストが届くと、PHP とその上で実行される Web サーバー ソフトウェアは、いくつかの処理を実行する必要があります。

• リクエストを解読します。 まず Web サーバー ソフトウェアがプロセスを起動し、次に PHP がプロセスを起動して、リクエストを受信し、解読し、リクエストに応じて処理する必要があります。 たとえば、Apache HTTP Server は、単純なもの (JPEG ファイルの取得) から複雑なもの (ネストされた CSS 要求の処理) まで、各データ要求を処理するためにリソースを割り当てます。 これらすべてには時間、システム リソース、およびメモリ割り当てがかかります。OS、PHP、またはその両方がリクエストの処理を開始する前に多数のライブラリをロードする必要がある場合、メモリ割り当ては非常に大きくなる可能性があります。
• サポートプロトコルを処理します。 SSL/TLS や HTTP/2 を実行する場合、Web サーバー ソフトウェアはリクエストをデコードする必要があり、時間のかかるプロセスになる可能性があります。
• 要求に応じて行動します。 PHP はリクエストを処理するためにリソースをまとめる必要があります。 これには、複数のデータベース呼び出し、インターネット経由での外部サービスへの呼び出し、および複雑な内部処理が必要になる場合があります。
• リクエストに返信します。 PHP は、結果を Web サーバー ソフトウェアに返して、HTTP 応答として要求元に送り返す必要があります。 覚えておいてください。Web サーバー ソフトウェアと PHP は両方とも、最初の受信から最終的な確認まで、各リクエストに対してアクティブな専用スレッドを実行します。

物理サーバー、仮想マシン、またはクラウド サーバー インスタンスがすべてのリクエストを処理するには、膨大な量になります。 サーバー マシン上の物理メモリ (物理または仮想) が使い果たされると、パフォーマンスが低下する傾向があります。 その後、新しいリクエストが到着すると、サーバーは現在のセッションをディスクにページングし始めます。 ファイル要求が満たされるのを待つと、ページングにも影響する待機状態も発生します。 ある（非常に限られた）ポイントを超えると、ページング操作とデータ要求が処理操作を圧倒し、パフォーマンスが悪循環に陥り、イライラしたユーザーに対して長時間の待機やセッションの完全な終了を引き起こします。

パフォーマンスの問題への対処

PHP のパフォーマンス障壁を克服することは確かに可能ですが、そのためにはいくつかの補完的なステップが必要です。 各ステップは他のステップと組み合わせることができます。 大まかに言うと、次のようになります。

• ハードウェアを使って問題に取り組みます。 メモリの増設、ディスクの高速化、データベース サーバーの分離、コンテンツ配信ネットワーク、スループット容量の増加、その他の機械的なソリューションは、パフォーマンスの問題に対する手っ取り早い解決策です。 これらのソリューションは、稼働時間を維持したり、パフォーマンスを直線的に拡張したりする可能性があります。
• PHP とアプリケーション コードの改善。 PHP の新しいバージョン、新しいフレームワーク、改良されたアプリケーション コードが大いに役立ちます。 繰り返しになりますが、新しいハードウェアに追加の費用をかけずに、パフォーマンスを 2 倍、さらには 4 倍にすることも可能です。
• サーバーソフトウェアが改善されました。 ほとんどの Web サーバーと PHP は、進行中の各オープン要求に専用のリソースを割り当てます。 NGINX サーバー ソフトウェアは、リソースを拘束することなく、受信したリクエストを処理し、サーバーのフットプリントを最小限に抑えます。
• マルチサーバー実装。 リバース プロキシ サーバーを実装して、インターネット要求を処理し、1 つ以上のアプリケーション サーバー間で要求を共有 (負荷分散) することができます。 リバース プロキシ サーバーは、ファイルのキャッシュ、SSL/TLS や HTTP/2 などのプロトコルの終了、複数のアプリケーション サーバーの管理も処理できます。 アプリケーション サーバーが 1 台しかない場合でも、これによりワークロードの大部分が軽減されます。 負荷分散により、サーバーを追加しても、どのサーバーも負荷の割り当て分を超えて動作が停止することがなくなります。

これらの手順を特定の順序で実装する必要はありません。たとえば、Web サーバーとして Apache を維持し、アプリケーション サーバーを PHP 7 にアップグレードしない場合でも、既存のサーバーの「前」にリバース プロキシとして NGINX を実装するだけでパフォーマンスが向上し、複数のアプリケーション サーバーを並行して実装できるようになります。

どのような方法であれ、現在のアプリケーション コードをほとんどまたはまったく変更せずに、パフォーマンスを何倍も向上させ、容量を 1 桁も向上させることができることを覚えておくことが重要です。 人々がどのようにしてこれらの驚異的なパフォーマンス向上をすでに達成したか、または達成の過程にあるかを知るには、読み進めてください。

注記： マルチサーバーの最適化がありますが、このブログ投稿ではこれについては多少無視します。 独立したデータベース サーバーとコンテンツ配信ネットワーク (CDN) を使用すると、アプリケーション サーバーの負荷を軽減し、パフォーマンスを大幅に向上できます。これらの種類の変更は、ここで説明するアプリケーションと実装の改善とは別個に行われ、並行して行われます。

ヒント 1 – PHP 7 にアップグレードする

早めに PHP 7 にアップグレードする主な理由は単純です。アプリケーションの速度が向上します (メモリの節約によって大幅に向上します)。 PHP 7 は以前のバージョンの PHP より2 倍高速で、メモリ使用量も大幅に少なくなると言われています。 (どちらの点でも、あなたの結果は間違いなく異なるでしょう。)

応答時間は、Web アプリケーションにとって非常に重要なものです。 より高速な Web アプリは、メモリ使用量も少なくなるため、ページ スワッピングやそれに伴うパフォーマンスの問題の可能性も減り、次の 3 つの効果が得られます。

1. ユーザーの満足度が高まり、記事を読んだり、製品情報を入手したり、ジットニーを呼んだり、空き部屋を借りたり、商品を購入したりするなど、サイトを訪問してタスクを完了する可能性が高くなります。 つまり、そもそもサイトやアプリを作成した理由です。
2. 特定のサーバーが、追加ユーザーによって速度が低下したり、クラッシュしたりするリスクを負うことなく、より多くのユーザーをサポートできるようになります。 破滅を先延ばしにするのは常に良いことだ。
3. サーバーに過負荷をかけ、稼働を停止させるハッカー攻撃に対するサーバーの脆弱性を軽減します。 今日では誰もが攻撃を受けますが、弱い者はより攻撃を受け、より攻撃的になります。 したがって、脆弱性が少ないほうが、多い場合よりも飛躍的に良い結果をもたらす可能性があります。

これらはすべてアップグレードする優れた理由であり、これらを総合すると、アップグレードする理由は圧倒的に多いように思われます。 また、パフォーマンス上の明らかなメリットがない場合でも、多くの問題を解決するために「最新バージョンにアップグレードする」ことが常に最初に推奨されます。 では、なぜ誰もがすぐにアップグレードしないのでしょうか?

簡単です。人々は古いコードに手を加えることを嫌いますが、それには十分な理由があります。 古いアプリが十分に動作していて、開発者が古いアプリをアップグレードするよりも新しいアプリを作成することでより良い結果を得られる場合、古いアプリは変更されずに長期間そのまま残ります。 (現在の Web サーバーとアプリに変更を加えずに NGINX を使用してアプリのパフォーマンスを向上させる方法については、このシリーズの 2 番目のブログ投稿を参照してください。)

しかし、可能であれば、より効率的な方法は、パフォーマンスの向上を求めて PHP 7 にアップグレードすることです。 ただし、特にテストを怠ることなく、完了するのに十分な時間が取れるまでは、開始しないでください。

PHP 7 にアップグレードするために必要なものを見てみましょう。

• 式の評価の変更。 PHP 7 で式を正しく評価するには、一部の式の記述方法を変更する必要がある場合があります。 (または、すべての PHP サーバーを一度にアップグレードせず、PHP 5.6 と PHP 7 の両方で適切に評価されるように、細心の注意を払っている場合)。 可変変数または可変プロパティがある場合は、両方の PHP バージョンで同じように評価されるようにコードを修正する必要があります。
• 構文の変更。 PHP 7 は ASP またはスクリプト タグをサポートしていません。 スイッチに対して複数のデフォルトケースを持つことはできません。 ( switchとif-then-elseの論争についてはここでは触れません。)
• 非推奨の機能の削除。 いろいろなもの PHPの5.xバージョンで廃止された機能は、今では 死んだオウム。 これらは PHP 7 では動作しません。 これらがコード内に存在し、すべて削除しようとして失敗した場合、ショッピング カート コードの機能はサイバー マンデーの前日の午後 11 時 59 分に確実に消えてしまいます。
• 新機能。 PHP 7 では、古いコードをアップグレードしたいユーザーを誘惑する新しい機能が多数追加されていますが、コードのクリーンアップで新しい機能を追加する際には注意が必要です。 新しい機能は素晴らしいものであることが多く、そうでなければ追加されなかったでしょう。しかし、それらはバグ（自分のものも他人のものも）や、PHP がさらにアップグレードされるにつれて将来の改訂を招く原因にもなります。
• 一般的なコードレビュー。 コードに触れるときはいつでも、つまりコード ファイルを開いて変更したかどうかわからないときはいつでも、コード内のすべての内容、特に変更した部分を確認する必要があります。
• テスト中。 すべてを常にテストする必要があります。 変更を加えた場合は、すべてを再テストする必要がありますが、それでもすべてのバグを検出できるわけではありません。 適切に実装された DevOps 環境では、このテストは比較的簡単に実行できますが、現時点でその約束の地に住んでいるのはほんの一握りの人だけです。

Engine Yard のこのブログには、これらの問題のほとんどに関する良い例が掲載されています。

PHP 7 にアップグレードすることに決めた場合は、PHP 7 の新機能を活用して、コードのパフォーマンスを全面的に見直し、少なくとも重要な機能を修正することを検討してください。 あなたとあなたのチームがスキルアップするには、これより良い方法はありません。今日実行、レビュー、テストする変更は、今後何年にもわたって役立つ可能性があります。 最適化されたコードは最適化された環境で実行することで大きなメリットが得られるため、このブログ投稿にあるその他のパフォーマンスに関する提案も最大限に活用できます。

そのため、アプリケーション コードに触れることなくパフォーマンスを向上させるために NGINX を導入するサイトが多いにもかかわらず、勇気を出して前進することをお勧めします。 引っ越しをするためのサポートはたくさんありますが、自分で袖をまくって引っ越しをすることもできます。 公式サイトにはPHP 7 移行ガイドがあり、O'Reilly からはPHP 7 アップグレードのハウツー本も出版されています。

ヒント 2 – NGINX Open Source または NGINX Plus を選択する

NGINX は、最もアクセス数の多い 10,000 の Web サイトの半数を含む、1 億 4,000 万以上の Web サイトを運営しているソフトウェアです。 (これらの測定では、単一サーバー サイトで Web サーバーを検出し、複数サーバー サイトでリバース プロキシ サーバーを検出します。) ウェブ サーバーとしては、どちらも即座にパフォーマンスが向上します。他のソフトウェアを実行しているサーバーが過負荷になり、最大 10 倍のスラッシングが発生するケースもあります。 リバース プロキシ サーバーとして、どちらも複数の専用サーバーを使用して、必要に応じて展開を拡張できます。

PHP と Apache はどちらも、すべてのオープン リクエストにリソースを割り当てます。どちらかまたは両方が多数のライブラリをロードする必要がある場合、リクエストごとの起動時間とメモリ フットプリントがかなり大きくなる可能性があります。 Web サーバー ソフトウェアとして NGINX に移行すると、サーバー レベルでこの問題が解消されます。 NGINX の機能を使用して、作業を Web サーバー (静的ファイルの提供など) またはリバース プロキシ サーバー (あらゆる種類のキャッシュ、プロトコル終了、負荷分散など) にオフロードすると、PHP が実行する必要がある作業が最小限に抑えられ、アプリケーション処理が簡素化され、高速化されます。

サイトにカスタムまたは独自の Apache モジュールがある場合は、モジュールを置き換えるまで Apache を NGINX に置き換えることができない可能性があります。 NGINX に問い合わせて、簡単な回避策があるかどうかを確認します。ない場合は、変更に必要な時間と労力を計算します。

NGINX を使用することを決定したら、NGINX Open Source と NGINX Plus のどちらかを選択できます。 NGINX Open Source と比較した NGINX Plus の最も顕著な機能は次のとおりです。

• プリコンパイルされたコード。 NGINX Plus はコンパイルされた形式で配布され、人気のあるライブラリや、オンザフライで追加および削除できる動的モジュールが含まれています。 (NGINX オープンソースは、コンパイル済みコードと未コンパイルコードの両方で利用できます。) サーバーを再起動せずに、幅広い構成変更を行うことができます。
• サポート。 NGINX Plus にはサポート パッケージが含まれており、NGINX エンジニアに直接アクセスできます。
• 監視と管理。 DevOps に適したツールは、サービス レベル アグリーメント (SLA) を満たすためにサーバーを稼働状態に保つのに役立ちます。

リバース プロキシ サーバーとして、NGINX Plus には追加の利点があります。

• 負荷分散。 NGINX の両方のバージョンは基本的な HTTP ロード バランシングをサポートしていますが、NGINX Plus ではより洗練されたアルゴリズムとTCP ロード バランシングが追加されています。
• セッションの永続性。 NGINX Plus は、負荷分散に加えて、PHP アプリケーション サーバーに非常に関連する、より洗練されたセッション永続性も提供します。
• 監視と管理。 NGINX Plus の監視および管理の全機能は、マルチサーバー展開で発揮されます。また、より複雑な実装では、プリコンパイルされたコードとサポートの価値も最大化されます。

NGINX Open Source と NGINX Plus はどちらも、コンテンツ キャッシュとマイクロキャッシュ (アプリケーション キャッシュとも呼ばれます) をサポートしています。 キャッシュは、アプリケーション サーバーの負荷を軽減するため、Web サーバーのコンテキストでは役立ちますが、両方の機能は依然として単一のマシンまたは仮想マシン インスタンスを共有しています。 リバース プロキシ サーバーでは、キャッシュによってアプリケーション サーバー デバイスから大量の作業負荷を軽減できるため、パフォーマンス上の利点が大きく高まります。

NGINX オープンソース ソフトウェアはnginx.orgから直接ダウンロードできます。コミュニティ サポートも利用できます。 単一の NGINX Plus サブスクリプションを開始するには、 30 日間の無料トライアルに登録するか、オンラインで購入します。 マルチインスタンス バンドルについては、 NGINX セールスにお問い合わせください。

ヒント 3 – Apache 設定を NGINX 構文に変換する

Web サーバー ソフトウェアとして Apache から NGINX に移行する場合、いくつかの変更を行う必要があります。詳細は、 sitepoint.comの優れた記事で説明されています。

• 設定ファイルを作成または変換します。 構成コードを変更して、NGINX (Apache ではありません) が構成に使用するファイルを指定します。
• 読み取り/書き込み権限を変更します。 ウェブサイトのルート ディレクトリ内のファイルに対して CRUD 操作 (作成、読み取り、更新、削除) を実行するための権限をアカウントに追加します。
• 有効な検索パターンを指定します。 ロケーション ブロックを追加して、リクエストの処理中に NGINX が試行できるパターンと試行できないパターンを指定します。
• .htaccess 構成コードを置き換えます。 Apache の構成の詳細は、通常、.htaccess ファイルまたは静的構成ファイル ( mod_rewriteディレクティブなど) に保存されます。 これらを NGINX 構成ファイル内の関連する構成仕様に置き換えます。 いくつかの例については、当社のブログをご覧ください。

これらの変更を行うことで、NGINX に慣れ、このブログ投稿のパート 2 で説明するように、より複雑なサイトを最適化できるようになります。 ただし、これらの構成変更を行うと、許容できない量の作業が発生したり、サイトの運用にリスクが生じたりする場合でも、心配する必要はありません。パート 2 で説明したマルチサーバー アーキテクチャは、Apache のコア Web サーバー ソフトウェアをアップグレードせずに、つまり Web サーバーの構成ファイルを変更せずに実装できます。

ヒント4 – 静的ファイルキャッシュを実装する

静的ファイルとは、少なくとも Web サーバーの観点から言えば、頻繁に変更されないファイルのことです。 静的ファイルには通常、JPEG や PNG などのグラフィック ファイルと、CSS や JavaScript ファイルなどのコード ファイルが含まれます。 これらのファイルをアプリケーション サーバーまたは別のデータベース サーバーに配置すると、それらのファイルに対する要求はアプリケーション コードによって処理される必要があり、要求の作成と実行に必要なすべてのオーバーヘッドが発生します。 これにより、アプリケーション サーバーはより重要な作業から「気をそらされ」、物理メモリが過負荷になり、新しい要求によって現在の要求がディスクにページ アウトされる状態に近づく可能性があります。

静的ファイル キャッシュは NGINX のコア機能です。Web サーバーまたはリバース プロキシ サーバーに実装できます。

• NGINX Web サーバーでは、静的ファイル キャッシュによってアプリケーション サーバーの負荷が軽減され、ファイルの取得が高速化され、メモリ オーバーヘッドが大幅に削減されます。 ただし、ファイルの取得は依然として同じ物理サーバーまたは仮想サーバー インスタンスから実行されるため、サーバーのプロセッサはアプリケーションの実行以外のタスクを処理する必要があります。
• NGINX リバース プロキシ サーバーは、Web サーバーとは別のマシンまたはインスタンスで実行されるため、静的ファイルのキャッシュによってアプリケーション サーバーのリソースが消費されることはありません。 アプリケーション サーバーは、アプリケーションの実行にのみ集中できます。

NGINX で静的ファイル キャッシュを実装するには、次の 3 つの手順を実行します。

• 検索のルート ディレクトリを指定します。
• リクエストを処理しています。
• 応答速度を最適化します。

リバース プロキシ サーバーが関与しない NGINX Web サーバーでは、通常の意味でのキャッシュは行われません。 X-Accel-Redirectヘッダーを使用して、静的ファイルへの問い合わせを Web サーバーにリダイレクトするだけです。 アプリケーション サーバーは要求を認識することはなく、すべてのリソースをアプリケーション要求に割り当てることができます。 リバース プロキシ サーバーでは、静的ファイル キャッシュが使用されます。アプリケーションを実行する物理サーバーまたは仮想サーバー インスタンスは、静的ファイル要求に応答する役割を一切持ちません。

応答速度を最適化する例として、次の構成スニペットにより、NGINX はオペレーティング システムのsendfileシステム コールを使用できるようになります。これにより、ファイルを中間バッファーにコピーしないため、ファイル転送の手順が 1 つ省略されます。

場所 /mp3 { sendfile オン;
sendfile_max_chunk 1m;
# ...
}

静的ファイル キャッシュ用に NGINX を構成する詳細については、 NGINX Plus 管理者ガイドを参照してください。

ヒント5 – マイクロキャッシングを実装する

マイクロキャッシングは、紛らわしいことに、アプリケーション キャッシングや単なるキャッシングなど、さまざまな名前で呼ばれます。 NGINX では、このようなファイルの有効期間が短いことを強調するために「マイクロキャッシュ」という用語を使用しています。

ユーザーのコメントのためのメカニズムを提供するブログ投稿ページがあるとします。 新しい訪問者がページにアクセスするたびに、または既存のユーザーがページを更新して自分の新しいコメントや他のユーザーの新しいコメントを表示するたびに、最新かつ最も優れたコメントを含める必要があります。 この場合、誰かがページにアクセスするたびにページを新たに生成するのが良い考えのようです。

しかし、「毎回」というのは負担になることもあります。 ページが 1 秒あたり 1 回訪問される場合、訪問ごとに新たに生成することは理にかなっています。 しかし、そのページがサイト上の他のすべてのページとともに 1 秒あたり 10 回、100 回、または 1,000 回のアクセスを受けると、アプリケーション サーバーが過負荷になる可能性があります。 人々に新鮮なコンテンツを提供するという目標を達成するということは、誰もすぐにコンテンツを入手できないことを意味します。

マイクロキャッシュとは、キャッシュされたバージョンを 1 秒または数秒などの短い期間有効としてマークしてページを生成することを意味します。 キャッシュされたバージョンの有効期限が切れると、次のリクエストで新しいページの生成が促され、その直後のリクエストでキャッシュされたバージョンが取得されます。 これは静的ファイルの場合と同じ動作ですが、時間枠がはるかに短くなります。

この画像は、サイト上でマイクロキャッシュできるコンテンツを探す場所を示しています。 これは、当社の Owen Garrett によるマイクロキャッシングに関するブログ投稿からの抜粋です。

マイクロキャッシングは、最も必要なときにアプリケーション サーバーから作業を削除し、ユーザーにほとんどまたはまったく損害を与えない点で優れています。 とても素晴らしいので、いくつかのシステムに組み込まれています。 Drupal では、その強力な組み込みマイクロキャッシュ機能が非常に重要であると考えられているため、Drupal の世界ではマイクロキャッシュは単に「キャッシュ」と呼ばれています。

しかし、Drupal ソリューションには若干の欠陥があり、同様のソリューションも同様です。 アプリケーション サーバーが行う作業は減りますが、構成、実装、およびファイル提供を管理するのは依然として Drupal (または、より一般的には PHP) です。 マイクロキャッシュに NGINX を使用すると、マイクロキャッシュによって指定された頻度で新しいページを生成すること以外、アプリケーション サーバーの負荷は完全に軽減されます。 キャッシュ ヒットのために何かを保存したり取得したりする必要はもちろん、他のリクエストも確認しません。

NGINX Plus やその他のツールを使用してサイトを監視し、マイクロキャッシュのメリットが得られるページを確認できます。 次の設定スニペットは、レスポンスの1秒間のキャッシュ期間を実装します。 200OKステータスコード。

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
proxy_cache cache;
proxy_cache_valid 200 1s;
# ...
}

パート1の結論

PHP ブログ投稿の最初の部分では、単一サーバー ソリューションとキャッシュに焦点を当てています。キャッシュは単一サーバーの実装で効果的ですが、リバース プロキシ サーバーが混在している場合はさらに効果的です。 パート 2 では、リバース プロキシ サーバー、PHP アプリケーションを中心としたマルチサーバー実装の利点について説明します。

NGINX Plus をお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。