PHP の最適化に関する HOWTO-php手册-php.cn

来源：http://phplens.com/ 著者 : John Lim

PHP は非常に高速なプログラミング言語ですが、PHP の最適化にはコードの実行速度だけではありません。

この章では、PHP の最適化になぜ関係があるのかを説明します。コードに関係しない多くの要因、および PHP のチューニングには、サーバー上の他のすべてのサブシステムとの関係で PHP がどのように動作するかを理解し、これらのサブシステムによって引き起こされるボトルネックを特定して修正する必要がある理由について説明します。また、PHP スクリプトをさらに高速に実行するために調整および最適化する方法についても説明します。

高いパフォーマンスを達成する

優れたパフォーマンスについて話すとき、PHP スクリプトの実行速度について話しているのではありません。パフォーマンスは、スケーラビリティと速度の間の一連のトレードオフです。使用するリソースが少なくなるように調整されたスクリプトは、キャッシュを実行するスクリプトよりも遅くなる可能性がありますが、同じスクリプトのより多くのコピーを Web サーバー上で一度に実行できます。

以下の例では、A.php は速く走ることができる短距離ランナーであり、B.php はほぼ同じ速度で永遠にジョギングできるマラソンランナーです。負荷が軽い場合は、A.php の方が大幅に高速ですが、Web トラフィックが増加すると、B.php のパフォーマンスが少し低下するだけで、A.php は限界に達するだけです。

より現実的な例を見てみましょう。問題をさらに明確にするため。 250K ファイルを読み取り、ファイルの HTML 概要を生成する PHP スクリプトを作成する必要があるとします。同じことを行う 2 つのスクリプトを作成します。hare.php はファイル全体を一度にメモリに読み込み、1 回のパスで処理します。もう 1 つは、一度に 1 行ずつファイルを読み込み、最長行以上は保持しない tortoise.php です。記憶の中で。 Tortoise.php は複数の読み取りが発行されるため遅くなり、より多くのシステムコールが必要になります。

Hare.php は 0.04 秒の CPU と 10 Mb RAM を必要とし、tortoise.php は 0.06 秒の CPU と 5 Mb RAM を必要とします。サーバーには 100 MB の実際の空き RAM があり、CPU は 99% アイドル状態です。話を単純化するために、メモリの断片化が発生しないと仮定します。

10 個のスクリプトを同時に実行すると、hare.php がメモリ不足になります (10 x 10 = 100)。この時点では、tortoise.php にはまだ 50 MB の空きメモリが残っています。 11 番目の同時スクリプトを実行すると、hare.php が仮想メモリの使用を開始し、速度が元の半分程度に低下します。 hare.php の各呼び出しには 0.08 秒の CPU 時間がかかるようになりました。その間、tortoise.php は通常の 0.06 秒の CPU 時間で引き続き実行されます。

以下の表では、さまざまな負荷に対する高速な PHP スクリプトが太字で示されています。

上記の例が示すように、優れたパフォーマンスを得るには、単に高速な PHP スクリプトを作成する必要があります。高性能の PHP を使用するには、基礎となるハードウェア、オペレーティングシステム、および Web サーバーやデータベースなどのサポートソフトウェアをよく理解する必要があります。

ボトルネック

ウサギとカメの例は、ボトルネックが速度低下の原因であることを示しています。無限の RAM を使用すると、hare.php は常に tortoise.php より高速になります。残念ながら、上記のモデルは少し単純化されており、RAM 以外にもパフォーマンスに対するボトルネックが多数あります。

(a) ネットワーク

おそらく、ネットワークが最大のボトルネックです。インターネットへの 10 M ビットのリンクがあり、1 秒あたり 1 メガバイトのデータを送信できるとします。各 Web ページが 30k の場合、1 秒あたりわずか 33 Web ページで回線が飽和状態になります。

さらに微妙なネットワークのボトルネックには、DNS などの遅いネットワークサービスへの頻繁なアクセスや、ネットワークソフトウェアへの不十分なメモリの割り当てが含まれます。

(b) CPU

CPU 負荷を監視している場合、ネットワーク経由でプレーン HTML ページを送信しても負担はかかりません前述したように、ボトルネックはネットワークであるため、CPU はまったく必要ありません。ただし、PHP が生成する複雑な動的 Web ページの場合は、通常、CPU 速度が制限要因になります。複数のプロセッサを備えたサーバーを使用するか、サーバーファームを使用すると、この問題を軽減できます。

(c) 共有メモリ

共有メモリは、プロセス間通信に使用され、キャッシュされたデータやコードなどの複数のプロセス間で共有されるリソースを保存します。。共有メモリが十分に割り当てられていない場合、データベース接続や実行可能コードなどの共有メモリを使用するリソースにアクセスしようとすると、パフォーマンスが低下します。

(d) ファイルシステム

ハードディスクへのアクセスは、ハードディスクからのデータの読み取りよりも 50 ～ 100 倍遅くなる可能性があります。ラム。 RAM を使用したファイルキャッシュにより、これを軽減できます。ただし、メモリが少ない状態では、ファイルシステムキャッシュに使用できるメモリの量が減少し、動作が遅くなります。ファイルシステムが大幅に断片化し、ディスクアクセスが遅くなる場合もあります。 Unix システムでシンボリックリンクを頻繁に使用すると、ディスクアクセスも遅くなる可能性があります。

デフォルトの Linux インストールは、速度ではなく互換性を重視して調整されたハードディスクのデフォルト設定を設定していることでも知られています。コマンド hdparm を使用して、Linux ハードディスク設定を調整します。

(e) プロセス管理

Windows などの一部のオペレーティングシステムでは、新しいプロセスを作成する操作が遅くなります。つまり、呼び出されるたびに新しいプロセスをフォークする CGI アプリケーションは、これらのオペレーティングシステムでは実行速度が大幅に遅くなります。マルチスレッドモードで PHP を実行すると、応答時間が改善されます (注: 古いバージョンの PHP はマルチスレッドモードでは安定しません)。

不必要なプロセスが多すぎて Web サーバーが過密になるのを避けてください。たとえば、サーバーが純粋に Web サービスを目的としている場合は、マシン上で X-Windows を実行 (またはインストール) することは避けてください。 Windows では、CPU 使用率が 100% になる Microsoft Find Fast (Office の一部) および 3D スクリーンセーバーの実行を避けてください。

削除を検討できるプログラムには、未使用のネットワークプロトコル、メールサーバー、ウイルス対策スキャナ、ハードウェアなどがあります。マウス、赤外線ポートなどのドライバー。 Unix では、SSH を使用してサーバーにアクセスしていると思います。次に、以下を削除することを検討できます。

