人気のある Web プログラミング言語としての PHP の最大の利点は速度です。 PHP4 はこれを非常にうまく行っており、これより高速なスクリプト言語はほとんどありません。ただし、アプリケーションの負荷が高く、帯域幅が比較的小さい場合、またはサーバーのパフォーマンスに影響を与える他のボトルネックがある場合は、私が処方した処方箋のいくつかを試して、それらが効果的であるかどうかを確認することをお勧めします。
1. コードの最適化
コードの最適化というと、整然とした明確なコードを思い浮かべるかもしれませんが、これはこの記事の意味ではありません。速度を追求したい場合は、PHP に対応する調整を行う必要があるからです。ソースコード。一般に、コードを判読できなくするために、冗長なコメントは削除されます。しかし、優れた資質を持つプログラマーにとって、これは驚くべきことです。幸いなことに、Zend Technologies はこれを支援する Zend 最適化エンジンをリリースしました。現在は無料ですが、Zend Optimizer ライセンスに従う必要があります。本製品は、エンジンが生成する中間コードを最適化することができます。
このエンジンのインストールは比較的簡単で、プラットフォームに対応するバージョンをダウンロードした後、圧縮ファイルを解凍し、次の 2 行を php.ini ファイルに追加し、Web サーバーを再起動すれば完了です。
zend_optimizer.optimization_level=15
zend_extension="/path/to/ZendOptimizer.so"
zend_loader.enable=Off
Win32 プラットフォームの場合は、次のようにする必要があります:
zend_optimizer.optimization_level=15
zend_extension_ts= "C:pathtoZendOptimizer.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 Output_handler ob_gzhandler
PHP コードに直接追加することもできます:
ob_start("ob_gzhandler");この圧縮技術は非常に効果的ですが、Netscape Communicator ユーザーの場合、グラフィック ファイルは圧縮できないため、不完全に送信されたように見えるため、IE では jpeg および gif ファイルの圧縮をオフにする必要があります。
結論:
この記事で説明した手法を採用すると、Web サイトのパフォーマンスが向上するはずですが、次の点にご注意ください:
- PHP がボトルネックの原因ではない可能性があります。他の原因 (例: データベース) を再確認してください
- あなたサーバーのパフォーマンスを最高の状態に調整することは不可能です。したがって、PHP とそのバッファリングについて文句を言う前に、サーバーをアップグレードするか、動的負荷分散テクノロジー (多額の費用がかかります) を採用する時期なのかを検討してください。
- コンテンツの圧縮を過小評価しないでください。100 MB のイントラネット上の PHP アプリケーションの速度が向上している一方で、モデム ユーザーが 100 KB の HTML ページについて不満を抱いていることを忘れないでください。