(一般に C10K 問題と呼ばれます)
特に Linux (epoll、signalfd、eventfd、timerfd..) と libev や libevent のようなライブラリに焦点を当てた、 c10k問題 (最終更新日: 2006 年 9 月 2 日)の解決策に関するより現代的なレビューはありますか?
最新の Linux サーバーで解決済みの問題と未解決の問題をすべて議論するものですか?
(一般に C10K 問題と呼ばれます)
特に Linux (epoll、signalfd、eventfd、timerfd..) と libev や libevent のようなライブラリに焦点を当てた、 c10k問題 (最終更新日: 2006 年 9 月 2 日)の解決策に関するより現代的なレビューはありますか?
最新の Linux サーバーで解決済みの問題と未解決の問題をすべて議論するものですか?
C10K の問題は通常、単一のサーバーを最適化しようとしていることを前提としていますが、参照記事が指摘しているように、「ハードウェアはもはやボトルネックではありません」。したがって、最初に取るべきステップは、単純にハードウェアの数を増やすことが最も簡単で安価にならないようにすることです。
1 秒あたり X クライアントにサービスを提供する 500 ドルのボックスがある場合、スループットを 2 倍にするために別の 500 ドルのボックスを購入する方がはるかに効率的です。元の箱から。もちろん、これはアプリがマルチサーバーに対応していること、負荷分散の方法を知っていることなどを前提としています...
偶然にも、ほんの数日前、Programming Reddit または Hacker News が次の記事について言及しました。
Java の初期の頃、私の C プログラミングの友人は、ブロッキング スレッドでソケット IO を実行したことを笑いものにしました。当時、代替手段はありませんでした。最近では、メモリとプロセッサが豊富にあるため、実行可能な戦略のようです。
この記事は 2008 年の日付なので、視野を数年引き上げることができます。
OP の質問に答えると、今日の同等のドキュメントは、単一のサーバーの負荷を最適化することではなく、オンライン サービス全体の負荷を最適化することであると言えます。その観点からすると、探しているのはドキュメントではなく、そうしたアーキテクチャやフレームワークを集めたライブ Web サイトであるほど、組み合わせの数は膨大です。そのような Web サイトが存在し、その名前はwww.highscalability.com です。
補足 1:
より多くのハードウェアを投入することが長期的な解決策であるという考えに反対します。
おそらく、パフォーマンスを「取得」するエンジニアのコストは、単一のサーバーのコストに比べて高くなります。スケールアウトするとどうなりますか? 100 台のサーバーがあるとします。サーバー容量が 10% 向上すると、月に 10 台のサーバーを節約できます。
マシンが 2 台しかない場合でも、パフォーマンスのスパイクに対処する必要があります。負荷がかかった状態で正常に機能が低下するサービスと機能しなくなるサービスの違いは、誰かが負荷シナリオの最適化に時間を費やしたことです。
補足2:
この投稿の主題は少し誤解を招くものです。CK10 ドキュメントは、毎秒 10,000 クライアントの問題を解決しようとはしていません。(1 秒あたりのクライアント数は、制限されたレイテンシーの下で持続的なスループットと共にワークロードも定義しない限り、無関係です。Dan Kegel は、そのドキュメントを書いたときにこれを認識していたと思います)。代わりに、並行サーバーを構築するためのアプローチの大要と、そのためのマイクロベンチマークとして見てください。おそらく、当時と現在で変わったことは、ある時点でサービスが静的ページを提供する Web サイト用であると想定できたことです。現在、このサービスは、noSQL データストア、キャッシュ、プロキシ、または何百ものネットワーク インフラストラクチャ ソフトウェアの 1 つかもしれません。
次の一連の記事もご覧ください。
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
彼は、かなりの量のパフォーマンス データと、10K 接続と 1M 接続をサポートするために実行しなければならなかった OS 構成作業を示しています。
30GB の RAM を搭載したシステムは、Erlang ベースのアプリ サーバーへの libevent フロントエンドを使用して、一種のソーシャル ネットワーク タイプのシミュレーションで 100 万の接続されたクライアントを処理できるようです。
スタンフォード大学の RamCloud プロジェクトをご覧ください: https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
彼らの目標は、1,000,000 RPC 操作/秒/サーバーです。彼らは、スループット目標の達成を妨げるシステムに存在するボトルネックに関する多数のベンチマークと解説を持っています。
libev は、自分自身と libevent に対していくつかのベンチマークを実行します...
Zed Shaw のpoll, epoll, science, and superpoll
[1] を読むことをお勧めします。epoll が必ずしも答えではない理由、poll を使用した方が良い場合がある理由、および両方の長所を最大限に活用する方法について説明します。