Connections
1 つの HTTP リクエストを満たすのに必要な CPU 秒数
10 の HTTP リクエストを満たすのに必要な CPU 秒数
11 の HTTP リクエストを満たすのに必要な CPU 秒数

hare.php
0.04
0.40
0.88
(runs RAM 不足)

tortoise.php
0.06
0.60
0.66

telnetd、inetd、atd、ftpd、lpd、sambad などのデーモン
受信メールの sendmail
NFS のポートマップ
xfs、 wm、xinit、X

通常 /etc/init* または /etc/rc*/init* ディレクトリに保存されている起動ファイルを変更することで、起動時にさまざまなプログラムを無効にすることもできます。

また、cron ジョブを確認して、削除できるか、オフピーク期間にスケジュールを変更できるかを確認してください。

(f) 他のサーバーへの接続

Web サーバーが他のサーバーで実行されているサービスを必要とする場合、それらのジョブが他のサーバーで実行されている可能性があります。サーバーがボトルネックになります。この最も一般的な例は、複数の Web サーバーからのあまりにも多くの複雑な SQL リクエストを処理している遅いデータベースサーバーです。完了です。このアドバイスが意味をなすのは、プログラミングチームのコーディングがそもそも高品質であり、アプリケーションのパフォーマンスパラメータをすでに十分に把握している場合のみです。そうしないと、テスト後にコードのかなりの部分を書き直さなければならないというリスクにさらされることになります。

私のアドバイスは、ソフトウェアアプリケーションを設計する前に、ハードウェアとソフトウェアの基本的なベンチマークをいくつか実行して、動作の感触を掴む必要があるということです。達成できる可能性のある最大限のパフォーマンス。次に、アプリケーションを設計してコーディングするときに、必要なパフォーマンスパラメーターを念頭に置いてください。どの段階でも、パフォーマンス、可用性、セキュリティ、柔軟性の間にトレードオフが存在するためです。

また、適切なテストデータも選択してください。データベースに 100,000 レコードを保持すると予想される場合は、100 レコードのみのデータベースでのテストは避けてください。後悔することになります。かつて、私の会社のプログラマーの一人にこのようなことが起こりました。遅いコードはずっと後になってから検出され、機能しても拡張できなかった多くのコードを書き直す必要があったため、多くの時間が無駄になりました。

Web サーバーを PHP 用にチューニングする

現在使用されている 2 つの最も一般的な Web サーバー、Apache 1.3 と IIS で最高の PHP パフォーマンスを実現します。ここでのアドバイスの多くは、HTML の提供にも当てはまります。

PHP の作者は、PHP で Apache 1.3 よりも Apache 2.0 を使用する場合、特にマルチスレッドモードでパフォーマンスやスケーラビリティの点で利点がないと述べています。 Apache 2.0 をプリフォークモードで実行する場合、次の議論は依然として重要です (2003 年 10 月 21 日)。

(a) Apache 1.3/2.0

Apache は Unix と Windows の両方で使用できます。世界で最も人気のある Web サーバーです。 Apache 1.3 は、Web サービスに事前フォークモデルを使用します。 Apache が起動すると、HTTP リクエストを処理する複数の子プロセスが作成されます。最初の親プロセスは守護天使のように機能し、すべての子プロセスが適切に動作していることを確認し、すべてを調整します。より多くの HTTP リクエストが受信されると、それらを処理するためにより多くの子プロセスが生成されます。 HTTP リクエストが遅くなると、親プロセスはアイドル状態の子プロセスを強制終了し、他のプロセスのリソースを解放します。このスキームの利点は、Apache を非常に堅牢にすることです。子プロセスがクラッシュした場合でも、親プロセスと他の子プロセスはクラッシュした子プロセスから隔離されます。

プリフォークモデルは他の考えられるデザインほど高速ではありませんが、私にとっては「大した問題ではない」と思います。 Apache のパフォーマンスの問題が重大になるずっと前に、他のボトルネックが発生するため、PHP スクリプトを提供するサーバーでは実行できません。 Apache の堅牢性と信頼性はより重要です。

Apache 2.0 は、マルチスレッドモードでの操作を提供します。私のベンチマークによると、このモードではパフォーマンス上の利点がほとんどありません。また、多くの PHP 拡張機能には互換性がないことにも注意してください (GD や IMAP など)。 Apache 2.0.47 (2003 年 10 月 21 日) でテスト済み。

Apache は httpd.conf ファイルを使用して設定されています。次のパラメータは、子プロセスを構成する際に特に重要です。

大規模なサイトの場合は、次の値に近い値が適している可能性があります:

ディレクティブ
デフォルト
説明

MaxClients
256
作成する子プロセスの最大数。デフォルトは、最大 256 の HTTP リクエストを同時に処理できることを意味します。それ以降の接続要求はキューに入れられます。

StartServers
5
起動時に作成する子プロセスの数。

MinSpareServers
5
作成する必要があるアイドル状態の子プロセスの数。アイドル状態の子プロセスの数がこの数を下回ると、最初に 1 つの子が作成され、次の 2 秒後に 2 つ、さらに 1 秒後に 4 つというように、1 秒あたり 32 の子が作成されるまで続きます。

MaxSpareServers
10
この数を超える子プロセスが生きている場合、これらの余分なプロセスは終了されます。

MaxRequestsPerChild
0
子が終了するまでに処理できる HTTP リクエストの数を設定します。 0 に設定すると、決して終了しないことを意味します。メモリリークが発生していると思われる場合、または十分に活用されていないリソースを解放するには、これを 100 ～ 10000 の値に設定します。

MinSpareServers 32

MaxSpareServers 64

Windows 上の Apache は動作が異なります。 Apache は子プロセスを使用する代わりにスレッドを使用します。上記のパラメータは使用されません。代わりに、デフォルトで 50 に設定される ThreadsPerChild という 1 つのパラメータがあります。このパラメータは、Apache によって生成されるスレッドの数を設定します。 Windows バージョンには子プロセスが 1 つしかないため、デフォルト設定の 50 は、50 個の同時 HTTP リクエストのみを処理できることを意味します。 Web サーバーのトラフィックが増加する場合は、この値を 256 から 1024 の間に増やしてください。

変更できるその他の便利なパフォーマンスパラメーターは次のとおりです。

DNS ルックアップが必要なく、htaccess ファイルを使用して Apache 設定を構成していない場合設定できる個別のディレクトリ:

