Node.jsのイベント駆動型の何がそんなに違いますか？ ASP.NetのHttpAsyncHandlerでこれを行うことはできませんか？
私はWebプログラミングをあまり経験しておらず、実際にはNode.jsで何もコーディングしていません。 event-driven approach に興味があります。それは良いようです。
この記事では、スレッドベースのアプローチを使用してリクエストを処理するときに発生する可能性のあるいくつかの悪いことについて説明し、代わりにイベント駆動型のアプローチを選択する必要があります。スレッドベースでは、食料/資源の準備が整うまで、レジ/スレッドは固定されます。イベントドリブンでは、レジ係がリクエストキューのどこかに送ってくれるので、食べ物を待っている間に他のリクエストをブロックすることはありません。スレッドベースのブロッキングをスケーリングするには、スレッドの数を増やす必要があります。私には、これはスレッド/スレッドプールを適切に使用しないことの悪い言い訳のように思えます。
IHttpAsyncHandlerを使用して適切に処理できませんでしたか？ ASP.Netは要求を受け取り、ThreadPoolを使用してハンドラー（BeginProcessRequest）を実行し、その内部でコールバックを使用してファイル/データベースを読み込みます。そのスレッドは他のリクエストを自由に処理できるはずです。ファイルの読み取りが完了すると、ThreadPoolが再度アクションに呼び出され、残りの応答が実行されます。私にとってそれほど違いはないのに、なぜそれほどスケーラブルではないのですか？
私が知っているスレッドベースの欠点の1つは、スレッドを使用するとより多くのメモリが必要になることです。しかし、これらを使用した場合のみ、複数のコアの利点を享受できます。 Node.jsがスレッド/コアをまったく使用していないことを疑います。
したがって、イベント駆動型とスレッドベース（「Javascriptとすべてのブラウザーだから...」という引数を持たないでください）だけに基づいて、Node.jsを使用する代わりにNode.jsを使用することの実際の利点を誰かが指摘できますか？既存の技術？
それは長い質問でした。ありがとう：）
まず、Node.jsはマルチスレッドではありません。これは重要。スレッド環境で完全に動作するプログラムを設計するには、非常に才能のあるプログラマーでなければなりません。スレッドは難しいだけです。
適切に設計されていないスレッドプロジェクトを維持するには、godである必要があります。非常に多くの問題があり、非常に大きなプロジェクトでは回避するのが難しい場合があります。
次に、プラットフォーム全体が非同期で実行されるように設計されました。すべての単一のIO相互作用が非同期であるASP.NETプロジェクトを見たことがありますか？簡単に言えば、ASP.NETはイベント駆動型に設計されていません。
次に、オープン接続ごとに1つのスレッドがあるという事実と、スケーリングの問題のために、メモリフットプリントがあります。間違っているが、ASP.NETの接続ごとに新しいスレッドを作成しないようにする方法がわからない場合は修正してください。
もう1つの問題は、Node.jsリクエストが使用されていないとき、またはIOを待機しているときにアイドル状態になることです。一方、C＃スレッドはスリープします。現在、スリープできるスレッドの数には制限があります。 Node.jsでは、1台の開発マシンで同時に10kクライアントを同時に簡単に処理できます。 1台の開発マシンで10kスレッドを並行して処理してみます。
言語としてのJavaScript自体により、非同期コーディングが容易になります。まだC＃2.0を使用している場合、非同期構文は非常に苦痛です。 Action<>とFunction<>を至る所で定義し、コールバックを使用している場合、多くの開発者は単に混乱するでしょう。イベント形式で記述されたASP.NETプロジェクトは、平均的なASP.NET開発者がメンテナンスすることはできません。
スレッドとコアに関しては。 Node.jsはシングルスレッドであり、複数ノードプロセスを作成することで拡張します。 16コアがある場合、node.jsサーバーの16インスタンスを実行し、その前に単一のNode.jsロードバランサーがあります。 （もしあなたが望むならnginxロードバランサーかもしれません）。
これはすべて、最初から非常に低いレベルでプラットフォームに書き込まれました。これは、後の段階で追加される機能ではありませんでした。
その他の利点
Node.jsには上記よりも多くの機能があります。 Node.jsがイベントループを処理する方法がASP.NETの非同期機能を使用するよりも優れているのは、上記の理由だけです。
- パフォーマンス。これは速い。本当に速い。
- Node.jsの大きな利点の1つは、低レベルAPIです。あなたには多くのコントロールがあります。
- HTTPサーバー全体をコードに直接統合し、IISに外部委託します。
- NginxとApacheの比較全体があります。
- C10Kチャレンジ全体は、IISではなくノードによって適切に処理されます
- AJAXおよびJSON通信は自然で簡単に感じられます。
- Node.jsの優れた点の1つは、リアルタイム通信です。それのために作られました。
- ドキュメントベースのnosqlデータベースとうまく連携します。
- TCPサーバーも実行できます。ファイル書き込みアクセスを実行できます。サーバー上で任意のUNIXコンソールコマンドを実行できます。
- CouchDBやmap/reduceなどを使用して、javascriptでデータベースをクエリします。クライアントをJavaScriptで記述します。 Webスタックでの開発中にコンテキストスイッチはありません。
- コミュニティ主導のオープンソースモジュールの豊富なセット。 node.jsのすべてはオープンソースです。
- フットプリントが小さく、依存関係がほとんどありません。 node.jsソースを自分でビルドできます。
Node.jsの欠点
それは難しい。若いです。 skilledJavaScript開発者として、Node.jsを使用してWebサイトを作成するのは、その低レベルの性質と私が持っている制御レベルのためだけです。まるでCのように感じます。私に使用されるか、私を吊るすかのいずれかの、多くの柔軟性とパワー。
APIは凍結されていません。急速に変化しています。 Node.jsが変更されるため、5年後に大規模なWebサイトを完全に書き直さなければならないことを想像できます。それは可能です。node.jsウェブサイトのメンテナンスは安くないことを知っておく必要があります。
さらに読む
http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
Node.jsとASP.Netおよび非同期プログラミングに関して多くの誤解があります。 非ブロッキングIO ASP.NETで を実行できます。ほとんどの人は、.Net 2.0以降で開始/終了パターンを使用してWebサービス呼び出しまたはその他のI/Oバインド操作を行うと、 。NetフレームワークがWindows iocompletionポートを使用する であることを知りません。 IO完了ポートは、Windowsオペレーティングシステムが非ブロッキングIOをサポートする方法であり、IO操作が完了した理由でアプリスレッドが解放されます。興味深いことに、node.jsは、Cygwinを介したWindowsでの最適ではない非ブロッキングIO実装を使用します。新しいWindowsバージョンがロードマップ上にあり、MicrosoftのガイダンスではIO補完ポートを使用します。その時点で違いはありません。
ADO.NETでノンブロッキングデータベース呼び出しを行うこともできますが、NHibernateやEntity FrameworkなどのORMツールに注意してください。それらは依然として非常に同期的です。
同期IO（ブロッキング）により、制御フローがより明確になり、このため人気があります。コンピュータ環境がマルチスレッド化されている理由は、これと表面的な関係があるだけです。より一般的には、複数のCPUのタイムシェアリングと使用率に関連しています。
スレッドが1つしかない場合、長時間の操作中に飢vが発生する可能性があり、これはIOと複雑な計算の両方に関連する可能性があります。したがって、経験則は1つのスレッドprです。ノンブロッキングIOを利用する場合は、十分なスレッドプールサイズを考慮して、単純な要求が存在する場合、より複雑な操作に飢えないようにしてください。また、複数のスレッドにより、複雑な操作を複数のCPUに簡単に分割できます。 node.jsのようなシングルスレッド環境は、アクションを調整するために、より多くのプロセスとメッセージの受け渡しを通じてのみマルチコアプロセッサを利用できます。
個人的には、node.jsのような追加のテクノロジーを導入する説得力のある議論はまだ見ていません。ただし、正当な理由があるかもしれませんが、ASP.NETでも実行できるため、非ブロッキングIOを介して多数の接続を処理することとはほとんど関係ありません。
BTW tamejsは、新しい.Net Async CTPと同様に、nodejsコードをより読みやすくするのに役立ちます。
Node.jsコミュニティとASP.NETコミュニティの文化的な違いを軽視するのは簡単です。確かに、IHttpAsyncHandler existsであり、.NET 1.0から使用されているので良いこともありますが、Node.jsに関するコードと説明はすべて非同期I/Oについてのものであり、明らかにそうではありません.NETになります。 LINQ To SQLを使用したいですか？ 缶の種類 、種類。ものを記録したいですか？ 「CSharp DotNet Logger」が動作する可能性があります 、おそらく。
そうです、IHttpAsyncHandlerがあり、本当に注意すれば、どこかでブロッキングI/Oをトリップすることなくイベント駆動型のWebサービスを書くことができるかもしれませんが、多くの人が使用している印象は本当に得られませんそれ（そして確かにASP.NETアプリを書くための顕著な方法ではありません）。対照的に、Node.jsはすべてイベントI/O、すべてのコード例、すべてのライブラリに関するものであり、人々がそれを使用する唯一の方法です。したがって、イベントI/Oモデルが実際に最後まで機能することに賭けようとする場合、おそらくNode.jsを選択するでしょう。
現在の時代の技術の改善と以下のリンクを読むと、専門知識の問題であり、重要な特定のシナリオに従って完璧なミックスを選択することができます。 NodeJSは成熟しつつあり、ASP.NET側にはASP.NET MVC、WebAPI、SignalRなどがあり、状況を改善しています。
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ および
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
ありがとう。