これらのフレームワークが解決する問題がわかりません。それらは、Apache HTTPD、Tomcat、Mongrel などの HTTP サーバーの代替品ですか? それとももっとですか？なぜそれらを使用する必要があるのでしょうか...実世界の例をいくつか教えてください。チャット ルームやブロードキャスト サービスの例を数え切れないほど見てきましたが、これが、たとえば Java プログラムを設定してソケットを開き、リクエストごとにスレッドをディスパッチする場合とどう違うのかわかりません。
ノンブロッキング I/O については理解できたと思いますが、それがマルチスレッド Web サーバーとどのように違うのかわかりません。Node.jsの場合、スレッドは1つしかなく、複数のスレッドをジャグリングするよりも効率的かもしれないと読みましたが、これらのフレームワークと従来のWebサーバーの唯一の違いは何ですか?
ネットワーキングを行うコードを作成する場合は、これらのフレームワークのいずれかを使用できます。
たとえば、多人数参加型のビデオ ゲームを作成する場合、「リクエストごとにスレッドをディスパッチする Java プログラムをセットアップする」という選択肢はおそらくありません。多くのスレッドが驚くほど複雑であり、パフォーマンスも低いことをジャグリングします。「たくさんのスレッドを生成するだけ」という事実は言うまでもありませんが、Twisted などの管理ツールが不足しています。アル。のようtwistdに、ロギング、デーモン化、起動とシャットダウンなどを処理します。
または、ビルド自動化システムを作成する場合は、サブプロセスを非同期的に呼び出して制御する機能が役立ちます。プロセスを非同期的に生成すると、そのプロセスを簡単に強制終了し、その終了を適切に処理できます。スレッドを開始してそのスレッドでブロックすることによってそれを生成した場合、スレッドを停止することは本質的に安全ではないため、簡単に停止することはできません。
EventMachine と Twisted の両方を使用して、クライアント側のプログラムを作成することもできます。Web ベースではない GUI アプリケーションを作成していて、クライアントとサーバーで同じプロトコル実装を使用したい場合があります。
非同期フレームワークは非常に多くの異なるコンテキストで使用できるため、使用したい非同期フレームワークを使用する他のアプリケーション用に記述された既存のライブラリ コードがあるという理由だけで、それを Web アプリケーションで使用したい場合があります。または、Web アプリケーションのコードを、将来の架空の Web 以外のアプリケーションで再利用できるようにしたい場合もあります。この場合、Apache や Tomcat などを使用する場合と機能面でそれほど違いはありません。プログラムを編成するための、より一般的で再利用可能な方法を提供するだけです。
実際、イベントベースのフレームワークは、多くの io があり、CPU 操作が少ない状況に適していますが、db を待機するため、ほとんどの Web ページを定義します。他の例としては、YouTube のようなチャットやビデオがあります。1 つのスタックで、同時により多くのクライアントにサービスを提供できます。イベントベースのサーバーは、数十または数百の接続されたクライアントを処理できますが、そのような量のスレッドはマシンを殺します。実際に処理する必要がある場合は、効率が低下します。
接続ごとのスタックなし。プロセッサ コアごとに 1 つのスタックのみ。実際には一度に複数のことを実行できるわけではありません。恣意的に行ったり来たりするのではなく、何かがビジー状態になるまで待ってからタスクを切り替えてみませんか?