ディレクティブ
デフォルト
説明

SendBufferSize
OS のデフォルトに設定
TCP/IP 接続で使用される出力バッファのサイズ (バイト単位) を決定します。これは主に、パケットをバッファリングする必要がある混雑したネットワークや遅いネットワークで役立ちます。次に、このパラメータを、通常ダウンロードされる最大のファイルのサイズに近い値に設定します。クライアント接続ごとに 1 つの TCP/IP バッファが作成されます。

KeepAlive [on|off]
オン
元の HTTP 仕様では、すべての HTTP リクエストがサーバーへの個別の接続を確立する必要がありました。頻繁な接続のオーバーヘッドを軽減するために、キープアライブヘッダーが開発されました。キープアライブは、複数の HTTP リクエストに対して同じソケット接続を再利用するようにサーバーに指示します。

別の専用 Web サーバーがすべての画像を提供する場合は、このオプションを無効にすることができます。この技術により、リソースの使用率が大幅に向上します。

KeepAliveTimeout
15
ソケット接続を維持する秒数。この時間には、サーバーによるコンテンツの生成とクライアントによる確認が含まれます。クライアントが時間内に応答しない場合は、新しい接続を作成する必要があります。

そうしないとソケットが長期間アイドル状態になるため、この値は低く保つ必要があります。

MaxKeepAliveRequests
100
MaxKeepAliveRequests で設定されたリクエスト数に達すると、ソケット接続は終了します。これを MaxClients または ThreadsPerChild 未満の高い値に保ちます。

TimeOut
300
アイドル時間がこの値を超えると切断します。クライアントの待機時間が短い場合は、この値をより低く設定できます。

LimitRequestBody
0
PUT または POST の最大サイズ。 ○は制限がないことを意味します。

# DNS ルックアップを無効にします: PHP スクリプトは IP アドレスのみを取得します

HostnameLookups をオフにします

# htaccess チェックを無効にします

AllowOverride none

シンボリックリンクにアクセスするときにディレクトリのセキュリティを心配しない場合は、追加の lstat() システムコールが行われないように、FollowSymLinks をオンにし、SymLinksIfOwnerMatch をオフにします。

Options FollowSymLinks

#Options SymLinksIfOwnerMatch

(b) IISチューニング

IIS は、Windows NT および 2000 で使用できるマルチスレッド Web サーバーです。インターネットサービスマネージャーから、次のパラメータを調整できます:

Web サイトのデフォルトの分離レベルを構成することもできます。 [アプリケーション保護] の [ホームディレクトリ] タブで、分離レベルを定義できます。高度に分離された Web サイトは、IIS とは別のプロセスとして実行されるため、実行が遅くなります。一方、IIS プロセスで Web サイトを実行するのは最も高速ですが、Web サイトのコードに重大なバグがある場合はサーバーがダウンします。現時点では、CGI を使用して PHP Web サイトを実行するか、アプリケーション保護を高に設定して ISAPI を使用することをお勧めします。

また、regedit.exe を使用して、次の場所に保存されている IIS 5 レジストリ設定を変更することもできます:

数値に基づくパフォーマンスチューニング1 日あたりのヒット数。
IIS に事前に割り当てるメモリの量を決定します。 ([パフォーマンス] タブ)。

帯域幅調整
Web サイトごとに割り当てられる 1 秒あたりの帯域幅を制御します。 ([パフォーマンス] タブ)

プロセススロットル
Web サイトごとに使用可能な CPU% を制御します。 ([パフォーマンス] タブ)。

タイムアウト
デフォルトは 900 秒です。ローカルエリアネットワークでは、より低い値に設定します。 ([Web サイト] タブ)

HTTP 圧縮
IIS 5 では、動的ページ、HTML、および画像を圧縮できます。圧縮された静的 HTML と画像をキャッシュするように構成できます。デフォルトでは、圧縮はオフになっています。

物理サーバー全体で HTTP 圧縮を有効にする必要があります。これをオンにするには、IIS コンソールを開き、サーバー (サブサイトではなく、左側のペインにあるサーバー) を右クリックし、プロパティを取得します。 [サービス] タブをクリックし、動的コンテンツを圧縮するには [アプリケーションファイルの圧縮] を選択し、静的コンテンツを圧縮するには [静的ファイルの圧縮] を選択します。

Windows での高いパフォーマンス: IIS と FastCGI

多くのテストを行った結果、IIS と FastCGI を使用することで Windows 上で最高の PHP パフォーマンスが得られることがわかりました。 CGI は、Web サーバーから外部プログラムを呼び出すためのプロトコルです。 CGI プログラムはページ要求のたびに終了するため、それほど高速ではありません。 FastCGI は、ページリクエスト後に CGI プログラムを永続化し、新しいページリクエストが来たときに同じ CGI プログラムを再利用することで、このプロトコルを変更して高パフォーマンスを実現します。

IIS での FastCGI のインストールは複雑であるため、EasyWindows を使用する必要があります。 PHPインストーラー。これにより、可能な限り最高のパフォーマンスを得るために、PHP、FastCGI、および Turck MMCache がインストールされます。このインストーラーは、Apache 1.3/2.0 用の PHP もインストールできます。

FastCGI に関するこのセクションは、2003 年 10 月 21 日に追加されました。

PHP4 の Zend エンジン

Zend Engine は、PHP4 で使用される内部コンパイラおよびランタイムエンジンです。 Zeev Suraski と Andi Gutmans によって開発された Zend Engine は、彼らの名前の略称です。 PHP4 の初期の頃は、次のように動作していました:

MemCacheSize
IIS がファイルキャッシュに使用するメモリの量を設定します。デフォルトでは、IIS は使用可能なメモリの 50% を使用します。 IIS がサーバー上の唯一のアプリケーションの場合は増加します。値はメガバイト単位です。

MaxCachedFileSize
ファイルキャッシュにキャッシュされるファイルの最大サイズをバイト単位で決定します。デフォルトは 262,144 (256K) です。

ObjectCacheTTL
キャッシュ内のオブジェクトがメモリに保持される時間の長さを (ミリ秒単位で) 設定します。デフォルトは 30,000 ミリ秒 (30 秒) です。

MaxPoolThreads
プロセッサごとに作成するプールスレッドの数を設定します。同時に実行できる CGI アプリケーションの数を決定します。デフォルトは 4 です。CGI モードで PHP を使用している場合は、この値を増やします。

ListenBackLog
IIS が接続キュー内で維持するアクティブなキープアライブ接続の最大数を指定します。デフォルトは 15 ですが、サポートしたい同時接続の数まで増やす必要があります。最大値は 250 です。

