php - 计算密集型和IO密集型

Question

请问为什么到底什么样的业务是计算密集型，什么样的业务是IO密集型？为什么说PHP最初设计是针对计算机密集型的，node.js是针对IO密集型的？

Answer 1

昨日、Liao Xuefeng のブログの「計算集約型と IO 集約型」に関する章を読みました。その抜粋は次のとおりです。

タスクは、

コンピューティング集約型と IO 集約型に分けることができます。

コンピューティング集約型

のタスクは、pi の計算、ビデオの高解像度デコードなど、大量の計算を必要とし、CPU リソースを消費するという特徴があり、すべて CPU のコンピューティング能力に依存しています。この種の計算負荷の高いタスクはマルチタスクでも完了できますが、タスクの数が増えるとタスクの切り替えに時間がかかり、タスクを実行する際の CPU の効率が低下します。 CPU の使用、コンピューティング集約型タスク 同時タスクの数は CPU コアの数と同じである必要があります。 コンピューティング集中型のタスクは主に CPU リソースを消費するため、コードの実行効率が非常に重要です。 Python などのスクリプト言語は実行効率が非常に低く、計算負荷の高いタスクにはまったく適していません。計算負荷の高いタスクの場合は、C 言語で記述することをお勧めします。

IO 集中型

、ネットワークおよびディスク IO を伴うタスクはすべて IO 集中型タスクです。このタイプのタスクの特徴は、CPU 消費量が非常に少なく、タスクのほとんどが IO 操作の完了を待機していることです。 (IO 速度が CPU やメモリの速度よりもはるかに遅いため)。 IO 集中型のタスクの場合、タスクが多いほど CPU 効率は高くなりますが、制限があります。最も一般的なタスクは、Web アプリケーションなどの IO 集中型のタスクです。 IO 集中型のタスクの実行中は、時間の 99% が IO に費やされ、CPU に費やされる時間はほとんどありません。そのため、Python のような非常に遅いスクリプト言語を非常に高速な C 言語に置き換えることは、完全に操作効率を向上させます。改善することはできません。 IO 集中型のタスクの場合、開発効率が最も高い (コード量が最も少ない) 言語が最適な言語であり、最も悪い言語は C 言語です。

Answer 2

Node.js 言語の概念を説明するよく使われる解説があります 非阻塞，事件驱动、それはおおよそ次のようなものです:

レストランに食事をするとき、レストランのウェイターは注文を受けてからメニューをキッチンに直接渡し、キッチンで待たずにすぐに次の客のところに行きます(阻塞）。直到烹饪结束后，厨师大喊“来拿菜”（事件）。服务员跑回厨房，把菜品端到你的桌子上（事件处理/回调)

この栗では、単純に次のように理解できます: ウェイターは CPU，而厨房的工作就是I/O に相当します。レストランでのウェイターの仕事は、「料理を待つ」時間のほとんどが「キッチンを待つ」ことに費やされるのは明らかです。これは、今日のほとんどの Web サイトの状況と似ています。Web サイトは通常、それほど複雑な操作を行う必要はありませんが、画像やビデオの読み取りなどのデータベース クエリなどの I/O 処理の待機に多くの時間を費やす必要があります。 。

そこで、Node.js は、従来の Web サービスでの「リクエストが来るたびにスレッドを開いて個別に処理する」という慣行を放棄し、代わりに、デフォルトでは単一のスレッドのみが高い負荷量に耐えることができるイベント駆動型モデルを採用しました。同時性の。

したがって、この状況では、次のように言います: Node.js 更适合 IO密集型的任务处理。

しかし、たとえば上記の栗を変えると、レストランではなく銀行を開くことになります。顧客が来て、指定された金額の引き出しを要求するたびに、ウェイターとして、顧客の口座レベルに基づいて金利を計算し、利息を計算し、配当金を計算する必要があります...（ランダムな比喩はそうではないかもしれません）適切）、「お金を引き出して顧客に渡す」 この動作自体は複雑ではありません。

現時点では、レストランのように多数の顧客を処理するのに 1 人のウェイターに依存することは期待できません。各リクエストにはウェイターの多大な時間が必要となるからです (これは避けられません 阻塞)。現時点では、PHP などの従来のモデルの方が適している可能性があります。

以上、あなたの混乱を解消できれば幸いです

Answer 3

• IO 集中型: ネットワーク送信、データベース呼び出しなど、大量の IO を使用するアプリケーション。ほとんどの Web アプリケーションは次のようなものです

• 計算集約型: 名前が示すように、大量の CPU 計算を必要とするタイプのアプリケーションです。クラウド コンピューティングなどのアプリケーションは、このカテゴリに分類されます。

Answer 4

