問題タブ [c10k]

誰かが私が読むべき本/論文/記事を紹介してもらえますか？多数の同時接続（C10K以上）を処理するJavaで高性能RPCサーバーを作成したい場合は、フォールトトレラントであり、スケールアウトできます。高いスループットを維持しますか？ありがとう！

通常の条件下でc10k の問題を処理することに関して、Apache はどのようになっていますか? データがほとんどない非常に小さなスクリプトを実行している場合、または Apache を使用している場合はスケールアウトする必要がありますか?

バックグラウンドでは、リクエストを処理する特殊なソフトウェアを実行しているいくつかのサーバーによって重労働が行われますが、フロントとして Apache を使用したいと考えています。これは実行可能な計画ですか？

現在展開されている Web サーバーでは、そのパフォーマンスの一般的な制限は何ですか?

意味のある答えは、1 秒あたり 100、1,000、10,000、100,000、または 1,000,000 リクエストのいずれかになると思いますが、今日はどれが正しいでしょうか? 5年前に正しいのはどれ? 5年後にはどれが期待できますか? (つまり、帯域幅、ディスク パフォーマンス、CPU パフォーマンスなどの傾向が回答にどのように影響するか)

重要な場合は、HTTP over TCP がアクセス プロトコルであるという事実を考慮する必要があります。OS、サーバー言語、およびファイルシステムの効果は、最良の組み合わせであると想定する必要があります。

ディスクには、静的に提供される小さな一意のファイルが多数含まれていると想定します。メモリ キャッシュの影響を排除するつもりであり、その CPU 時間は主にネットワーク/プロトコル情報を組み立てるために使用されます。これらの仮定は、リクエストがある程度の帯域幅、CPU 時間、およびディスク アクセスを必要とする「最悪のケース」の見積もりに向けて回答を偏らせることを目的としています。

私は、桁違いに正確なものだけを探しています。

ソケットプログラミングでマルチクライアント機能をサポートするための複数のスレッドを作成できます。それはうまく機能しています。しかし、10,000のクライアントが接続したい場合、私のサーバーはそれほど多くのスレッドを作成できません。

これらすべてのクライアントを同時にリッスンできるようにスレッドを管理するにはどうすればよいですか？

また、この場合、サーバーが特定のクライアントに何かを送信したい場合、それはどのように可能ですか？

Linux で高性能サーバーを作成するために必要な、スレッド プーリング、ソケット ポーリングなどを行う C++ (または単純な C) ライブラリを見つけたことを覚えています。(そして、このライブラリはBoostそのものではありませんでしたが、Boost を使用していた可能性があります。)

いつものことですが、図書館の名前が思い出せません。推測はありますか？

更新:それはACEではありませんでし た。

C で作成するデーモンがあり、20 ～ 150K の TCP 接続を同時に処理する必要があります。それらは長時間実行される接続であり、切断されることはめったにありません。それらは常に非常に少量のデータを送信しますが (スティミュラス/レスポンス プロトコルであっても、MTU を超えることはめったにありません)、それらに対する応答時間は非常に重要です。現在の UNIX コミュニティは、大量のソケットを取得するために何を使用しており、それらの応答の待ち時間を最小限に抑えているのだろうかと思っています。フォーク ワーカー プール、スレッド (接続ごと)、静的サイズのスレッド プールへの接続の多重化を中心に展開する設計を見てきました。助言がありますか？

利用可能なメモリ、帯域幅、CPU、そしてもちろんネットワーク接続によって課せられる制限があります。しかし、それらは多くの場合、垂直方向にスケーリングできます。Linux に他に制限要因はありますか? カーネルを変更せずにそれらを克服できますか? 何もなければ、制限要因はギガビット イーサネットになるのではないかと思います。しかし、効率的なプロトコルの場合、それを圧倒するには 50K の同時接続が必要になる可能性があります。私がそんなに高くなる前に、他の何かが壊れるでしょうか？

ソフトウェア udp および/または tcp/ip ロード バランサーが必要だと考えています。残念ながら、http プロトコルを除いて、オープンソース コミュニティにはそのようなものは存在しないようです。しかし、epoll を使用してこれを作成することは、私の能力を超えているわけではありません。スケールに合わせるには多くの微調整が必​​要になると思いますが、それは段階的に行うことができる作業であり、私はそのための優れたプログラマーになるでしょう.

ピーク時には約 250/rps を提供する必要があります。私たちが行っているのは、画像の URL を受け取り、memcache から画像を取り出し、Apache 経由で返すことです。

私たちの現在のシステムは、メモリが 4 GB のデュアルコア マシンです。memcache のイメージ用に 2 GB、Apache 用に 2 GB です。しかし、ピーク時には非常に高い負荷 (20 ～ 30) が見られます。Apache によって報告された平均応答時間は、1 要求あたり 30 ～ 80 ミリ秒であり、メモリから提供される単純な Apache 要求としてはやや遅いようです。

これのためのより良いツールはありますか? IO 待機がそれを妨げていたため、ディスクからの提供はオプションではないため、メモリに移動しました。CDN はどのように行うのですか?

編集:まあ、システムはこのように機能します。リクエストが届くと、「キュー」をチェックして、このリクエストを以前に見たかどうか、およびイメージを (ディスクから... またはメモリから) 提供したことがあるかどうかを確認します。そうでない場合は、memcached キューでそのリクエストのカウンターをインクリメントし、実際にイメージを生成してメイン サーバーに保存するワーカー マシンがあります。そのため、現在、リクエストが来ると、memcached db が存在するかどうかを確認してから、実際の画像データベースの別の db に接続します。画像がディスク上にあるとき、file_exist 関数だけでも完了するまでに 30 ミリ秒以上かかることがわかったので、メモリに移動しました。イメージを ramdisk に移動した場合、file_exist の速度が向上しますか?それとも、イメージを探し出す必要があるかどうかを確認するために最初のチェックが必要ですか?

(一般に C10K 問題と呼ばれます)

特に Linux (epoll、signalfd、eventfd、timerfd..) と libev や libevent のようなライブラリに焦点を当てた、 c10k問題 (最終更新日: 2006 年 9 月 2 日)の解決策に関するより現代的なレビューはありますか?

最新の Linux サーバーで解決済みの問題と未解決の問題をすべて議論するものですか?