PHP スクリプトは Zend Engine によってロードされ、Zend オペコードにコンパイルされました。オペコードは、オペレーションコードの略で、低レベルのバイナリ命令です。次に、オペコードが実行され、生成された HTML がクライアントに送信されました。オペコードは実行後にメモリからフラッシュされました。

現在、このプロセスを高速化するのに役立つ製品や技術が多数あります。次の図は、最新の PHP スクリプトがどのように動作するかを示しています。影付きのボックスはすべてオプションです。

PHP スクリプトはメモリにロードされ、Zend オペコードにコンパイルされます。これらのオペコードは、Zend Optimizer と呼ばれるオプションのピープホールオプティマイザーを使用して最適化できるようになりました。スクリプトに応じて、PHP コードの速度を 0 ～ 50% 向上させることができます。

以前は、実行後にオペコードは破棄されていました。現在は、オプションで、いくつかの代替オープンソース製品と商用クローズドソース製品である Zend Accelerator (旧名 Zend Cache) を使用して、オペコードをメモリにキャッシュできるようになりました。 Zend Optimizer と互換性のある唯一のオペコードキャッシュは、Zend Accelerator です。オペコードキャッシュは、スクリプトの読み込みとコンパイルの手順を削除することで実行を高速化します。オペコードキャッシュを使用すると、実行時間が 10 ～ 200% 改善されます。

高いパフォーマンスの秘訣の 1 つは、より高速な PHP コードを書くことではなく、生成された HTML をファイルまたは共有ファイルにキャッシュすることで PHP コードの実行を避けることです。メモリ。 PHP スクリプトは 1 回だけ実行されて HTML がキャプチャされ、その後のスクリプトの呼び出しではキャッシュされた HTML がロードされます。データを定期的に更新する必要がある場合、キャッシュされた HTML に有効期限値が設定されます。 HTML キャッシュは PHP 言語や Zend Engine の一部ではありませんが、PHP コードを使用して実装されます。これを行うクラスライブラリは数多くあります。そのうちの 1 つは PEAR キャッシュであり、これについては次のセクションで説明します。もう 1 つは、Smarty テンプレートライブラリです。

最後に、Web クライアントに送信される HTML を圧縮できます。これは、PHP スクリプトの先頭に次のコードを配置することで有効になります:

オペコードキャッシュの場所

Zend Accelerator: Zend Engine チームによって開発された商用オペコードキャッシュ。非常に信頼性が高く、堅牢です。詳細については、http://zend.com を参照してください。

次のオープンソースオペコードキャッシュは、実行する PHP スクリプトに大きく依存するため、運用サーバーで使用する前にテストする必要があります。

Turcke MMCache : http://turck-mmcache.sourceforge.net/
(2003 年 10 月 21 日追加 - 強くお勧めします - 私もこれを使用しています)

代替 PHP キャッシュ: http://apc.communityconnect.com/

PHP アクセラレータ: http ://www.php-accelerator.co.uk/

AfterBurner キャッシュ: http://www.bwcache.bware.it/

ob_start("ob_gzhandler");

:
:

?>

HTML の圧縮率が高い場合は、HTML ファイルのサイズを 50 ～ 80% 削減して、ネットワーク帯域幅の要件と遅延を軽減することができます。欠点は、圧縮のためにある程度の CPU パワーを確保する必要があることです。

PEAR キャッシュを使用した HTML キャッシュ

PEAR キャッシュは、HTML や画像などの複数のタイプのデータをキャッシュできるようにする一連のキャッシュクラスです。

PEAR キャッシュの最も一般的な用途は、HTML テキストをキャッシュすることです。これを行うには、start() 関数と end() 関数の間で出力またはエコーされたすべてのテキストをキャッシュする出力バッファリングクラスを使用します。 file", array("cache_dir" => "cache/") );

if ($contents = $cache->start(md5("これは一意のキーです!"))) {

#
# ああ、キャッシュされたデータが返されました
#

print $contents;
print "

キャッシュヒット

";

} else {

#
# キャッシュデータがないか、キャッシュの有効期限が切れています
#

print "

これを持たずに家を出ないでください…

"; # キャッシュに入れる
print "

立って配達

"; # キャッシュに配置します
print $cache->end(10);

}

Cache コンストラクターは、最初のパラメーターとして使用するストレージドライバーを受け取ります。ファイル、データベース、共有メモリのストレージドライバーが利用可能です。 pear/Cache/Container ディレクトリを参照してください。 Ulf Wendel によるベンチマークは、「ファイル」ストレージドライバーが最高のパフォーマンスを提供することを示唆しています。 2 番目のパラメータはストレージドライバのオプションです。オプションは、キャッシュディレクトリの場所である「cache_dir」と、キャッシュされたすべてのファイルに使用するプレフィックスである「filename_prefix」です。奇妙なことに、キャッシュの有効期限はオプションパラメーターに設定されていません。

一部のデータをキャッシュするには、キーを使用してキャッシュされたデータの一意の ID を生成します。上の例では、md5("this is a unique key!") を使用しました。

start() 関数は、キーを使用してコンテンツのキャッシュされたコピーを検索します。コンテンツがキャッシュされていない場合、start() によって空の文字列が返され、end() が呼び出されるまで、以降のすべての echo() および print() ステートメントは出力キャッシュにバッファリングされます。

end() 関数はバッファーの内容を返し、出力バッファリングを終了します。 end() 関数は、最初のパラメータとしてキャッシュの有効期限を受け取ります。このパラメータには、データをキャッシュする秒数、データの有効期限を指定する Unix 整数タイムスタンプ、またはデフォルトの 24 時間のゼロを指定できます。

PEAR キャッシュを使用する別の方法は、変数またはその他のデータを保存することです。。これを行うには、基本 Cache クラスを使用できます:

require_once("Cache.php");

$cache = new Cache("file", array("cache_dir" => "cache/") );
$id = $cache->generateID("これは一意のキーです");

if ($ data = $cache->get($id)) {

print "キャッシュヒット。
Data: $data";

} else {

$data = "慈悲の質は緊張しません。 ..";
$cache->save($id, $data, $expires = 60);
print "キャッシュミス。
";

}

?>

データを保存するにはsave() を使用します。一意のキーがすでに有効なファイル名である場合は、generateID() ステップをバイパスできます。 save() がデータをシリアル化するため、オブジェクトと配列を保存できます。最後のパラメータは、データの有効期限がいつ切れるかを制御します。これは、データをキャッシュする秒数、またはデータの有効期限が切れる日時を指定する Unix 整数タイムスタンプ、またはデフォルトの 24 時間を使用する場合はゼロにすることができます。キャッシュされたデータを取得するには、get() を使用します。

