PHP の実行速度を向上させるための完全なガイド_PHP チュートリアル

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

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

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

; - 通知を除くすべてのエラーを表示します
; = E_ALL & ~E_NOTICE

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

;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR

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

error_reporting = E_ALL & ~E_NOTICE
;出力)。本番 Web サイトでは、この機能をオフにして、代わりにエラーログを使用することを強くお勧めします (以下を参照)。ユーザー (Web サーバー上のファイル パス、データベース スキーマ、その他の情報)。
display_errors = On
; を使用する必要がないようにスクリプトを作成する必要があります。グローバルとしてのフォーム変数は、コードがよく考えられていない場合、簡単にセキュリティ問題を引き起こす可能性があります。
register_globals = On

; ファイルの場合、これはデータが格納されるパスです。注: Windows ユーザーは、PHP のセッション関数を使用するために、この変数を変更する必要があります。
session.save_path = "c:/winnt/temp" (存在する独自のディレクトリに変更できます)

; cgi.force_redirect は、ほとんどの Web サーバーで PHP を CGI として実行するために必要です。PHP はデフォルトで有効にします。** 安全に有効にできます。 IIS ではこれをオフにする必要があります。**
cgi.force_redirect = 0

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

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

コードの最適化


よりクリーンなコードを書く方法については、誰もが知っていると思いますが、速度が必要な場合は、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.remotecommunications.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 サーバーのパフォーマンスには限界があるため、サーバーのアクセス数が多いことが原因である可能性もあります。アップグレードするか、負荷分散の使用を検討してください (多額の費用がかかります)

3. 100Mb/s LAN では、PHP アプリケーションは非常に優れたパフォーマンスを発揮する可能性があります。遅いモデムを使用するユーザーを考慮する必要があります。

http://www.bkjia.com/PHPjc/314745.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/314745.html技術記事 Php セットアップの問題;;;;;;;;;;;;;;;;;;;;;;; エラー処理とログ記録。必要なエラーを取得するまでの各数値 E_ALL - すべて...