PHP の実行速度を向上させるための完全なガイド-php手册-php.cn

PHP セットアップの問題と高速化に関する提案使用中にphpの設定が間違っていてアプリケーションが使用できない場合は、php.iniの以下のパラメータ設定を確認してください。
以下では、PHPがd:/php/

にインストールされていることを前提としています。 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; エラー処理とログ記録 ;

;または、目的のエラーを取得するための各数値
; E_ALL - すべてのエラーと警告
; E_WARNING - 実行時警告(致命的でないエラー)
; E_PARSE - コンパイル時の解析エラー
; E_NOTICE - 実行時の通知 (これらは、コードのバグによって生じることが多い警告です。ただし、
; 意図的 (例: 初期化されていない変数と
を使用; 自動的に
; 空の文字列に初期化されることに依存)
; E_CORE_ERROR - PHP の初期起動時に発生する致命的なエラー
; >; E_CORE_WARNING - PHP の初期起動中に発生する警告 (致命的ではないエラー)
; E_COMPILE_ERROR - ユーザーが生成したエラーメッセージ
; -生成された警告メッセージ
; E_USER_NOTICE - ユーザーが生成した通知メッセージ

; 例:

;error_reporting = E_ALL & ~E_NOTICE

; - エラーのみを表示します

;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR

; - 通知を除くすべてのエラーを表示します

error_reporting = E_ALL & ~E_NOTICE
; エラーを出力します (出力の一部として)。
; 代わりに、この機能をオフにして、エラーログを使用することを強くお勧めします。以下)。本番 Web サイト
で display_errors を有効にしておくと、Web サーバー上のファイルパス、データベーススキーマ、その他の情報がエンドユーザーに公開される可能性があります。
; 🎜>
; register_globals をオンにする必要がないように、最善を尽くしてスクリプトを作成する必要があります。
;
register_globals = On

; ファイルの場合、これはデータファイルが保存されるパスです。 PHP のセッション関数を使用するために、この
変数を変更します。
session.save_path = "c:/winnt/temp"(既存のディレクトリに変更できます)

;
で PHP を CGI として実行するセキュリティを提供するために必要です。PHP はデフォルトでオンにします。
; **あなたは自分の責任でこれをオフにできます。 IIS ではこれを安全にオフにできますが、実際には必ずオフにする必要があります。**
cgi.force_redirect = 0

; ロード可能な拡張機能 (モジュール) が存在するディレクトリ。
extension_dir = ./extensions /
; または、d:/php/extensions/

などの絶対ディレクトリに設定します。たとえば、画像管理システムがそれを使用します。 d:/php/extensions/.
extension=php_gd.dll
の下にあります PHP の利点の 1 つは非常に高速であることです。一般的な Web サイトアプリケーションには十分であると言えます。ただし、サイトのトラフィックが多い、帯域幅が狭い、またはその他の要因によりサーバーのパフォーマンスのボトルネックが発生する場合は、PHP の速度をさらに向上させるための他の方法を考える必要がある場合があります。この記事では、ユーザーがより「クール」に閲覧できるようにするための方法をいくつかの側面から紹介します。

コードの最適化