$cache->delete($id) を使用してキャッシュされたデータ項目を削除でき、$cache->flush() を使用してすべてのキャッシュされた項目を削除できます。

新規:より高速なキャッシングクラスは Cache-Lite です。強くお勧めします。

ベンチマークの使用

前のセクションでは、パフォーマンスに関する多くの問題について説明しました。ここで、本質的な部分に移ります。つまり、何を調整すべきかについて適切な情報を取得できるように、コードの測定とベンチマークを行う方法です。

Web サーバー上で現実的なベンチマークを実行したい場合は、サーバーに HTTP リクエストを送信するツールが必要になります。 Unix では、ベンチマークを実行する一般的なツールには、Apache リリースの一部である ab (apachebench の略) と、新しいフラッド (httpd.apache.org/test/flood) が含まれます。 Windows NT/2000 では、Microsoft の無料の Web Application Stress Tool (webtool.rte.microsoft.com) を使用できます。

これらのプログラムは、複数の HTTP リクエストを同時に作成し、複数の Web クライアントをシミュレートし、リクエストの完了に関する詳細な統計を表示できます。「vmstat 1」を使用して Unix 上でベンチマークを実行すると、サーバーがどのように動作するかを監視できます。これにより、ディスク I/O、仮想メモリ、CPU 負荷のパフォーマンスに関するステータスレポートが毎秒出力されます。あるいは、「top d 1」を使用すると、実行中のすべてのプロセスが CPU 負荷別にソートされて 1 秒ごとに全画面更新されます。

Windows 2000 では、パフォーマンスモニターまたはタスクマネージャーを使用してシステム統計を表示できます。

HTTP オーバーヘッドを気にせずにコードの特定の側面をテストしたい場合は、マイクロタイムを使用してベンチマークを実行できます。 () は、マイクロ秒単位の正確な現在時刻を文字列として返します。次の関数は、計算に適した数値に変換します。

function getmicrotime()
{
list($usec, $sec) =explode(" ",microtime());
return ((float)$usec + (float)$sec);
}

$time = getmicrotime();

#
# ベンチマークコードはこちら
#

echo "

経過時間: ", getmicrotime() - $time, " 秒";

あるいは、APD や XDebug などのプロファイリングツールを使用することもできます。 xdebug を使用してコードを圧縮する私の記事も参照してください。

ベンチマークのケーススタディ

このケーススタディでは、クライアントのために行った実際のベンチマークについて詳しく説明します。この例では、顧客は、長い SQL クエリの実行を含まないすべての PHP ページに対して 5 秒の応答時間を保証したいと考えていました。次のサーバー構成が使用されました: Red Hat 7.2 Linux 上で PHP 4.0.6 を実行する Apache 1.3.20 サーバー。ハードウェアは、1 Gb の RAM を備えたツイン Pentium III 933 MHz の野獣でした。 HTTP リクエストは、PHP スクリプト「testmysql.php」に対するものになります。このスクリプトは、別のサーバーで実行されている MySQL データベースから約 20 レコードを読み取り、処理します。簡単にするために、すべてのグラフィックスが別の Web サーバーからダウンロードされると仮定します。

ベンチマークツールとして「ab」を使用しました。 10 の同時接続 (-c10) を使用して、1000 のリクエスト (-n1000) を実行するように「ab」を設定します。結果は次のとおりです:

# ab -n1000 -c10 http://192.168.0.99/php/testmysql.php
これは ApacheBench、バージョン 1.3 です
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http:// www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group、http://www.apache.org/

サーバーソフトウェア: Apache/1.3.20
サーバーホスト名: 192.168.0.99
サーバーポート: 80

ドキュメントパス: /php/testmysql.php
ドキュメント長: 25970バイト

同時実行レベル: 10
テストにかかった時間: 128.672秒
完了したリクエスト: 1000
失敗したリクエスト: 0
合計転送数: 26382000バイト
HTML転送: 25970000 バイト
1 秒あたりのリクエスト数: 7.77
転送速度: 205.03 kb/s 受信

接続時間 (ms)
min avg max
接続: 0 9 114
処理: 698 1274 2071
合計: 698 1283 2185

ベンチマークの実行中、サーバー側でコマンド「top d 1」を使用してリソース使用率を監視しました。パラメータ「d 1」は、更新の間に 1 秒の遅延を意味します。出力は以下のとおりです。

午後 10 時 58 分、アップ 3:36、2 ユーザー、負荷平均: 9.07、3.29、1.79
74 プロセス: 63 スリープ、11 実行、0 ゾンビ、0 停止
CPU0 状態: 92.0% ユーザー、 7.0% システム、0.0% ナイス、0.0% アイドル
CPU1 の状態: 95.0% ユーザー、4.0% システム、0.0% ナイス、0.0% アイドル
メモリ: 1028484K av、230324K used、798160K free、64K shrd、27196K buff
スワップ: av 2040244K、使用済み 0K、空き 2040244K 30360K キャッシュ

PID ユーザー PRI NI サイズ RSS 共有統計 %CPU %MEM 時間コマンド
1142 apache 20 0 7280 7280 3780 R 21.2 0.7 0:20 httpd
1154 アパッチ 17 0 8044 8044 3788 S 19.3 0.7 0:20 httpd
1155 apache 20 0 8052 8052 3796 R 19.3 0.7 0:20 httpd
1141 apache 15 0 6764 6764 3780 S 14.7 0.6 0:20 httpd
1174アパッチ 14 0 6848 6848 3788 S 12.9 0.6 0:20 httpd
1178 アパッチ 13 0 6864 6864 3804 S 12.9 0.6 0:19 httpd
1157 アパッチ 15 0 7536 7536 3788 R 11.0 0.7 0:19 httpd
1159 アパッチ 15 0 7540 7540 3788 R 11.0 0.7 0:19 httpd
1148 apache 11 0 6672 6672 3784 S 10.1 0.6 0:20 httpd
1158 apache 14 0 7400 7400 3788 R 10.1 0.7 0:19 httpd
1163 apache 20 0 7540 7540 3788 R 10.1 .7 0:19 httpd
1169 apache 12 0 6856 6856 3796 S 10.1 0.6 0:20 httpd
1176 apache 16 0 8052 8052 3796 R 10.1 0.7 0:19 httpd
1171 apache 15 0 7984 7984 3780 S 9.2 0.7 0:18 httpd
1170パチェ 16 0 7204 7204 3796 R 6.4 0.7 0:20 httpd
1168 apache 10 0 6856 6856 3796 S 4.6 0.6 0:20 httpd
1377 natsoft 11 0 1104 1104 856 R 2.7 0.1 0:02 トップ
1152 apache 9 0 6752 6752 3788 S 1.8 0.6 0:20 httpd
1167 apache 9 0 6848 6848 3788 S 0.9 0.6 0:19HTTPD
1ルート8 0 520 520 452 S 0.0 0.0 0:04 Init 2 root 9 0 0 0 0 0 0 0 0 0.0 0:00 KEVENTD

