TCP の長い接続を使用するための PHP の最適化アイデア

1. 群衆に直面する

サイトのアーキテクチャが次の点を満たしている場合、この記事の最適化計画は非常に適しています:

1) 開発言語として php などのスクリプト言語を使用します

2) 必要がありますRPC サービス、memcache、redis などのバックエンド サービスに接続するためです。

3) トラフィックが非常に大きい

2. 解決すべき問題

一般的な Web アーキテクチャは上記のとおりです:

1) フロントエンドは APP または Web ページです

2) サーバーの上位層は Web サーバーアクセスです

3) PHP スクリプト言語はバックエンドデータを呼び出し、ビジネスロジックを完成させ、ページを結合します

4) 最後はサービス、キャッシュ、データベースです

php は、プロセスが実行できる C++/Java とは異なり、スクリプト言語です 常駐しているため、短い接続を使用してバックエンド サービスに接続します:

写真上記は典型的なシナリオです。サイト php はマシン A にデプロイされ、キャッシュ memcache はマシン B にデプロイされます。これらは短い接続を通じて通信します。プロセスは次のとおりです:

1) php が tcp 短い接続を確立します

2) 送信します。 memcache プロトコルに従ったデータ

3) memcache によって返されたデータを受信します

4) php が TCP の短い接続を閉じます

サイトのトラフィックが少ない場合、上記のプロセスは機能しませんサイトのトラフィックが非常に大きく、 QPS は非常に高く、PHP による memcache の TCP 接続の確立と終了のオーバーヘッドは無視できません。これを最適化する方法がこの記事の核心です。

3. UNIX ドメイン ソケットの概要

話は変わりますが、まず UNIX ドメイン ソケットのテクノロジについて見てみましょう。

UNIX ドメイン ソケットは、ネットワーク プロトコル スタック、パッケージ化とアンパック、チェックサムの計算、シーケンス番号と応答の維持などを通過する必要がなく、1 つのプロセスからアプリケーション層データをコピーするだけです。別のプロセスに。これは、同じホスト上の 2 つの無関係なプロセスに使用でき、全二重であり、信頼性の高いメッセージ配信のための IPC メカニズムを提供します (メッセージが失われたり、繰り返されたり、混乱したりすることはありません)。

4. 最適化計画

UNIX ドメイン ソケットの効率は TCP ショート接続よりもはるかに高いことがわかりますが、同じホストと PHP アプリケーション間のプロセス通信にのみ使用できます。エンド サービスは別のマシンにデプロイされることがよくありますが、現時点で最適化に使用できますか? 答えは「はい」です。

簡略化されたアーキテクチャ図は上記のとおりです。ローカルプロキシは、php アプリケーションサーバーにデプロイされ、php とローカルプロキシ間の通信に使用され、ローカルプロキシは、ローカルプロキシとの TCP ロング接続を確立します。これにより、通信効率が大幅に向上し、リクエストごとに TCP 短い接続を確立および終了するオーバーヘッドが排除されます。

5. ローカルプロキシの要点

上記の最適化計画を実現するには、ローカルプロキシを実装する際に注意すべき点がいくつかあります

1)。プロトコル設計: ローカル プロキシ自体にはビジネス ロジックはなく、アップストリームは memcache プロトコルを送信し、それをバックエンドの memcache に透過的に送信します。この場合、アップストリーム クライアントは何も作成する必要がありません。コードの修正

2) 通信方法: 前述したように、ローカルプロキシとアップストリームはUNIXドメインソケットを使用して通信し、TCPロングコネクションを使用してダウンストリームと通信します

3) 効率的なフレームワーク: このソリューションは効率の損失を解決します。 tcp の短い接続の効率要件が非常に高いため、成熟した効率的なネットワーク フレームワーク (libevent など) と tcp の長い接続の接続プール テクノロジーを使用して実現します

4) リクエスト マッピング: 必要です上流から送信されたリクエストを下流に送信されたリクエストに 1 つずつマッピングし、上位のリクエスト パッケージが応答パッケージに正しくマッピングされるようにします