社内アプリ用のストリーミング ソリューションを構築しようとしていますが、障害を乗り越えるためのソリューションが空白になっています。現在、私の作業例ではAPEを使用していますが、制限により、ホスト マシンで実行中の外部プロセスを使用できないため、APE サーバーを実行できません。
代替手段を探していますが、これまでに見つけたものはすべて、サーバー上でプロセスを実行する必要がありました。
プロジェクトに関するいくつかの詳細。
node.jsがこれを処理できるか、または他のソリューションを処理できるかどうか、誰にもアイデアがありますか?
問題は、従来の Web サーバーがソケットごとのスレッド アプローチを使用して同時ユーザーを処理することです。これは、コメット/ロング ポーリング手法に常に最適であるとは限りません。(ただし、IIS の新しいバージョンには、独自の接続ハンドラーをプラグインする方法があります。これについては、後で詳しく説明します。)
従来の Web サーバーの場合、多くの場合、目標は接続を確立し、できるだけ早くユーザーに何かを提供し、次の接続に移動することです。接続が長時間続く場合は、大きなダウンロードや巨大なクエリなどの集中的な処理を行っている可能性がありますが、全体的に CPU を積極的に使用しているため、スレッド モデルがうまく機能しています。
コメット (ロング ポーリング) では、通常、イベントが発生するのを待つだけの Web サーバーに接続します。これにより、より多くの同時接続が促進されます。また、これらのユーザーの多くが、同じイベントが全面的に発生するのを待っている可能性もあります。
ユーザーが主にスピンして待機するようにスレッドを割り当てることは、この種のことには最適なモデルではありません。より優れたモデルは、イベント ループ ベースの Web サーバーであり、すべてを非同期的な方法で実行します。イベントを複数のユーザーにディスパッチする際に、クライアントごとにコストのかかるコンテキスト スイッチが必要になることはありません。これは、Node.js が (libevent をコアとして使用して) 構築されているものであり、Ruby Eventmachine、Twisted Python、Friendfeed の Tornado、Jetty、および C# ベースのManosサーバーと同様です。
そのため、Apache や古いバージョンの IIS などの従来の Web サーバーは、Comet のニーズに対して効率的な方法で機能しないため、comet を独自のプロセス カスタム サーバーで実行する方が有利な場合がよくあります。
.NET のスレッド プールは 25 の一般的なスレッドと 25 の IO スレッドに制限されている (そして、http 接続は IO スレッドを使用する) ため、標準の ASP.NET アプリは少しねじ込まれています。スレッド プールは .NET の他のすべてのものと共有されるため、実際にはそれよりもわずかに少なくなるように効果的に制限される場合があります。ただし、構成設定を使用してスレッドプールを増やすことはできますが、スレッドを投入するほどパフォーマンスが指数関数的に低下する傾向があります。次に、.NET の標準スレッド モニターを使用して、独自のコメット イベント ディスパッチを作成するだけです。
ただし、より新しいバージョンの IIS を実行する .NET アプリには希望の光があります。カスタムIAsyncHttpHandlerを作成できます。これがどのように機能するかについては、オンラインでいくつかの優れたガイドがあります。これにより、独自の接続プールを構築して、より効率的にクライアントにサービスを提供できます。これは完璧な解決策ではなく、自分で多くの配管を構築する必要があります。WebSyncは、このインターフェイスをラップし、操作できる高レベルのフレームワーク部分を提供する商用製品です。
WebSync はあなたにとって良い解決策です。IIS で実行されるため、外部プロセスは必要ありません。ここでチェックしてください。
PubNubを見たことがありますか？あなたがしていることを処理できるかもしれません。お金はかかりますが、無料のトランザクションもたくさんあります。予想される負荷の種類がわからない。
ロングプーリングを使用して、独自に実装できます。IIS では、25 の同時要求は問題になりません。APE がクライアントにストリーミングするものを見てみましょう。これを 100 行のコードで再実装する方法は非常に明確です (つまり、互換性のある形式でのシリアル化を意味します)。