出力を「上部」の出力で見る"、ツイン CPU Apache サーバーはアイドル時間 0% でフル稼働しています。さらに悪いのは、負荷平均が過去 1 分間で 9.07 (過去 5 分間で 3.29、過去 15 分間で 1.79) であることです。負荷平均は、実行準備ができているプロセスの平均数です。ツインプロセッササーバーの場合、負荷が 2.0 を超えると、システムが過負荷になっていることを意味します。負荷 (9.07) と ab で定義した同時接続数 (10) の間には密接な関係があることに気づくかもしれません

幸いなことに、約 798,160 MB の空き容量があり、仮想メモリは使用されておらず、十分な物理メモリがあります。

さらに下では、CPU 使用率の順にプロセスが表示されます。最もアクティブなものは Apache httpd プロセスです。最初の httpd タスクは 7280K のメモリを使用し、平均して CPU の 21.2%、物理メモリの 0.7% を占有しています。 STAT 列はステータスを示します。R は実行可能、S はスリープ中、W はプロセスがスワップアウトされていることを意味します。

上記の数値を考慮し、これが典型的なピーク負荷であると仮定すると、いくつかの計画を実行できます。ツイン CPU サーバーの負荷平均が 9.0 で、各タスクの完了にほぼ同じ時間がかかると仮定すると、負荷の軽いサーバーは 9.0 / 2 CPU = 4.5 倍高速になるはずです。したがって、ピーク負荷時に応答するのに 1.283 秒かかっていた HTTP リクエストは、完了するまでに約 1.283 / 4.5 = 0.285 秒かかります。

これを検証するために、(前のベンチマークでは 10 でしたが) 2 つの同時クライアント接続でベンチマークを行ったところ、平均 0.281 秒となり、予測の 0.285 秒に非常に近づきました。

# ab -n100 -c2 http://192.168.0.99/php/testmysql.php

[簡潔にするために一部の行を省略]

1 秒あたりのリクエスト数: 7.10
転送速度: 187.37 kb/s 受信

接続時間(ms)
min avg max
Connect: 0 2 40
Processing: 255 279 292
Total: 255 281 332

逆に、接続が 2 倍になると、平均接続時間は 1.283 秒から 2.566 秒に 2 倍になると予測できます。ベンチマークでは、実際のタイムは 2.570 秒でした。

40 接続での過負荷

ベンチマークをプッシュして 40 接続を使用すると、サーバーは 35% の失敗したリクエストで過負荷になりました。さらに調査したところ、「接続が多すぎる」ために MySQL サーバーの永続接続が失敗していたことが原因でした。

このベンチマークは、Apache 子プロセスの残留動作も示しています。各 PHP スクリプトは 2 つの永続接続を使用するため、接続数が 40 の場合、デフォルトの MySQL max_connections の 100 を大幅に下回る最大 80 の永続接続のみを使用する必要があります。ただし、Apache のアイドル状態の子プロセスは、レイテンシのため、新しいリクエストにすぐには割り当てられません。 - 生存およびその他の技術的な理由。これらの残留子プロセスは、「ラクダの背中を折るわら」である残りの 20 以上の永続的な接続を保持していました。

修正

非永続的なデータベース接続に切り替えることで、この問題を修正することができ、次の結果が得られました。 5.340秒。別の解決策は、MySQL max_connections パラメーターをデフォルトの 100 から増やすことでした。

結論

上記のケーススタディは、パフォーマンスの最適化が非常に複雑であることを再度示しています。これには、ネットワークルーティング、TCP/IP スタック、物理メモリと仮想メモリの量、CPU の数、Apache 子プロセスの動作、PHP スクリプト、データベース構成など、複数のソフトウェアサブシステムを理解する必要があります。この場合、PHP コードは非常によく調整されていたため、最初のボトルネックは CPU であり、それが応答時間の低下を引き起こしました。負荷が増加するにつれて、MySQL クライアント接続のより深刻なボトルネックが発生するまで、システムの速度はほぼ直線的に低下しました (これは良い兆候です)。これにより、非永続接続に切り替えて修正するまで、PHP ページで複数のエラーが発生しました。

上の図から、指定された望ましい応答時間に対して処理できる同時 HTTP 接続の数を計算できます。インターネット上の双方向ネットワーク遅延を 0.5 秒 (片道 0.25 秒) と仮定すると、次のように予測できます:

クライアントが最大 5 秒の応答時間を望んでいたため、サーバーは 1 秒あたり最大 34 の同時接続を処理できます。。これは、1 秒あたり 34/5 = 6.8 ページビューのピーク容量になります。

サーバーが処理できる 1 日の最大ページビュー数を取得するには、1 秒あたりのピーク容量に 50,000 を掛けて (この手法は、大手 Web ホスティング会社、pair.com の Web マスターによって提案されています)、340,000 ページとなります。

コードの最適化

なぜ PHP 以外の問題について議論することにそれほど重点が置かれているのか疑問に思っている辛抱強い読者は、PHP が高速言語であり、速度低下の原因となる可能性のあるボトルネックの多くは PHP の外部にあることを思い出してください。 .

ほとんどの PHP スクリプトは単純です。これらには、セッション情報の読み取り、コンテンツ管理システムまたはデータベースからのデータのロード、適切な HTML のフォーマット、結果の HTTP クライアントへのエコーが含まれます。一般的な PHP スクリプトが 0.1 秒で完了し、インターネット遅延が 0.2 秒であると仮定すると、HTTP クライアントが認識する 0.3 秒の応答時間のうち、実際の PHP 計算は 33% のみです。したがって、スクリプトの速度が 20% 向上すると、HTTP クライアントの応答時間は 0.28 秒に低下しますが、これは重要な改善ではありません。もちろん、サーバーは同じページに対しておそらく 20% 多くのリクエストを処理できるため、スケーラビリティが向上しました。

