Nodejsについて
5089 ワード
非同期I/O
オペレーティングシステムでは、プログラム実行の空間はカーネル空間とユーザ空間に分けられます.私たちがしばしば提示する非同期I/Oは、ユーザ空間におけるプログラムがカーネル空間のI/O操作に依存せずに、後続のタスクを実行することができる.以下の疑似コードは、ディスクからファイルを取得し、ネットワークからファイルを取得する動作を模倣している.非同期I/Oの効果は、get FileFrom Netの呼び出しがget Fileの呼び出しの終了に依存しないことです.
非同期I/Oの必要性
アプリケーションを起動しやすくするように設計する言語があります.プログラムを同期I/Oのモデルとして設計しました.これは、プログラム中の後続のタスクはI/Oの完了を待つ必要があるということです.I/Oが完了するまでは、CPUを十分に利用できません.CPUを十分に利用し、I/Oを並列させるために、現在は目的を達成できる2つの方法があります.マルチスレッド単一プロセスマルチスレッドの設計は、共有されたプログラム空間において、並列処理タスクを実現することで、CPUを十分に利用する効果がある.マルチスレッドの欠点は、実行時のコンテキスト交換のオーバヘッドが大きく、状態同期(ロック)の問題である.同様に、プログラムの作成と呼び出しを複雑にします. 単スレッドマルチプロセスは、マルチスレッドによる使用の不便を避けるために、単スレッドホールドコールを簡単化する言語を選択し、マルチプロセスを起動する方式を採用して、CPUを十分に利用し、全体的な並列処理能力を向上させる.その欠点は、業務ロジックが複雑な場合(複数のI/O呼び出しを含む)であり、業務ロジックが複数のプロセス間に分布しないため、事務処理時はマルチスレッドモードよりもはるかに長い. 前者は性能の最適化にまだ旋回の余地があります.後者のやり方は純粋にサーバーを三倍にする行為です.また、現在の大型Webアプリケーションでは、単独機の場合は非常にまれであり、一つの事務はしばしばインターネットを介して何回か最終的な処理を完了する必要があります.ネットワーク速度が理想的でないと、mとnの値が大きくなり、同期I/Oの言語モデルが最も脆弱な状態を表します.この場合の非同期I／Oはその利点を表し、max(m,n)の時間オーバーヘッドはmおよびn値の成長による性能問題を効果的に緩和することができる.並列タスクが多い場合、m＋n＋…とmax(m,n,…)の間のどちらが優れているかは一目瞭然です.この公式からは、非同期I/Oが分散環境においていかに重要であるかを知ることができ、Node.jsがこの非同期I/Oを天然に支持していることが、多くのクラウドコンピューティングメーカーの愛顧の根本的な原因である.
非同期I/Oに対するオペレーティングシステムのサポート
Node.jsを聞いた時、私達はよく突拍子もなく、渋滞もなく、折り返しも聞いています.事件という言葉が混ざっています.その中で、異歩と非閉塞は同じように聞こえる.実際の効果の観点から,非同期と非閉塞の両方が並列I／Oの目的を達成した.しかし、計算機カーネルI/Oから言えば、非同期とブロッキング/非ブロッキングは実際には別のことです. I/Oの渋滞と非ブロッキングモードのI/Oは、I/Oが完了するまでアプリケーションの待ち時間を引き起こす.I/O操作を非ブロッキングモードに設定することもできます.アプリケーションの呼び出しは、本当のデータが得られない時にすぐに戻ってしまう可能性があります.このため、アプリケーションは何度かの呼び出しが必要です.I/O操作が完了したことを確認することができます. I/Oの同期は、非同期I/Oと同期し、非同期的にアプリケーションに現れる.閉塞I/O呼び出しを行うと、アプリケーションが呼び出しの完了を待つプロセスは同期状態です.逆にI/Oが非ブロッキングモードの場合、アプリケーションは非同期です. 非同期I/Oとポーリング技術
非ブロッキングI/O呼び出しを行う場合、完全なデータを読むためには、アプリケーションは複数のポーリングを行う必要があります.データの読み込みが完了し、次のステップの操作ができるようにすることができます.ポーリング技術の欠点は、アプリケーションが積極的に起動し、CPUの時間スライスを多く占用することになり、性能が比較的低いことである.現存するポーリング技術は以下の通りである. read select poll epoll pspelect kqueue readは最も性能が低いもので、I/Oの状態を確認するためにリピート調整を行うことによって、完全なデータ読み取りが完了します.selectは、ファイル記述子上のイベント状態を判断するための改良案である.オペレーティングシステムはまた、poll、epollなどの多重化技術を提供し、性能を向上させる.ポーリング技術は非同期I/Oを満足させ、完全なデータ取得を保証する.しかし、アプリケーションの場合、まだ同期を計算することができます.アプリケーションはまだI/Oの状態を積極的に判断する必要がありますので、CPU時間がかかります.
前の方法はreadを呼び出してポーリングを繰り返します.最終的に成功するまでは、ユーザプログラムは多くのCPUを占有し、性能はより低いです.実際には、このような繰り返しreadポーリングの代わりに、オペレーティングシステムが状態判断を行うためのselect方法を提供する.select内部では、ファイル記述子のイベント状態を確認することにより、データが完全に読み込まれているかどうかを判定します.しかし、アプリケーションにとっては、まだ同期と見なされています.アプリケーションはまだI/Oの状態を判断するために積極的に必要であり、CPUの待ち時間も多くかかり、selectもポーリングです.
理想的な非同期I/Oモデル
理想的な非同期I/Oは、ポーリングを必要とせずにアプリケーションから非同期呼出しを開始し、さらに次のタスクを処理し、I/Oが完了したら、信号またはコールバックによってデータをアプリケーションに転送すれば良い.
幸いにも、Linuxでは、非同期のI／O方式(AIO)が信号またはコールバックによってデータを伝達する方法がある.残念なことに、Linuxの下にはこのようなサポートがあります.(AIOはカーネルI/OのOuDIRECT方式の読み取りのみに対応しており、システムキャッシュを利用できなくなります.参照:http://forum.nginx.org/read.php?2は、113524,113587〓〓msg-13587以上は非閉塞I/Oに基づいて設定されています.他の理想的な非同期I/Oは閉塞I/Oを採用していますが、マルチスレッドに参加して、I/Oを複数のスレッドに分けて、スレッド間の通信を利用して非同期をシミュレートしています.GlibcのAIOがその典型です.http://www.ibm.com/developerworks/linux/library/l- async/ですが、残念なことに、耐えられないいくつかの欠陥とバグがあります.簡単に説明できます.Linuxプラットフォームには完璧な非同期I/Oサポートがありません.幸い、libevの著者であるMark Alexander Lehmannが、異歩I/Oのライブラリ:libeioを再実現しました.libeioの本質はそのまま採用されています.スレッド池と閉塞I/Oがシミュレートした非同期I/O.Windowsプラットフォームの状況はどうですか?実は、Windowsならではのカーネル非同期IO案があります.IOCPの考えは本当の非同期I/O案です.非同期方法を呼び出して、I/O完了通知を待っています.IOCP内部は依然としてスレッドを通じて実現しています.これらのスレッドはシステムカーネルキャッチャーによって管理されています.IOCPは違います.の非同期モデルはNode.jsの非同期呼出モデルとよく似ています.以上の2つの案はNode.jsが選択した非同期I/O案です.Windowsプラットフォームと***nixプラットフォームの違いにより、Node.jsは抽象的なパッケージ層としてlibuvを提供しています.すべてのプラットフォームの互換性の判定はこの段階で行われます.上位のNode.jsと下位層のそれぞれのibeliev/IOlive CPを保証します.独立しています.Node.jsはコンパイル中にプラットフォーム条件を判断し、unixディレクトリまたはwinディレクトリ下のソースファイルを選択的にコンパイルしてターゲットプログラムに入れます.
締め括りをつける
Node.jsの性能がいいです.創業者Ryan Dahlによると、性能はNode.jsが考慮する重要な要素です.Rubyや他の仮想マシンではなくC++とV 8を選択するのも性能に基づく目的です.Node.jsはデザインも大胆です.シングルプロセス、シングルスレッドモードで運行しています.これはJavascriptの運行方式と一致します.イベント駆動機構は、Node.jsが内部の単一スレッドを通じてイベントの循環キューを効率的に維持することによって実現され、マルチスレッドのリソース占有と文脈切り替えがないことは、大規模なhttp要求に直面していることを意味し、Node.jsはイベント駆動によってすべてを解決し、従来の言葉に慣れたネットワークサービス開発者はマルチスレッドの合併と協力に非常に詳しいかもしれないが、Node.jsに直面している.その特徴を受け入れて理解する必要があります.このような設計は負荷の圧力がCPU(イベントサイクル処理)に集中すると推測できますか?メモリ(Java仮想マシンがOutOfMemoryを投げたのを覚えていますか?)ではなく、実際に見ると、宝共有データプラットフォームチームのNode.jsに対する性能テストを見てみませんか?物理機器構成:RHEL 5.2、CPU 2.2 GHz、メモリ4 G Node.jsアプリケーションシーン:MemCacheエージェント、毎回100バイトデータ を取る接続池のサイズ:50 合併ユーザ数:100 試験結果(socketモード):メモリ(30 M)、QPS(16700)、CPU(95%) (利点)Nodeはイベント駆動とブロッキングなしに基づいているので、同時要求を処理するのに非常に適しているので、Nodeに構築されたプロキシは、Rubyなどの他の技術に比べて実現される.また、Nodeプロキシと相互作用するクライアントコードは、Javascript言語で作成されていますので、クライアントとサーバー側は同じ言語で作成されています.これは素晴らしいことです. (欠点)Nodeは比較的新しいオープンソースのプロジェクトですので、不安定です.常に変化しています.そして十分なサードパーティのサポートが足りないです.Ruby/Railsの当時のように見えます.
オペレーティングシステムでは、プログラム実行の空間はカーネル空間とユーザ空間に分けられます.私たちがしばしば提示する非同期I/Oは、ユーザ空間におけるプログラムがカーネル空間のI/O操作に依存せずに、後続のタスクを実行することができる.以下の疑似コードは、ディスクからファイルを取得し、ネットワークからファイルを取得する動作を模倣している.非同期I/Oの効果は、get FileFrom Netの呼び出しがget Fileの呼び出しの終了に依存しないことです.
getFile("file_path");
getFileFromNet("url");
非同期I/Oの必要性
アプリケーションを起動しやすくするように設計する言語があります.プログラムを同期I/Oのモデルとして設計しました.これは、プログラム中の後続のタスクはI/Oの完了を待つ必要があるということです.I/Oが完了するまでは、CPUを十分に利用できません.CPUを十分に利用し、I/Oを並列させるために、現在は目的を達成できる2つの方法があります.
非同期I/Oに対するオペレーティングシステムのサポート
Node.jsを聞いた時、私達はよく突拍子もなく、渋滞もなく、折り返しも聞いています.事件という言葉が混ざっています.その中で、異歩と非閉塞は同じように聞こえる.実際の効果の観点から,非同期と非閉塞の両方が並列I／Oの目的を達成した.しかし、計算機カーネルI/Oから言えば、非同期とブロッキング/非ブロッキングは実際には別のことです.
非ブロッキングI/O呼び出しを行う場合、完全なデータを読むためには、アプリケーションは複数のポーリングを行う必要があります.データの読み込みが完了し、次のステップの操作ができるようにすることができます.ポーリング技術の欠点は、アプリケーションが積極的に起動し、CPUの時間スライスを多く占用することになり、性能が比較的低いことである.現存するポーリング技術は以下の通りである.
前の方法はreadを呼び出してポーリングを繰り返します.最終的に成功するまでは、ユーザプログラムは多くのCPUを占有し、性能はより低いです.実際には、このような繰り返しreadポーリングの代わりに、オペレーティングシステムが状態判断を行うためのselect方法を提供する.select内部では、ファイル記述子のイベント状態を確認することにより、データが完全に読み込まれているかどうかを判定します.しかし、アプリケーションにとっては、まだ同期と見なされています.アプリケーションはまだI/Oの状態を判断するために積極的に必要であり、CPUの待ち時間も多くかかり、selectもポーリングです.
理想的な非同期I/Oモデル
理想的な非同期I/Oは、ポーリングを必要とせずにアプリケーションから非同期呼出しを開始し、さらに次のタスクを処理し、I/Oが完了したら、信号またはコールバックによってデータをアプリケーションに転送すれば良い.
幸いにも、Linuxでは、非同期のI／O方式(AIO)が信号またはコールバックによってデータを伝達する方法がある.残念なことに、Linuxの下にはこのようなサポートがあります.(AIOはカーネルI/OのOuDIRECT方式の読み取りのみに対応しており、システムキャッシュを利用できなくなります.参照:http://forum.nginx.org/read.php?2は、113524,113587〓〓msg-13587以上は非閉塞I/Oに基づいて設定されています.他の理想的な非同期I/Oは閉塞I/Oを採用していますが、マルチスレッドに参加して、I/Oを複数のスレッドに分けて、スレッド間の通信を利用して非同期をシミュレートしています.GlibcのAIOがその典型です.http://www.ibm.com/developerworks/linux/library/l- async/ですが、残念なことに、耐えられないいくつかの欠陥とバグがあります.簡単に説明できます.Linuxプラットフォームには完璧な非同期I/Oサポートがありません.幸い、libevの著者であるMark Alexander Lehmannが、異歩I/Oのライブラリ:libeioを再実現しました.libeioの本質はそのまま採用されています.スレッド池と閉塞I/Oがシミュレートした非同期I/O.Windowsプラットフォームの状況はどうですか?実は、Windowsならではのカーネル非同期IO案があります.IOCPの考えは本当の非同期I/O案です.非同期方法を呼び出して、I/O完了通知を待っています.IOCP内部は依然としてスレッドを通じて実現しています.これらのスレッドはシステムカーネルキャッチャーによって管理されています.IOCPは違います.の非同期モデルはNode.jsの非同期呼出モデルとよく似ています.以上の2つの案はNode.jsが選択した非同期I/O案です.Windowsプラットフォームと***nixプラットフォームの違いにより、Node.jsは抽象的なパッケージ層としてlibuvを提供しています.すべてのプラットフォームの互換性の判定はこの段階で行われます.上位のNode.jsと下位層のそれぞれのibeliev/IOlive CPを保証します.独立しています.Node.jsはコンパイル中にプラットフォーム条件を判断し、unixディレクトリまたはwinディレクトリ下のソースファイルを選択的にコンパイルしてターゲットプログラムに入れます.
締め括りをつける
Node.jsの性能がいいです.創業者Ryan Dahlによると、性能はNode.jsが考慮する重要な要素です.Rubyや他の仮想マシンではなくC++とV 8を選択するのも性能に基づく目的です.Node.jsはデザインも大胆です.シングルプロセス、シングルスレッドモードで運行しています.これはJavascriptの運行方式と一致します.イベント駆動機構は、Node.jsが内部の単一スレッドを通じてイベントの循環キューを効率的に維持することによって実現され、マルチスレッドのリソース占有と文脈切り替えがないことは、大規模なhttp要求に直面していることを意味し、Node.jsはイベント駆動によってすべてを解決し、従来の言葉に慣れたネットワークサービス開発者はマルチスレッドの合併と協力に非常に詳しいかもしれないが、Node.jsに直面している.その特徴を受け入れて理解する必要があります.このような設計は負荷の圧力がCPU(イベントサイクル処理)に集中すると推測できますか?メモリ(Java仮想マシンがOutOfMemoryを投げたのを覚えていますか?)ではなく、実際に見ると、宝共有データプラットフォームチームのNode.jsに対する性能テストを見てみませんか?