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

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

; error_reporting はビットフィールドです。または、目的のエラーを取得するための各數(shù)値
; E_ALL - すべてのエラーと警告
; E_WARNING - 実行時(shí)警告 (致命的ではないエラー)
;解析エラー
; E_NOTICE - 実行時(shí)の通知 (これらは、コードのバグによって生じることが多い警告です
; 意図的なものである可能性があります (例: 初期化されていない変數(shù)の使用や
; という事実に依存します)自動(dòng)的に E_CORE_ERROR - PHP の初期起動(dòng)中に発生する致命的なエラー
; E_CORE_WARNING - PHP の初期起動(dòng)中に発生する警告 (致命的ではないエラー) E_COMPILE_ERROR - 致命的なコンパイル時(shí)エラー (非致命的なエラー)致命的なエラー)
; 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 サイトでは、この機(jī)能をオフにして、代わりにエラーログを使用することを強(qiáng)くお?jiǎng)幛幛筏蓼?(以下を參照)。ユーザー (Web サーバー上のファイル パス、データベース スキーマ、その他の情報(bào))。
display_errors = On
; を使用する必要がないようにスクリプトを作成する必要があります。グローバルとしてのフォーム変數(shù)は、コードがよく考えられていない場(chǎng)合、簡(jiǎn)単にセキュリティ問題を引き起こす可能性があります。
register_globals = On

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

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

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

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

コードの最適化


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

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

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 を使用していない場(chǎng)合にのみ無効にできることに注意してください。Zend Encoder Runtime については後述します。

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

PHP アプリケーションがさらに高速化する必要がある場(chǎng)合、次の方法はバッファリングです。これを?qū)g現(xiàn)するには、いくつかの方法があります。 Zend Cache (評(píng)価版)、APC、Afterburner Cache を自分で試してみました。

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

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

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

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

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

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

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

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

output_handler = ob_gzhandler ;

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

php_value Output_handler ob_gzhandler

...または次の方法で PHP コード內(nèi)で直接呼び出します:

ob_start("ob_gzhandler")

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

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

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

結(jié)論

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

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

2. Web サーバーのパフォーマンスには限界があるため、サーバーのアクセス數(shù)が多いことが原因である可能性もあります。アップグレードするか、負(fù)荷分散の使用を検討してください (多額の費(fèi)用がかかります)

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