上記の例は、手を上げて諦めるべきだという意味ではありません。これは、コードの速度の最後の 1% を調整することに誇りを感じるべきではなく、より高いリターンを得るためにコードの価値のある領域の最適化に時間を費やす必要があることを意味します。

高いリターンコードの最適化

そのような高いリターンが得られる場所達成可能なのは、コード内に散らばる while ループと for ループであり、コード内の各速度の低下は、それらを反復処理する回数によって拡大されます。何を最適化できるかを理解する最良の方法は、いくつかの例を使用することです:

例 1

配列を出力する簡単な例を 1 つ示します:

for ($j=0; $j echo $arr[$j]."
";

これは、コードを次のように変更することで大幅に高速化できます。

for ($j=0, $max = sizeof($arr) , $s = ''; $j<$max; $j++)
$s .= $arr[$j]."
";

echo $s;

まず、式 $j
2 番目の問題は、PHP 4 では、複数回エコーする方が、すべてを文字列に保存して 1 回の呼び出しでエコーするよりも遅いということです。これは、エコーは HTTP クライアントへの TCP/IP パケットの送信を伴う可能性がある高価な操作であるためです。もちろん、$s に文字列を蓄積すると、より多くのメモリを使用するため、スケーラビリティの問題がいくつか発生するため、ここにはトレードオフが関係していることがわかります。上記のコードを高速化する別の方法は、出力バッファリングを使用することです。これにより、出力文字列が内部的に蓄積され、スクリプトの最後で出力が一度に送信されます。これにより、メモリの増加と遅延の増加を犠牲にして、ネットワークのオーバーヘッドが大幅に削減されます。完全に echo ステートメントで構成されたコードの一部では、15% のパフォーマンスの向上が観察されました。

ob_start();
for ($j=0, $max = sizeof($arr), $s = ''; $j echo $arr[$j]."< br>";

ob_start() による出力バッファリングは、すべての PHP スクリプトのグローバル最適化として使用できることに注意してください。長時間実行されるスクリプトでは、出力バッファを定期的にフラッシュして、何らかのフィードバックが HTTP クライアントに送信されるようにすることもできます。これは ob_end_flush() で実行できます。この関数は出力バッファリングもオフにするため、フラッシュの直後に ob_start() を再度呼び出すことをお勧めします。

要約すると、この例では、ループの不変条件を最適化する方法と、出力バッファリングを使用してコードを高速化する方法を示しました。

例 2

次のコードでは、特別なフォーマット関数を使用して行をフォーマットし、PEAR DB レコードセットを反復処理し、結果をエコーします。今回は 10.2 ミリ秒で実行時間をベンチマークしました (これにはデータベース接続と SQL 実行時間は含まれません):

function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return ' '.$arr[0].''.$arr[1].'';
}

for ($j = 0; $ j < $rs->numRows(); $j++) {
print FormatRow($rs);
}

例 1 から、コードを次のように変更することでコードを最適化できることがわかりました (実行時間: 8.7 ミリ秒):

function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return ''.$arr[0].' '.$arr[1].'';
}

ob_start();

for ($j = 0, $max = $rs->numRows(); $ j < $max; $j++) {
print FormatRow($rs);
}

私のベンチマークでは、$max を使用すると 0.5 ミリ秒、ob_start を使用すると 1.5 ミリ秒の高速化に寄与することがわかりました。ループアルゴリズムを変更すると、コードを簡素化して高速化できます。この場合、実行時間は 8.5 ミリ秒に短縮されます:

function FormatRow($arr)
{
return ''.$arr[0].''.$ arr[1].';
}

ob_start();

while ($arr = $rs->fetchRow()) {
print FormatRow($arr);
}

One最後の最適化はここで可能です。関数呼び出しのオーバーヘッド (速度のために保守性が犠牲になる可能性があります) を削除して、さらに 0.1 ミリ秒 (実行時間: 8.4 ミリ秒) を短縮できます。 )) {
print ''.$arr[0].''.$arr[1].'';
}

切り替えることでPEAR キャッシュに移行すると、キャッシュされたデータの実行時間は再び 3.5 ミリ秒に減少しました:

require_once("Cache/Output.php");

ob_start();

$cache = new Cache_Output("file", array("cache_dir) " => "cache/") );

$t = getmicrotime();

if ($contents = $cache->start(md5("this is a unique kexy!"))) {
print "

キャッシュヒット

";
print $contents;
} else {
print "

キャッシュミス

";

##
## データベースに接続してクエリを実行するコード省略
##

while ($arr = $rs->fetchRow()) {
print ''.$arr[0].''.$arr [1].'';
}

print $cache->end(100);
}

print (getmicrotime()-$t);

以下に最適化方法をまとめます。

上記の図から、最大の速度向上はコードの微調整によるものではなく、ob_start() などの単純なグローバル最適化、または HTML キャッシュなどの根本的に異なるアルゴリズムの使用によってもたらされることがわかります。調整の時間

実行時間 (ミリ秒)
最適化方法

9.9
初期コード、最適化なし、データベース接続と SQL 実行時間を除く

9.2
ob_start
の使用
8.7
ループ不変条件 ($max) の最適化と ob_start
の使用
8.5
forループからwhileループに変更し、配列をFormatRow()に渡してob_start
を使用する
8.4
FormatRow()を削除してob_start
を使用する
3.5
PEAR Cacheを使用し、ob_start
を使用する
オブジェクトの最適化-指向性プログラミング

2001 年 3 月に、私は PHP 4.0.4pl1 のクラスを使用して非公式のベンチマークをいくつか実施し、その結果からいくつかのアドバイスを導き出しました。主要なポイントは次の 3 つです:

1.使用する前にすべての変数を初期化します。

2.値に 2 回以上アクセスする予定がある場合は、メソッドで頻繁に使用されるすべてのグローバル/プロパティ変数を逆参照し、値をローカル変数に入れます。

3.頻繁に使用するメソッドを派生クラスに配置してみてください。

警告: PHP は継続的な改善プロセスを経ているため、将来状況が変わる可能性があります。

詳細

オブジェクトメソッド (クラスで定義された関数) の呼び出しが通常の関数の約 2 倍遅いことがわかりました。呼び出します。私にとって、これは非常に許容できるものであり、他の OOP 言語と同等です。

メソッド内 (以下の比率は概算のみです):

