Cometのロングポーリングは、接続ごとに1つのスレッドを占有するため、Webサーバーには適していません。したがって、持続的接続を持つ多くのユーザーを持つことはできません。そうしないと、Webサーバーがクラッシュします。
これはHTML5のWebソケットでも同じですか？
持続的接続ごとに1つのスレッドを占有する場合、これでリソースの問題をどのように解決できますか？
質問する
1033 次
2 に答える
3
...接続ごとに1つのスレッドを占有するため
この仮定は完全に真実ではありません。詳細については、ここで私が与えた答えを参照してください。たとえば、IISでIAsyncHttpHandlerを使用して、クライアントごとにスレッドを使用せずに、ロングポーリングを実行することは完全に可能です。
于 2010-08-09T01:10:13.017 に答える
2
Spenderは正しいです。接続ごとにスレッド/プロセスを使用するのは、くだらないWebサーバー（たとえば、mpm_workerまたはmpm_preforkを使用するApache）のみです。
スマートCometまたはWebsocketsゲートウェイ（私は少し前にそのようなものを書きました）は、Proactor（スレッドの固定プールを使用）またはReactor（シングルスレッド）パターンのいずれかに基づくイベント駆動型アーキテクチャを備えています。ロングポーリングは、キープアライブHTTP接続（それをサポートするブラウザーの場合-それらの約99％）で実行する必要があります。その場合、Websocketと同様のパフォーマンス/スケーラビリティ特性が得られます。
于 2010-08-09T01:31:09.053 に答える