計算量が多いとは何ですか? たとえば、SQLite データベースを Linux メモリ ファイル システム /dev/shm に配置して、100 万のデータに対して SELECT クエリ操作を実行すると、この SELECT クエリは、B+ ツリー インデックスを使用する場合に実行されます。 B+ ツリー インデックスのバイナリ検索は、典型的な集中的な計算です。インデックスが使用されていない場合、単にテーブル全体をスキャンすることも集中的な計算になります。そのため、パフォーマンスを確保しメモリを制御するために、リレーショナル データベースなどは通常 C/C++ を使用して実装されます。使い方。

IO 集中型とは何ですか? たとえば、SQLite データベースはメモリ内ではなく、通常の機械ディスク上にあり、CPU がどれほど高速であっても、書き込み操作 (INSERT/UPDATE/DELETE) は典型的な IO 集中型操作です。 SQLite エンジンは高速ですが、メカニカル ディスクの書き込み操作によっても遅くなります。そのため、同時実行性のために、SQLite では WAL(write-ahead log) ログ先行書き込みサポートが導入されました。具体的な構成は、SQLite クエリを実行することです。 リーリー

WAL メカニズムの原理: 変更はデータベース ファイルに直接書き込まれず、WAL (data.db3-wal) と呼ばれる別のファイルに書き込まれます。トランザクションが失敗した場合、WAL 内のレコードは無視され、変更は元に戻されます。トランザクションが成功すると、後でデータベース ファイルに書き戻され (PRAGMA synchronous = NORMAL)、変更がコミットされます。この動作は、WAL ファイルとデータベース ファイルを同期する動作と呼ばれ、チェックポイントによって自動的に実行されます。 SQLite の場合、WAL ファイルに 1000 ページの変更が蓄積されます (PRAGMA wal_autocheckpoint)。適切な時点で、SQLite が提供するチェックポイントを実行すると、WAL ファイルが空になります。読み取りの場合、SQLite は WAL ファイル内を検索して最後の書き込みポイントを見つけ、それを記憶し、それ以降の書き込みポイントを無視します (これにより、読み取りと書き込みを並行して実行できることが保証されます)。 WAL ファイルにある場合は、WAL ファイル内のデータを読み取ります。そうでない場合は、SQLite を使用して WAL ファイルにデータを書き込みます。書き込みを保証する必要があるため、WAL の実装中に書き込みと書き込みを並行して実行することはできません。そのため、すべての読み取りプロセスと書き込みプロセスは同じマシン上に存在する必要があります。データの一貫性は保証できません。

WAL やチェックポイントのような概念は MySQL などの他のデータベースにも存在しますが、MySQL はより複雑で、この書き込み方法では大規模な同時書き込み操作をサポートできます。

非同期書き込みと考えることができます。 WAL+checkpointNode の JS インタープリターは Chromium の V8 に基づいており、V8 には JIT ジャストインタイム コンパイル メカニズムがあるため、Node の集中的なコンピューティング パフォーマンスは PHP よりも劣ります。PHP 関係者は現在 PHP の JIT テストを開発していますが、そのパフォーマンスはまだそれほど良くありません。 V8. ただし、たとえ Node のコンピューティング パフォーマンスが優れていたとしても、Node で大規模な集中的な計算を実行することを推奨する人はほとんどいません。集中的なコンピューティングの消費は必然的に Node のサービスをブロックしてしまうためであり、これは Node が提唱するノンブロッキングの概念に反します。

Node は JS のイベント駆動特性を使用してノンブロッキングを実現しますが、コールバックベースのイベント プログラミング方法はコードのメンテナンスに役立ちません。さらに、Node のようなサービスは Java のような単一プロセス、マルチスレッド、マルチコアを使用できません。 Tomcat などのサービスはサポートされませんが、V8 はマルチスレッド用に設計されていないため、ノード担当者はマルチコアを活用するためにクラスターのマルチプロセス モジュールを構築することしかできません。

PHP は比較的平凡で、計算速度は JIT 言語ほど速くありません。ただし、JIT 以外の一般的なスクリプト言語の中では、PHP は遅いというわけではありません。たとえば、PHP5 はすでに Python よりも高速です。 /Zend/bench.php テストでは、PHP 7.1 の所要時間は 5.4 のわずか 1/4 です。

さらに、PHP の PHP-FPM や Apache MOD_PHP などのマルチプロセス FastCGI 実行メソッドは、複数のコアを簡単に利用できます。また、opcache を有効にして、PHP スクリプトのオペコードを共有メモリにキャッシュすることもできます。 Functions.php では、opcache がスクリプトをメモリにキャッシュした後、PHP がリクエストされるたびにスクリプトを再解析する必要がなく、特に複雑な場合にオペコードを直接実行できるため、パフォーマンスの向上は非常に明白です。 PHP アプリケーション