人気のある Web プログラミング言語としての PHP の最大の利点は速度です。 PHP4 はこれを非常にうまく行っており、これより高速なスクリプト言語はほとんどありません。ただし、アプリケーションの負荷が高く、帯域幅が比較的小さい場合、またはサーバーのパフォーマンスに影響を与える他のボトルネックがある場合は、私が処方した処方箋のいくつかを試して、それらが効果的であるかどうかを確認することをお勧めします。
人気のある Web プログラミング言語としての PHP の最大の利点は速度です。 PHP4 はこれを非常にうまく行っており、これより高速なスクリプト言語はほとんどありません。ただし、アプリケーションの負荷が高く、帯域幅が比較的小さい場合、またはサーバーのパフォーマンスに影響を与える他のボトルネックがある場合は、私が処方した処方箋のいくつかを試して、それらが効果的であるかどうかを確認することをお勧めします。
1. コードの最適化
コードの最適化というと、きちんとした明確なコードを思い浮かべるかもしれませんが、速度を追求したい場合は、PHP ソース コードに対応する調整を行う必要があるため、この記事の目的はそこではありません。一般に、コードを判読できなくするために、冗長なコメントは削除されます。しかし、優れた資質を持つプログラマーにとって、これは驚くべきことです。幸いなことに、Zend Technologies はこれを支援する Zend 最適化エンジンをリリースしました。現在は無料ですが、Zend Optimizer ライセンスに従う必要があります。本製品は、エンジンが生成する中間コードを最適化することができます。
このエンジンのインストールは比較的簡単です。 プラットフォームに対応するバージョンをダウンロードした後、圧縮ファイルを解凍し、次の 2 行を PHP.ini ファイルに追加し、Web サーバーを再起動します。完了しました。
zend_optimizer.optimization_level=15zend_extension="/path/to/ZendOptimizer.so"
zend_loader.enable=オフ
Win32 プラットフォームの場合は次のようになります:
zend_optimizer.optimization_level=15
zend_extension_ts="C:\path\to\ZendOptimizer.dll"
zend_loader.enable=オフ
あ!それは間違いではないですか?なぜ3行なのでしょうか?実際には 3 行目はオプションです。 zend_loader をオフにすると速度が少し向上するようなので、この 3 行目を PHP.ini に追加する価値があります。これをオフにする前提条件は、Zend 暗号化プログラムを使用していないことであることに注意してください。
2. バッファリング
さらに速度を向上させたい場合は、バッファリング技術の使用を検討する必要があります。 Zend Cache (ベータ版)、APC、Afterburner キャッシュ、jpCache などの代替ソリューションがいくつかあります。
上記はバッファ モジュールで、.PHP ファイルに対する最初のリクエストによって生成された中間コードを Web サーバーのメモリに保存し、後続のリクエストに対して「コンパイルされた」バージョンを返します。これにより、ディスクの読み取りと書き込み、およびメモリ内でのすべての作業が削減されるため、このプロセスによりアプリケーションのパフォーマンスが大幅に向上します。
このような製品は簡単に入手できるものがたくさんありますが、どれを選択すればよいでしょうか?
Zend Cache は優れた商用製品です。これらの大きな PHP ページを初めてロードすると、明らかに速度が向上し、サーバーがより多くのリソースを予約するようになります。残念ながら、この製品にはお金がかかりますが、場合によってはお金をケチりたくない場合があります。
Afterburner Cache は Bware Technologies の製品で、まだベータ版のようですが、Zend Cache ほど良い結果は得られず、Zend 最適化エンジンとも連携できません。無料なのでこのモジュールを採用しました。
APC (Alternative PHP Cache) も Community Connect が公開している無料モジュールで、本番環境でも使用できるようです。
3. Web コンテンツの圧縮
ますます混雑するネットワークにとって、帯域幅を節約することは水を節約することと同じくらい価値があります。 IETF 標準によれば、ほとんどのブラウザは gzip を使用して圧縮されたコンテンツをサポートする必要があります。つまり、gzip 圧縮されたコンテンツをブラウザに送信すると、ブラウザはデータを透過的に解凍します。
mod_gzip は、Remote Communications によって起動された無料の Apache モジュールで、静的な Web コンテンツを圧縮してブラウザに送信できます。ほとんどの静的 Web ページには、このモジュールが適しています。
ですが
Remotecommunications の関係者は、このモジュールは mod_PHP、mod_perl、mod などによって生成されるすべての動的コンテンツをサポートしていると言っていますが、mod_gzip メーリング リストから判断すると、この問題はまだ解決されていないようです。 1.3.14.6fにあります。動的コンテンツを圧縮したい場合は、スクリプトの最初と最後で使用される PHP クラス、class.gzip_encode.PHP を使用できます。 Web サイト全体では、php.ini の auto_prepend および auto_append 内の関数が呼び出されます。詳細については、このクラスのプログラムを参照してください。このプログラムには十分なコメントがあり、著者がほぼすべてを説明しています。ただし、使用する前に、zlib をサポートするように PHP をコンパイルする必要があります。
PHP 4.0.4 の場合、新しい解決策は ob_gzhandler を使用することです。これにより、次の文を php.ini に追加するだけで、上記のクラスと同じ効果を実現できます。
output_handler = ob_gzhandler ;これにより、PHP が出力バッファリングをアクティブ化し、すべての出力を圧縮できるようになります。すべてのコンテンツを圧縮して出力したくない特別な理由がある場合は、.htAccess ファイルに次の行を追加して、対応するディレクトリ内のファイルを圧縮できます。
PHP_value 出力ハンドラー ob_gzhandler
PHP コードに直接追加することもできます:
ob_start("ob_gzhandler");
この圧縮技術は非常に効果的ですが、Netscape Communicator ユーザーの場合、グラフィック ファイルは圧縮できないため、不完全に送信されたように見えるため、IE ではこの問題は発生しません。jpeg および gif ファイルの圧縮をオフにする必要があります。
結論:
この記事で説明した手法を採用すると、Web サイトのパフォーマンスが向上しますが、次の点に注意してください。
- PHP がボトルネックの原因ではない可能性があります。他の原因 (データベースなど) を再確認してください
-サーバーのパフォーマンスを最高の状態に調整することはできません。したがって、PHP とそのバッファリングについて文句を言う前に、サーバーをアップグレードするか、動的負荷分散テクノロジー (多額の費用がかかります) を採用する時期なのかを検討してください。
- コンテンツの圧縮を過小評価しないでください。100 MB のイントラネット上の PHP アプリケーションの速度が向上している一方で、モデム ユーザーが 100 KB の HTML ページについて不満を抱いていることを忘れないでください。