プッシュ通知用に MQTT を実行することに関連して、ユーザーは Linux で 1024 接続制限をどのように超えていますか?
私は Mosquitto サーバーを使用していますが、Linux バージョンには 1024 の接続制限が組み込まれていないと読んだと思います。では、単一のサーバー (ブリッジなどなし) を使用して、5,000、10,000 以上のユーザーを獲得できますか?
または、ブリッジングが絶対に必要ですか? mosquitto の構成設定のマニュアル ページ以外に、これがどのようにセットアップされているかについて多くの記述を見たことがありません。
または、いくつかの Linux 構成設定を変更するだけで、単一の mosquitto サーバーを使用しても問題ありませんか?
私のアプリは多かれ少なかれインスタント メッセージング アプリなので、約 10,000 人、場合によっては 20,000 人が mosquitto に 24 時間 365 日常時接続してメッセージを警告することを期待しています。
うーん
理論的には、mosquitto の最大ソケット数の Linux 設定を必要に応じて増やすことができます。問題はパフォーマンスに関するものです。重要な指標は、1 秒あたりの合計メッセージ数です。20,000 のクライアントが接続されている場合、アクティブになるクライアントの数と、それぞれが送信するメッセージの数は?
例として、クライアントの半分がアクティブで、1 秒あたり 1 メッセージを送信している場合、10k msps になります - もちろん着信のみです。これらのメッセージがそれぞれ 10 バイトの場合、持続的な 100kB/s または 800kbps になります。
もう 1 つの側面は、トピックの階層がどのように配置されているかです。何がベストとは言えませんが、確実に効果はあります。
私の最善の提案は、実在の人物をシミュレートするクライアントを作成し、それを使用してシナリオを実際にテストすることです。
極端なクライアント数の例を見てきました: http://bit.ly/HytRpKですが、それ以上の詳細はありません。
最後のポイント: IBM は現在、MQTT に関するレッドブックを作成しています。それは「春に」、つまりすぐに利用可能になるはずです。スケーリングの問題をカバーすると思います。
お客様の場合、IBM WebSphere MQ の MQTT をテストし、同時クライアント接続の数をキュー マネージャーあたり最大 240,000 まで増やしました (MQ ランタイム、MQ クラスターには多数を含めることができます)。これは、Apache Web サーバーによって適切に処理されるよりも 10 倍程度大きいと言われました。テスト中のサーバー CPU は 5% 未満でした。同時 MQTT クライアントの数を 240,000 をはるかに超えて増やし続けていたでしょうが、ラボは負荷テスト用のクライアント マシンを使い果たしました。IBM MQ は、WebSphere Message Broker ESB に組み込まれた pub/sub プロバイダーであるため、同じ結果になると思います。
その数の接続に対してモスキートのボリュームテストを行った人は誰も知りません。選択したランタイムでmosquittoのインスタンスをテストし、システムテスト中に多数のクライアントスレッドをそれに接続することができると思います。
WebSphere MQをMQTTブローカーとして使用するIBMの実装は、最大100,000の同時接続をサポートすることが示されています。IBMの無料ブローカーRSMBは1024接続に制限されていると思います。
ブリッジとプロビジョニングサービスを使用してブローカーをスケールアウトし、新しいユーザーを接続するブローカーを特定する方法を検討することをお勧めします。