プロジェクトの1つで作業するとき、登録ユーザー間の通信を実装するタスクに直面しました。 基本的にはチャットである必要がありますが、同時に1人の対話者のみと通信できます。
このようなチャットが耐える潜在的な負荷は、約10,000の同時キープアライブ接続です。 各新しいメッセージは、メインデータベースと「高速」データベースに記録する必要があります。そのタスクは、ユーザー間の通信の実際の部分のみを保存することです。つまり、メッセージがすぐに宛先に配信される一種の「一時」ストレージとして機能します。
MongoDBはこのタスクに適しています。 レプリケーションプロセスが十分に確立されているため、local.oplog。$ Mainテーブルに定期的に新しいメッセージ用の個別のデーモンを問い合わせ、もしあれば、JSON形式でアドレスに即座に配信できます。 負荷のかかった安定した動作のために、そのようなデーモンがいくつかあり、数千のスクライブがそれらのそれぞれに接続されます。
そしてここで、悪魔が置かれる「高速サーバー」として使用するものの選択に直面しましたか？ これを行うために、 phpDaemonベースとNode.JSベースの2つのソリューションをテストしました。
したがって、初心者向けの完全なチャットアーキテクチャは次のとおりです。
図 1.完全なチャット構造
- 通信を開始する各新しいクライアントは、「高速」サーバー（ phpDaemonまたはNode.js ）の1つとの接続を確立し、そこからメッセージを受信します。
- メインサーバーに新しいメッセージを送信すると、そのメッセージは永続データベース（ MySQL ）と、ある種の「高速」データベース（この場合はMongoDB ）に書き込まれます。
- マスターMongoDBは、変更をlocal.oplog。$レプリケーション用のメインコレクションに書き込みます 。
- この時点で、「高速サーバー」は、新しいメッセージの存在について「高速」データベースの調査を実施し、もしあれば、それらが宛先のクライアントに送信します。
テストバージョンでは、永続的なデータベースとユーザー認証はありません。 コレクションから新しいメッセージを取得し、現在アクティブなすべてのクライアントに送信する「高速サーバー」は1つだけです（図2）。
図 2.簡素化されたチャット構造
今日プレーしているチームの構成：
Node.jsチーム
- Node.js（ http://nodejs.org ）
- クライアントとNode.js間の接続を確立するためのSocket.IOライブラリ（ http://socket.io ）
- Node.jsからMongoDBを操作するためのChristkv Node-mongo-nativeライブラリ（ https://github.com/christkv/node-mongodb-native ）
- さて、MongoDBに新しいメッセージをポーリングするための同じライブラリのoplog.jsファイル（ https://github.com/christkv/node-mongodb-native/blob/master/examples/oplog.js ）
PhpDaemonチーム
- phpDaemon（ http://phpdaemon.net ）
- クライアントとサーバー間の接続を確立するためのphpDaemonからのスクリプト（ https://github.com/kakserpom/phpdaemon/tree/master/clientside-connectors/websocket ）
- MongoDBを使用する場合は、組み込みのphpDaemon機能も使用します
- データベースを照会するには、わずかに変更されたMongoNodeアプリケーション（ https://github.com/kakserpom/phpdaemon/blob/master/app-servers/MongoNode.php ）を使用します 。これは、Memcacheに変更を書き込まず、接続しているすべてのユーザーに送信します。
会議の裁判官はApache Benchmarkです。
そのため、MongoDBのポーリングをリードするデーモンの1つを起動します。また、着信クライアントと「通信」します。 別のマシンからApache Benchmarkユーティリティを使用して、複数のキープアライブクライアントを接続します（テスト時間20秒）。 この時点で、サードパーティのフォームを使用して、MongoDBにメッセージを書き始めます。 各デーモンおよびキープアライブ接続の数ごとに、 5回の反復を行い、データを平均して結果を確認します。
| 鬼
| 完全なリクエスト
| 1秒あたりのリクエスト
| リクエストあたりの時間、ミリ秒
（すべての同時リクエスト全体） | 分
リクエスト、ms | 最大リクエスト、ミリ秒
|
|---|---|---|---|---|---|
| 10個のキープアライブ接続
| |||||
| phpDaemon
| 1147
| 54.36
| 18.440
| 21
| 7116
|
| Node.JS
| 1285
| 64
| 15.618
| 16
| 9064
|
| 100個のキープアライブ接続
| |||||
| phpDaemon
| 1543
| 75.15
| 13.313
| 22
| 12889
|
| Node.JS
| 1284
| 64.12
| 15.765
| 17
| 13347
|
| 500のキープアライブ接続
| |||||
| phpDaemon
| 1365
| 67.73
| 14.824
| 15
| 15174
|
| Node.JS
| 1236
| 61.71
| 16.611
| 23
| 16078
|
| 1000キープアライブ接続
| |||||
| phpDaemon
| 1159
| 56.99
| 17.680
| 19
| 13103
|
| Node.JS
| 1528
| 75.02
| 13.354
| 17
| 16785
|
赤は「最高のパフォーマンス」を示します
ご覧のとおり、少数の同時接続（10）では、Node.JSに基づくチャットの方が優れています。 より多くの要求が処理され、1つの要求の処理に必要な時間がそれに応じて短縮されます。 確かに、phpDaemonは最長のリクエストの期間が短くなっていますが、これはそれほど重要ではありません。
化合物の数が100、そして500に増加すると、状況は変わりました。 PhpDaemonはすでにパフォーマンスの面で進歩しています。
また、1000個のキープアライブ接続により、phpDaemonaのパフォーマンスは低下しましたが、Node.JSのパフォーマンスは向上し、かなり大きなギャップが生じました。