しかし、swooleは、実行するための恒久的なメモリです。いくつかの違いがありますが、我々は次を理解することです。
ロードされた任意のサーバリソースを実行した後、それは常にメモリに保持されます。クライアント接続は、最初の接続時にクライアントの必要性を排除するときには、いくつかの設定ファイル、初期化変数およびその他の操作をロードし、接続する100クライアントがあり、我々は、サーバーを開いていると仮定され、これらの操作は、バックを持っていますこのプロセスは、メモリの十分から直接読み取る、ロードを繰り返しています。
本当に良いそれはそう？明らかに、非常に良い。また、これは大きなパフォーマンスを向上します。
しかし、開発者のための要件も高くなっています。これらのリソースの永続的な記憶なので、およびWebモードとして、要求の終了後にメモリやリソースを解放しますありません。我々は良いの操作で対処していなかったことを一度、メモリリークが発生し、時間の経過は、メモリのオーバーフローを有することができます。
swoole以前には良い印象でした、私はすべてのピットを期待していませんでした。あなたはそれが、より自分の能力を高めるための制約として当分の間だと思う場合は実際には、これはすべてのピット、ピットではありません。
戻る私たちは冒頭で述べた質問に、長ったらしい説明は再び：私たちのコード最初のサーバがメモリにロードされ、クライアントは再び要求を開始したときに我々は、ローカルディスク上のコードを変更する方法下旬に関係なく、常に力のコードのメモリでは、我々は唯一のメモリを解放し、サーバーを終了し、サーバーを再起動することができますので、新しいコードは、あなたが理解しているかどうか、そう、メモリに再ロードされているのですか？
一部の学生はそれを言う、私は良いトラブルを感じ、何もメモリにそれは手動で設定を解除リリースでなければなりませんswooleで独自のアプリケーションを言っているのではありませんか？
ローカル変数のために、心を行使する必要はありません、swooleは、イベントのコールバック関数が戻った後にリリースされます。彼らは、使用後に解放されることはありませんので、しかし、グローバル変数のためにあなたは、あまりにもハードワークしなければなりません。解放されないのだろうか？PHPでは、グローバル変数これらのタイプのこと：グローバル変数を宣言し、オブジェクトのプロパティまたは静的変数は、関数の静的および使用するためにあえてスーパーグローバル内で宣言しましたか？不注意なリズムサーバが直接オフに終了します！
なぜ我々は、グローバル変数を考える必要がありますか？
あなただけのグローバル共有したいされていませんか？しかし、マルチプロセスの開発モデル、サブプロセスのメモリヒープに格納されているメモリのプロセスで使用されるグローバル変数には、共有メモリはswoole開発に我々はグローバル変数を使用して回避しようとそうではありません！
私が非を使用したくありませんか？私達はちょうど使用したい、幸せです。
私たちは、メモリリークを回避する方法を見てみましょう。
例えば、接続を識別するクライアントを格納するための大規模な静的アレイがあります。私たちは、OnCloseのコールバック内の変数をクリーンアップすることができます。
また、swooleもmax_requestメカニズムを提供し、我々はメモリ不足を避けるためにmax_requestとtask_max_requestこれら2つのパラメータを設定することができます。
max_request意味することは、ワーカープロセスが自動的に終了します、タスクの数を処理するためのワーカープロセスは、このパラメータを超えるタスクワーカープロセスの最大数であるので、彼らは、空きメモリやリソースの目的を達成します。
我々はマネージャプロセスを持っているため、新しいワーカープロセスを再引っ張ってくるワーカープロセスが終了Managerプロセスの後、ワーカープロセスが終了、ではない「人」ビジネスロジックを心配しないでください。
タスクのtask_max_requestプロセス、同じ意味のmax_request。
裸の私は、私たちの見解はとても楽しいではない、と述べました。
サーバコード次のように省略されています
次のようにクライアントコードはあります
テストの目的のために、我々はワーカープロセス、タスク、プロセス、最大のタスクの設定ワーカープロセスを3回開かれ、最大のタスクの設定タスクの進捗状況は4倍です。
クライアントは、現在のプロセスの構造を見て、私たちに求めていない前に、サーバーを実行した後
プロセスIDは15644と15645ああに等しいことに留意されたいが、これは2つのワーカープロセス、プロセス、そのタスクです。マックの下で最終的に私たちは誰が誰であるかを区別することはできません。
その後、我々は結果を見て、クライアントは3回を要求してみましょう
元のプロセスIDを発見していない今となっている15680の15645に等しいですか？リクエスト3回の後に我々は、ワーカープロセスが自動的に取り出され、プロセスのワーカープロセスマネージャ15680を引っ張っている決定します。
私たちは、再び第四時間を要求します
発見のプロセスIDと等しいタスク処理15644が消えて、新しい子プロセス15704が再作成されています。
すべての権利だ公式うそは、存在しないようです。
だから... ...私はもともとそんなにナンセンスの初めに導入しますか？
すべてmax_requestのパラメータは、サーバ上で以下のいくつかの制限がありませんので。
max_requestしか要求に応答して、同期のブロッキング、ステートレスなサーバプログラムのために使用することが
max_request Serverはべきではない、純粋な非同期セット
ベースモードを使用max_requestは無効である
基本モードはswooleの動作モードであり、我々はマルチプロセスモードを紹介します。
要約：
- 永久的なメモリは、オーバーヘッドが小さい、swoole良いではありません削減します
- 私たちは無益、最高ではない、グローバル変数を利用するのは避けるべき
- max_requestメモリオーバーフローの問題は、PHPを解決することができますが、制限のシーンがあるため、主に、空きメモリの習慣を開発するためにmax_request