1秒あたり10000のTCP接続を処理するシステムを設計していますが、どのような問題に遭遇しますか？

CentOSを実行している比較的新しい8コアボックスがあります。TCPを使用する統計サーバーを開発したいと思います。これは非常に単純で、TCP接続を受け入れ、カウンターをインクリメントし、接続を閉じます。キャッチは、少なくとも1秒に1万リクエストでこれを行う必要があるということです。CPU /メモリは問題ないだろうと思っていますが、この種のボリュームを許可するためにサーバーで設定する必要があるかもしれない人為的な制限（ハーフオープン接続など）の方が心配です。だから、これは可能ですか？どの設定に注意する必要がありますか？NICはそれを処理できませんか？

これは一般にc10k問題として知られています。そのページには、あなたが遭遇する問題に関する多くの良い情報があります。

あなたはそれをすることができるはずです（それはおそらく悪い考えですが）。

上の樹脂のappserv私はクアッドコア2.6GHzのXeonプロセッサ上〜5K REQ /秒を得ることができます。要求は、mysqlから1行を読み取り、非常に小さなxml応答を送信する単純なサーブレットを呼び出します。

テストは

ab -n 10000 -c 16 http://some/url/

試験結果：

Concurrency Level:      16
Time taken for tests:   1.904 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3190000 bytes
HTML transferred:       1850000 bytes
Requests per second:    5252.96 [#/sec] (mean)
Time per request:       3.046 [ms] (mean)
Time per request:       0.190 [ms] (mean, across all concurrent requests)
Transfer rate:          1636.42 [Kbytes/sec] received

しかし、各リクエストごとに新しいスレッドを生成することなく、単純なcプログラムを使用する方がはるかに優れていると思います。Greg Hewgillからのリンクはあなたにそれについて良いアイデアを与えるはずです。

長時間のテスト中であっても、接続に関する問題は発生しません[前述のハーフオープンソケット]。ギガビットイーサネットで接続された2つのLinuxボックス間でテストを実行します[ただし、帯域幅はボトルネックではありません]。

Apacheの負荷テスト中に当たったLinuxカーネルの制限に興味があるかもしれません。私の場合、カーネルはいくつかの有用なエラーメッセージを生成したので、私のアドバイスはプログラムを書くことであり、制限に達しているように見える場合は、カーネルログに注意してください。

可能であれば、TCPではなくUDPを使用します。軽量である必要があるため、スケーラビリティが向上します。

nicはそれを処理できるはずですが、1秒あたり1万個の新しいTCP接続を持つという設計には疑問があります。接続をすばやく作成/破棄する場合は、a）接続をより長く開いたままにするか、b）代わりにUDPを使用する必要があります。

時々クエリを実行する必要がある1Mのクライアントがいて、負荷が毎秒10kに達する場合、UDPがおそらくより良い選択です。

1秒ごとにクエリを実行する必要があるクライアントが1万個しかない場合、既存の接続を開いたままにして再利用できます。これは、OSにはるかに優しく、毎回新しいハンドシェイクを必要としないため、レイテンシも大幅に少なくなります。

毎秒1万件のリクエストがある場合、とにかくフロントエンドのロードバランサーがあると思うので、それもテストする必要があります。

（注意：これはStack Overflowに属していたと思います）