うーん、こういうのをここに載せていいのかわかりません。しかし、これはすべて、知識を向上させるための新しいアイデアについて話し合うことができる正しい場所だと確信しています. 右？
私はこれについて考えていました.PHPをAPACHEモジュールとして使用する場合、PHPファイルへの各リクエストはコードを実行するための新しいプロセスを生成します. 通常、複数のファイル ( include) をロードし、さまざまな手順も実行します。したがって、「index.php」を実行した場所を推測すると、プロセス全体が数回繰り返され、必要に応じて数回繰り返されます。
実用的な例: 10 個のクラスをロードする特定の index.php を実行した場合、PHP はすべてのファイルを解析し、必要に応じて重要な部分を実行します。CPU、メモリ、ストレージの I/O 使用率を生成します。
<?php
require_once 'classes/File.php';
require_once 'classes/Event.php';
require_once 'classes/Mobile.php';
// ...
File::emptyDir('tmp');
?>
すべてのクラスをロードし、解析して実行します。Ok。
したがって、必要なファイルを何度も、一度だけ実行する必要がなく、メソッドのみを使用するアンビエントでは、ユーザー要求ごとにそれを使用するソケット アンビエントを作成すると、冗長性を回避して PHP アクセスを過速度にできますか?
ユーザー インタラクションの簡単な例:
- ユーザーがリクエストを開始し
/page?version=1.3ます。 - エンジンへの
.htaccessリダイレクト。request.php - エンジンは、プリロードされたアイドル状態のサービス (
service.phpのソケット) が存在するかどうかをチェックし、それを使用します。そうでない場合は、新しいサービスを開始して (コードを事前にロードして)、それを使用してください。 $_SERVERユーザー データ (およびとして$_GET) をサービス (たとえば JSON として) に送信すると、WORKING 状態になります。- サービスはユーザー データを
request.php再び に返します。そして、次のリクエストで使用するために IDLE にします。そして、非常に長い IDLE 時間の後に閉じます。
問題は、このメソッドは、毎回すべてのコードを解析することを回避し (opcode オプティマイザーを除く)、クラスを準備するなどして、PHP を過速度にする可能性があるということです。
私はいくつかの理論的な欠点/利点について考えています:
- GOOD: リクエストを非常に速く返す可能性があります。
- GOOD: 毎回同じファイルのロードを回避するか、毎回新しいプロセスを作成します。
- GOOD: すべてのスレッド インスタンスと状態を制御できます。
- ニュートラル: ファイルを変更した場合、すべてのサービスを閉じて、更新されたファイルで新しいファイルを作成する必要があります。解決策: Devopment アンビエントでは、すべてのメイン リクエストが新しいサービスを開始することを避けてください。
- 悪い: リクエストごとにメモリを解放する代わりに、より多くの時間メモリを使用します。