もう言いません
速度が必要な場合は、これを誰もが知っていると思います。ここで提案されているのは、この面倒な作業を他のツールで完了できるということです。これは Zend Optimizer であり、Zend Technologies の Web サイト (http://www.zend.com/) から無料で入手できるプログラムです。その原理はシンプルで、Zend エンジンによって生成された中間コードを検出し、それを最適化することでより高い実行速度を実現します。コードの最適化はかなり面倒な作業だと思います。また、最適化されたコードは理解しにくくなる可能性があります。特に、PHP プログラムをしばらく放置していて、突然顧客から変更を求められた場合、自分では何をすればよいか分からないかもしれません。。わかった ;-）。したがって、PHP ソースコードが比較的複雑な場合は、Zend Optimizer を使用してこの最適化作業を行うことをお勧めします。その利点は、コードが複雑になって理解しにくくならないことです。

Zend Optimizer のインストールは非常に簡単です。使用しているプラットフォームに応じて、関連するプリコンパイル済みライブラリをダウンロードし、php.ini に 2 行を追加して、Web サーバーを再起動するだけです。

zend_optimizer.optimization_level=15zend_extension="/path/to/ZendOptimizer.so" zend_loader.enable=Off

少し奇妙かもしれません。2 行書かれていませんでしたか、なぜ3行になりますか？ただし、3 行目はオプションです。この zend_loader を無効にすると最適化が速くなるようです。そのため、この行を php.ini ファイルに追加するとよいでしょう。 zend_loader は、Zend Encoder Runtime を使用していない場合にのみ無効にできることに注意してください。Zend Encoder Runtime については後述します。

もっと早くしたいですか?キャッシュを使用する

PHP アプリケーションにさらに高速な速度が必要な場合、次の解決策はキャッシュです。これを実現するには、いくつかの方法があります。 Zend Cache (評価版)、APC、Afterburner Cache を自分で試してみました。

上記のものはすべて「バッファモジュール」です。それらの原理は似ています。PHP ファイルが初めてリクエストされたとき、PHP ソースコードの中間コードを Web サーバーのメモリに保存することで、その後の同じリクエストに対して、「コンパイルされた」バージョンがメモリに直接保存されます。提供された。この方法はディスクアクセスを最小限に抑えることができるため、実際に PHP のパフォーマンスを大幅に向上させることができます。さらに便利なのは、PHP ソースコードが変更されると、バッファリングされたモジュールがこれらの変更を検出して再ロードできるため、顧客が古いバージョンのプログラムを入手することを心配する必要がないことです。これらのバッファ付きモジュールは優れていますが、どれを選択すればよいでしょうか?それぞれ紹介しましょう:

Zend Cache は Zend Technologies の商用製品です (PHP エンジンと Zend Optimizer を無料で提供している会社でもあります)。本当に悪くありません。最初の実行後、明らかに PHP の速度が大幅に向上し、サーバーの空きリソースが増えていることがわかります。デメリットとしては、料金がかかることですが、コストパフォーマンスを考えると、それでも十分に価値があります。

Afterburner Cache は、Bware Technologies (bwcache.bware.it) が提供する無料のバッファモジュールです。現在はベータ版のみで、Zend Cache と同じ働きをするようですが、パフォーマンスの向上は Zend Cache ほどではなく、既存のバージョンは Zend Optimizer では動作しませんが、無料です。

APC (Alternative PHP Cache) は、Community Connect (apc.communityconnect.com) によって提供されるもう 1 つの無料モジュールです。動作は非常に安定しており、速度も大幅に向上しています。ただし、これらは私のアプリケーションでのテストにすぎないため、結論を出すことはできません。 Web コンテンツの圧縮 (顧客がより「楽しく」使えるようにする)

上記の 2 つの方法の後、PHP アプリケーションのパフォーマンスは大幅に向上したと思います。別の側面から考えてみます: ダウンロード速度。アプリケーションが社内でのみ実行されており、すべての顧客が 100Mb/s イーサネットを使用してサーバーに接続している場合は、これは問題にならない可能性がありますが、一部の顧客が低速のモデム接続を使用している場合は、コンテンツ圧縮方式の使用を検討する必要があります。。
IETF 仕様によれば、ほとんどのブラウザは gzip コンテンツ
圧縮をサポートしています。これは、Web コンテンツをクライアントのブラウザに送信する前に gzip を使用して圧縮できることを意味し、ブラウザはデータを受信する際に自動的にデータを解凍し、ユーザーが元のページを表示できるようにします。同様に、Web ページのコンテンツを圧縮する方法もいくつかあります。

mod_gzip は、Remote Communications (http://www.phpbuilder.com/columns/www.remoteecommunications.com) によって無料で提供される Apache モジュールで、静的な Web ページを圧縮できます。 Apache でコンパイルする (または DSO として使用する) だけで問題なく動作します。 Remotecommunications の関係者によると、mod_php、mod_perl などの動的コンテンツも圧縮できるそうです。しかし、試してみましたが、うまくいかないようです。 mod_gzip メーリングリストで、このバグは次のバージョン (バージョン 1.3.14.6f になると思います) で修正される予定であると読みました。ただし、静的コンテンツの圧縮には引き続き使用できます。

しかし、動的コンテンツも圧縮したいので、別の方法を見つける必要があります。 1 つの方法は、class.gzip encode.php (http://leknor.com/code/) を使用することです。この PHP クラスを PHP スクリプトの最初と最後で呼び出して、ページのコンテンツを圧縮します。サイト全体でそのような圧縮が必要な場合は、php.ini ファイルの auto_prepend および auto_append でこれらの関数を呼び出すことができます。これは非常にうまく機能しますが、負荷の高いサイトでは明らかに多少のオーバーヘッドが発生します。どのように動作するかについて詳しくは、クラスコードを参照してください (少なくとも zlib サポートを使用して PHP をコンパイルする必要があります)。著者による説明書も非常に詳しく書かれているので、知りたいことはすべてわかります。

最近、PHP の出力バッファリングに関する記事も目にしました。つまり、PHP4.0.4 では新しい出力バッファ処理メソッド ob_gzhandler が導入されており、その機能は上で紹介したクラスと同じですが、 php.ini で次の構文を使用するだけで済むという点が異なります。

output_handler = ob_gzhandler ;

これにより、PHP の出力バッファリング機能が有効になり、送信されるすべてのデータが圧縮されます。いくつかの特別な理由により、ここで設定せず、必要な場合のみデフォルト設定を変更する場合 (圧縮なし)、圧縮する必要がある PHP ソースコードディレクトリ内の .htaccess ファイルを変更するだけです。使用される構文は次のとおりです。

php_value Output_handler ob_gzhandler

... または、次の方法で PHP コード内で直接呼び出します。

ob_start("ob_gzhandler" ); >
この出力バッファリング方法は優れており、サーバーに追加のシステムオーバーヘッドをもたらしません。この方法を使用することを強くお勧めします。その変化は次の例で説明できます。顧客が 28.8K モデムを使用している場合、このプロセスの後、突然 ISDN アクセスに切り替えられたと考えるでしょう。注意すべき点が 1 つあります。Netscape Communicator は画像圧縮をサポートしていないため、画像は表示されません。したがって、顧客全員が Internet Explorer を使用している場合を除き、jpeg および gif 画像の圧縮を無効にする必要があります。他のファイルの圧縮には問題はありませんが、特にブラウザが珍しいプラグインを使用している場合や、めったに使用されないブラウザの場合は、テストすることをお勧めします。

その他の便利なもの...

Zend Technologies のオンラインストアは今年 1 月 24 日に開設され、いくつかの興味深い PHP 関連製品を販売しています。前述の Zend Cache、Zend Encoder (簡単に言えば、ソースコードの漏洩を心配せずに顧客に販売できるように、コンパイルされたクラスを生成できる PHP コード用のコンパイラーです。これらのクラスを実行する必要がある Web サーバーで (デコードには Zend Encoder Runtime を使用します)、Zend Ide (多くの強力な機能を備えた PHP 用の統合開発環境)、および PHP 開発者向けのサポートサービスを提供します。

結論

この記事で説明したテクニックを使用すると、サイトのパフォーマンスを大幅に向上させることができますが、次の点に注意してください。

1.ボトルネックは存在しない可能性があります。PHP の場合、アプリケーション内のすべてのオブジェクト (データベースなど) を調べる必要があります。

2. Web サーバーのパフォーマンスには限界があるため、パフォーマンスの低下が原因であるとは考えないでください。 PHP へのアクセスが原因である可能性もあります。ボリュームが非常に大きいため、サーバーをアップグレードするか、負荷分散システムの使用を検討してください (多額の費用がかかります)

3. 100Mb/s LAN では、PHP アプリケーションは適切に動作する可能性がありますが、低速モデムを使用するユーザーを考慮する必要があります。