メソッド内でローカル変数をインクリメントするのが最も高速です。関数内でローカル変数を呼び出すのとほぼ同じです。
グローバル変数のインクリメントは、ローカル変数よりも 2 倍遅くなります。
オブジェクトプロパティ (例: $this->prop++) のインクリメントは、ローカル変数よりも 3 倍遅くなります。
未定義のローカル変数のインクリメントは、事前に初期化された変数のインクリメントよりも 9 ～ 10 倍遅くなります。
関数内で使用せずにグローバル変数を宣言するだけでも、処理が遅くなります (ローカル変数をインクリメントするのとほぼ同じ量)。 PHP はおそらく、グローバルが存在するかどうかを確認するチェックを行います。
メソッドの呼び出しは、クラスで定義されているメソッドの数に依存していないように見えます。テストクラスにメソッドを 10 個追加しました (テストメソッドの前後) が、パフォーマンスに変化はありませんでした。
派生クラスのメソッドは、基本クラスで定義されたメソッドよりも高速に実行されます。
1 つのパラメーターと空の関数本体を使用した関数呼び出しには、7 ～ 8 回の $localvar++ 操作を実行するのとほぼ同じ時間がかかります。もちろん、同様のメソッド呼び出しは約 15 の $localvar++ 操作になります。
更新: 2004 年 7 月 11 日: 上記のテストは、約 3 年前に PHP 4.0.4 で行われました。これを PHP4.3.3 で再度テストしたところ、関数の呼び出しには約 20 の $localvar++ 操作が必要となり、メソッドの呼び出しには約 30 の $localvar++ 操作が必要になりました。これは、$localvar++ の実行速度が速くなったか、関数の速度が遅くなったことが原因である可能性があります。

使用しているソフトウェア (Apache、PHP、IIS、データベース) を理解し、オペレーティングシステム、ネットワーキング、サーバーハードウェアに関する知識が深まるほど、コードとシステム。

PHP スクリプトの場合、通常、最もコストがかかるボトルネックは CPU です。ツイン CPU は、おそらく 2 ギガバイトの RAM よりも有用です。

「configure –-enable-inline-optimization」オプションを使用して PHP をコンパイルし、可能な限り最速の PHP 実行可能ファイルを生成します。

データベースを調整し、SQL WHERE 条件でよく使用されるフィールドのインデックスを作成します。非常に人気のあるデータベース抽象化ライブラリである ADOdb は、SQL チューニングモードを提供します。このモードでは、無効で高価で疑わしい SQL、その実行計画、および SQL が実行された PHP スクリプトを表示できます。

ほとんど変更されないデータがある場合は、HTML キャッシュを使用します。データが毎分変化する場合でも、データがキャッシュと同期されていれば、キャッシュが役に立ちます。コードの複雑さに応じて、パフォーマンスを 10 倍向上させることができます。

最も複雑なコードを早い段階で (または少なくともプロトタイプで) ベンチマークして、修正が手遅れになる前に予想されるパフォーマンスの感触をつかみます。適切にスケールされることを確認するために、現実的な量のテストデータを使用するようにしてください。
2004 年 7 月 11 日更新: すべての関数呼び出しの実行プロファイルを使用してベンチマークを行うには、xdebug 拡張機能を試すことができます。 xdebug の使用方法の簡単なチュートリアルについては、「xdebug を使用したコードの圧縮」を参照してください。これを行うための市販の製品もあります。ゼンドスタジオ。

オペコードキャッシュの使用を検討してください。これにより、コードの複雑さに応じて 10 ～ 200% の速度向上が得られます。キャッシュの中には他のものよりも信頼性の高いものがあるため、キャッシュをインストールする前に必ずいくつかのストレステストを実行してください。

コードの先頭で ob_start() を使用します。これにより、Apache の速度が無料で 5 ～ 15% 向上します。 gzip 圧縮を使用してダウンロードをさらに高速化することもできます (これには予備の CPU サイクルが必要です)。

Zend Optimizer のインストールを検討してください。これは無料で、いくつかの最適化を行いますが、Zend Optimizer がインストールされていると一部のスクリプトが実際に遅くなることに注意してください。コードに多数のループがある場合には、Zend Optimizer が適しているというのがコンセンサスです。現在、多くのオペコードアクセラレータが同様の機能を備えています (この文を 2003 年 10 月 21 日に追加)。

最初にループを最適化します。ループの不変式 (定数) をループの外に移動します。

可能な場合は配列関数と文字列関数を使用します。これらは、PHP で同等のコードを記述するよりも高速です。

複数の小さな文字列を 1 つの大きな文字列に連結する最も速い方法は、出力バッファ (ob_start) を作成し、そのバッファにエコーすることです。最後に、ob_get_contents を使用してコンテンツを取得します。これが機能するのは、通常、文字列連結ではメモリ割り当てが最大の要因であり、出力バッファリングでは 10K のチャンクで増加する大きな 40K の初期バッファが割り当てられるためです。 2004 年 6 月 22 日追加。

関数内の参照を使用してオブジェクトと配列を渡します。可能であれば、オブジェクトと配列も参照として返します。これが短いスクリプトであり、コードのメンテナンスが問題にならない場合は、グローバル変数を使用してオブジェクトまたは配列を保持することを検討できます。

セッション変数を使用する PHP スクリプトが多数ある場合は、セッション用の共有メモリモジュールを使用して PHP を再コンパイルするか、RAM ディスクを使用することを検討してください。これを「configure --with-mm」で有効にしてから PHP を再コンパイルし、php.ini で session.save_handler=mm を設定します。

部分文字列を検索する場合、最も速いコードは strpos() を使用し、次に preg_match()、最後に ereg() を使用します。同様に、str_replace() は preg_replace() よりも高速であり、preg_replace() は ereg_replace() よりも高速です。

2004 年 7 月 11 日追加: 最も頻繁に発生するケースを先頭にして大きな switch ステートメントを並べます。最も一般的なケースの一部がデフォルトセクションにある場合は、switch ステートメントの先頭でこれらのケースを明示的に定義することを検討してください。

XML を処理する場合、正規表現を使用した解析は、DOM や SAX を使用するよりも大幅に高速です。

メモリ使用量を削減するために、使用されなくなった変数を Unset() します。これは主にリソースや大きな配列に役立ちます。

深い階層を持つクラスの場合、派生クラス (子クラス) で定義された関数は、基本クラス (親クラス) で定義された関数よりも速く呼び出されます。基本クラスで最も頻繁に使用されるコードを派生クラスでも複製することを検討してください。

作成者が
strayly
(海外文摘)
::
コメント
(0)

の場合は、コードを PHP 拡張機能、Java クラス、または COM オブジェクトとして記述することを検討してください。