たとえば、共有、仮想、または専用ホスティングを取得する場合、サーバー/マシンが一度に処理できる TCP 接続は 64,000 個までとどこかで読みましたが、これは本当ですか? 帯域幅に関係なく、どのタイプのホスティングでも処理できる接続数はどれくらいですか? HTTP は TCP 経由で動作するものと想定しています。
これは、64,000 人のユーザーしか Web サイトに接続できず、より多くのユーザーにサービスを提供したい場合は Web ファームに移行する必要があることを意味しますか?
ベストアンサー1
要するに、あなたは数百万単位同時にアクティブな TCP 接続と、それに伴う HTTP 要求の数。これにより、適切な構成の適切なプラットフォームで期待できる最大のパフォーマンスがわかります。
今日、私は ASP.NET を使用した IIS が 100 程度の同時接続をサポートするかどうか心配していました (私の更新を見ると、古い ASP.Net Mono バージョンでは 1 秒あたり約 10,000 の応答が期待できます)。この質問/回答を見たとき、自分で答えずにはいられませんでした。ここでの質問に対する回答の多くは完全に間違っています。
最良の場合
この質問に対する答えは、下流で起こり得る無数の変数や構成から切り離すための、最も単純なサーバー構成にのみ関係する必要があります。
したがって、私の答えとしては、次のシナリオを考えてみましょう。
- TCP セッションでは、キープアライブ パケット以外のトラフィックは発生しません (そうでない場合は、当然、対応する量のネットワーク帯域幅とその他のコンピュータ リソースが必要になります)
- プールからのリクエストごとにハードウェア スレッドを使用するのではなく、非同期ソケットとプログラミングを使用するように設計されたソフトウェア。(つまり、IIS、Node.js、Nginx... 非同期設計のアプリケーション ソフトウェアを備えた Web サーバー (Apache は除く))
- パフォーマンス/価格に見合った CPU / RAM。今日は、適当に i7 (4 コア) と 8GB の RAM としましょう。
- 一致する適切なファイアウォール/ルーター。
- 仮想制限/ガバナーなし - 例: Linux somaxconn、IIS web.config...
- 他の低速ハードウェアに依存しません。ハードディスクからの読み取りは、ネットワーク IO ではなく、最低共通分母およびボトルネックとなるため、実行されません。
詳しい回答
同期スレッドバインド設計は、非同期 IO 実装に比べてパフォーマンスが最も悪くなる傾向があります。
WhatsAppは、Unix系OSマシン1台で100万のWITHトラフィックを処理できます。https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/。
そして最後にこれ、http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.htmlは、1,000 万という数値を達成するにはどうすればよいかを詳細に説明しています。サーバーには、汎用 CPU よりも効率的にこの特定の役割向けに設計された ASIC であるハードウェア TCP オフロード エンジンが搭載されていることがよくあります。
優れたソフトウェア設計の選択
非同期IOの設計はオペレーティングシステムやプログラミングプラットフォームによって異なります。Node.jsは非同期を念頭に置いてください。少なくとも Promises を使用する必要があります。また、ECMAScript 7 が登場したら、async/awaitを使用します。C#/.Net には、node.js のような完全な非同期サポートがすでに備わっています。OS やプラットフォームに関係なく、非同期は非常に優れたパフォーマンスを発揮することが期待できます。また、どの言語を選択する場合でも、「非同期」というキーワードを探してください。ほとんどの最新言語には、何らかのアドオンであっても、何らかのサポートがあります。
WebFarmへ？
特定の状況における制限が何であれ、Web ファームはスケーリングの優れたソリューションの 1 つです。これを実現するためのアーキテクチャは多数あります。1 つはロード バランサーを使用することです (ホスティング プロバイダーはロード バランサーを提供できますが、これにも制限があり、帯域幅の上限もあります)。ただし、このオプションはお勧めしません。接続が長時間実行されるシングル ページ アプリケーションの場合、代わりに、クライアント アプリケーションが起動時にランダムに選択し、アプリケーションの存続期間中に再利用するサーバーのオープン リストを用意することを好みます。これにより、単一障害点 (ロード バランサー) がなくなり、複数のデータ センターを介したスケーリングが可能になり、帯域幅が大幅に増加します。
神話を打ち破る - 64K ポート
「64,000」に関する質問の要素についてですが、これは誤解です。サーバーは65535以上のクライアントに接続できます。https://networkengineering.stackexchange.com/questions/48283/is-a-tcp-server-limited-to-65535-clients/48284
ちなみに、Windows 上の Http.sys では、HTTP URL スキーマの下で複数のアプリケーションが同じサーバー ポートを共有することが許可されています。各アプリケーションは個別のドメイン バインディングを登録しますが、最終的には 1 つのサーバー アプリケーションが要求を適切なアプリケーションにプロキシします。
2019-05-30更新
最速のHTTPライブラリの最新の比較はこちらです -https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- テスト日: 2018-06-06
- 使用ハードウェア: Dell R440 Xeon Gold + 10 GbE
- リーダーは1秒あたり約700万のプレーンテキスト応答を持っています（応答であり、接続ではありません）
- 2番目のFasthttp for golangは150万の同時接続を宣伝しています - 参照https://github.com/valyala/fasthttp
- 上位の言語は Rust、Go、C++、Java、C で、C# でさえ 11 位 (690 万/秒) にランクされています。Scala と Clojure はさらに下位にランクされています。Python は 270 万/秒で 29 位にランクされています。
- リストの一番下には、laravel と cakephp、rails、aspnet-mono-ngx、symfony、zend があります。すべて 1 秒あたり 10k 未満です。これらのフレームワークのほとんどは動的ページ用に構築されており、かなり古いものですが、リストの上位には新しいバリエーションがある可能性があります。
- これは HTTP プレーンテキストであり、Websocket 専門ではないことに注意してください。ここに来る多くの人は、Websocket の同時接続に興味がある可能性があります。