23

何百ものクラスファイルを含むLARGE（600K以上）phpファイルを含めることに関連する「コスト」に関する情報を誰かが持っているかどうか疑問に思っています。たとえば、一致するものを見つける前に複数のディレクトリを検索する個々のファイルを自動ロードする場合と比較して、本当に大きな違いがありますか？

APCキャッシングをオンにすると、このコストは無視できるようになりますか？

4

3 に答える 3

21

基本的に、1つの大きなファイルを含めるコストはユースケースによって異なります。200クラスの大きなファイルがあるとしましょう。

1つのクラスのみを使用する場合、大きなファイルを含めると、その個々のクラスに小さなクラスファイルを含めるよりもコストがかかります。

200のクラスすべてを使用する場合、大きなファイルを含めると、200の小さなファイルを含めるよりも大幅に安価になります。

カットオフがどこにあるかは、実際にはシステムに依存します。私はそれが50％マークのあたりになるだろうと想像します（1つのリクエストで100未満のクラスを使用している場合は、自動ロードします）。

また、APCを使用すると、損益分岐点がより少ないクラスに近づく可能性があります（したがって、使用しない場合、100クラスを使用すると損益分岐点になる可能性がありますが、使用すると50クラスになる可能性があります）、大きなシングルインクルードがはるかに安くなりますが、小さい方の各個人の損益分岐点はわずかに含まれます。

正確な損益分岐点は、システムに100％依存します（ディスクI / Oの速度、プロセッサの速度、メモリの量など）。したがって、プラットフォームで確実に知る唯一の方法は、テストすることです。

ただし、生のパフォーマンスよりも多くのことが危機に瀕しています。同時に複数のクラスで作業するのは難しいため、1つの大きなファイルでは保守性が低下します（IDEのタブが役に立たなくなります）。私は個人的にすべてのクラスを別々のファイルに保存し、ファイルの1つの巨大な怪物を作るのではなく、開発者としての私の生活を楽にします。

さて、Facebookのトラフィックレベルがある場合は、さらに調査する価値があるかもしれません。しかし、あなたがそうでなければ、私は個人的にそれについて心配しません...

于 2011-02-03T19:48:00.557 に答える
20

include()多くのプログラマーやCMSプラットフォームがこれらの実行前のphpコストを見落としているので、共有したいphpのさまざまなコストについていくつかのテストを実施しました。

関数自体のコストはごくわずかです。100ファイルインクルード（空のファイルを含む）のコストは約5ミリ秒です。opcacheを使用する場合は1マイクロ秒以内。

したがって、100個の個別のファイルに含まれるのではなく、100個のクラスを含むより大きなphpファイルを含めることによるコスト削減は、わずか約5ミリ秒です。また、OpCodeキャッシュを使用すると、そのコストは無関係になります。

実際のコストは、ファイルのサイズ、およびPHPが解析および/またはコンパイルする必要があるものに伴います。これらのコストをよりよく理解するために、オプティマイザー対応のeAcceleratoropcacheを使用してPHP5.3を実行し、10,000RPMドライブを搭載した2010MacMiniServerで実施したテスト結果を以下に示します。

1µs  for 100 EMPTY File includes, w/opcache
5ms  for 100 EMPTY File includes, no opcache

7ms   for 100 32KB File includes, w/opcache
30ms  for 100 32KB File includes, no opcache

14ms  for 100 64KB File includes, w/opcache
60ms  for 100 64KB File includes, no opcache

22ms  for 100 128KB File includes, w/opcache
100ms for 100 128KB File includes, no opcache

38ms  for 100 200KB File includes, w/opcache
170ms for 100 200KB File includes, no opcache

したがって、600KBのphpファイルのコストは約6ミリ秒、またはオペコードキャッシュを使用する場合は約1ミリ秒です。代わりに本当に見たいのは、リクエストごとに含まれるすべてのコードのサイズです。

コンボでファイルをマージしてリソースを節約しようとするのは間違いなく良い考えではなく、op-cacheを使用する場合は間違いです。同じファイルを100回インクルードしたので、私のテストではディスク速度はほとんど考慮されていません。とはいえ、基本的なパフォーマンスの観点からは、op-cacheをインストールすることが実際に前提条件であるため、ディスクI/Oをカバーする必要性はまったく感じません。

パフォーマンスを可能な限り向上させ、RAMの使用量を節約するには、逆のことを行う必要があります。これは、オートローダーまたはクラスファクトリパターンを使用して、ファイルを可能な限りコンテキストに応じて分割し、リクエストごとに未使用のコードをできるだけ少なくすることです。

その趣旨で、誤用include_once()はパフォーマンスに悪影響を与える可能性もあります...

あなたの基本クラスに関して。同様の状況がありますが、テーブルスキーマのごく一部しか含まれていません。主にフィールドタイプと主キーの詳細。パフォーマンス上の理由から、テーブルの非常に重いスキーマはめったに使用されないため、意図的に含めません。使用される場合は、リクエストごとに最大で2、3個しか使用しません。

テーブルの平均的な完全な列の詳細は、スキーマ配列ごとに約20〜50kです。任意の要求にそれらの10〜15を含めると、アレイのコストは約1〜3ミリ秒になります。それ自体はそれほど多くありません。しかし、リクエストごとに500kのRAMを節約することと組み合わせると、価値があります。

于 2015-03-16T07:51:15.593 に答える
1

APCを使用すると大幅に節約できますが、ソースが600kの場合に無視できるかどうかはわかりません。それは約15000行のコードですか？Webサイトの場合はそれほど多くありませんが、単一のファイルの場合はかなり大きくなります。

むしろ、より動的なアプローチを使用し、特定のクラスで特定の機能を分離することをお勧めします。次に、ページごとに、必要なコードを選択できます。

特にAPCを使用する場合は、ディスクから多数の小さなファイルをロードするときに発生するファイルI / Oのオーバーヘッドがないため、このアプローチの方が適しています。小さな指定されたクラスを実装し、それぞれを別々のファイルに入れることを選択します。PHPクラスのロードメカニズム（__autoload）を使用して、適切なユニットを自動的にロードできます。

クラスとユニットの適切な命名規則を理解すると、開発がはるかに簡単になります。

于 2011-02-03T19:45:54.083 に答える