PHP_PHP チュートリアルのチューニング

Apache は高度に構成可能なソフトウェアです。機能が豊富ですが、それぞれの機能が高価です。 Apache のチューニングには、適切な方法でリソースを割り当てることも含まれます。また、必要なものだけを含めるように構成を簡素化することも含まれます。
MPM を構成する
Apache はモジュール式であるため、機能を簡単に追加および削除できます。 Apache の中核となるマルチプロセッシング モジュール (MPM) は、ネットワーク接続の管理とリクエストのスケジュール設定というモジュール式の機能を提供します。 MPM を使用すると、スレッドを使用したり、Apache を別のオペレーティング システムに移行したりすることもできます。
一度にアクティブにできる MPM は 1 つだけであり、 --with-mpm=(worker|prefork|event) を使用して静的にコンパイルする必要があります。
リクエストごとに 1 つのプロセスを使用する従来のモデルは、プリフォークと呼ばれます。ワーカーと呼ばれる新しいスレッド モデルは、それぞれが複数のスレッドを持つ複数のプロセスを使用して、より低いオーバーヘッドでより優れたパフォーマンスを実現します。最新のイベント MPM は、さまざまなタスクに個別のスレッド プールを使用する実験モデルです。どの MPM が使用されているかを確認するには、httpd -l を実行します。
どの MPM を使用するかの選択は、多くの要因によって決まります。イベント MPM が実験的な状態を離れるまで、このモデルは考慮されるべきではなく、スレッドを使用するか使用しないかの選択が必要です。一見すると、すべての基礎となるモジュール (PHP で使用されるすべてのライブラリを含む) がスレッドセーフである場合、スレッド化の方がフォークよりも優れています。 Prefork はより安全な選択です。ワーカーを選択する場合は、慎重にテストする必要があります。パフォーマンスの向上は、ディストリビューションに含まれるライブラリとハードウェアによっても異なります。
どの MPM を選択するかに関係なく、適切に構成する必要があります。一般に、MPM の構成には、実行中のワーカーの数と、ワーカーがスレッドかプロセスかを制御する方法を Apache に指示することが含まれます。プリフォーク MPM の重要な構成オプションをリスト 1 に示します。

リスト 1. プリフォーク MPM の構成
                                            スタートサーバー 50
MinSpareServers 15
MaxSpareServers 30
最大クライアント数 225
子供あたりの最大リクエスト数 4000

独自のソフトウェアをコンパイルします
私が初めて UNIX® を使い始めたとき、システムに組み込まれるすべてのものに対してソフトウェアをコンパイルすることにこだわりました。結局、更新の維持に問題が生じたので、このタスクを簡素化するパッケージを構築する方法を学びました。その後、ほとんどの場合、リリース バージョンと同じことを行っていることに気づきました。現在、私はほとんどの場合、選択したディストリビューションが提供するすべてのものを可能な限り使用し、必要な場合にのみ独自のパッケージを使用するようにしています。
同様に、最新かつ最高のコードを使用するよりも、ベンダー提供のパッケージを使用する方が保守性の点で優れていることがわかる場合があります。場合によっては、パフォーマンスのチューニングとシステム管理の目標が矛盾することがあります。 Linux の商用バージョンを使用している場合、またはサードパーティのサポートに依存している場合は、ベンダーのサポートを検討する必要がある場合があります。
独自のやり方を貫きたい場合は、ディストリビューションで動作するパッケージを構築する方法と、それらをパッチ適用システムに統合する方法を学びましょう。これにより、ソフトウェアと加えた変更が一貫して構築され、複数のシステム間で動作することが保証されます。また、ソフトウェア更新をタイムリーに受信するには、適切なメーリング リストと RSS フィードを購読する必要があります。
プリフォーク モデルは、リクエストごとに新しいプロセスを作成します。冗長プロセスは受信リクエストを処理するためにアイドル状態を維持するため、起動の待ち時間が短縮されます。事前に構成された構成では、Web サーバーが起動するとすぐに 50 のプロセスが開始され、10 ～ 20 のアイドル状態のサーバーを実行し続けようとします。プロセス数のハード制限は MaxClients によって指定されます。プロセスは多数の連続リクエストを処理できますが、Apache は接続数が 4,000 を超えるとプロセスをキャンセルするため、メモリ リークのリスクが軽減されます。
スレッド MPM の構成も同様ですが、使用するスレッドとプロセスの数を決定する必要があります。 Apache のドキュメントでは、必要なすべてのパラメータと計算について説明しています。
使用する値を選択するには、いくつかの試行錯誤が必要です。最も重要な値は MaxClients です。目標は、サーバーに過度のスワップを行わせることなく、十分なワーカー プロセスまたはスレッドを実行できるようにすることです。受信リクエストが処理能力を超えた場合、少なくともこの値を満たすリクエストが処理され、他のリクエストはブロックされます。
MaxClients が高すぎると、Web サーバーが 1 つのプロセスを交換して別のプロセスを実行できるようにしようとするため、すべてのクライアントでサービスが低下します。設定が低すぎると、サービスが不必要に拒否される可能性があります。この値は、高負荷下で実行されているプロセスの数と、すべての Apache プロセスによって発生するメモリ フットプリントを確認して設定すると役立ちます。 MaxClients の値が 256 を超える場合は、ServerLimit も同じ値に設定する必要があります。関連情報については、MPM ドキュメントをよくお読みください。
サーバーの役割に基づいて、起動およびアイドル状態を維持するサーバーの数を調整します。サーバーが Apache のみを実行している場合は、マシンを最大限に活用できるため、リスト 1 に示すように適度な値を使用できます。システム内に他のデータベースまたはサーバーがある場合は、実行中のアイドル状態のサーバーの数を制限する必要があります。
オプションとオーバーライドを効果的に使用する
Apache によって処理されるすべてのリクエストは、Web サーバーが従う必要がある制約や特別な指示を指定する複雑なルールのセットを満たします。フォルダーへのアクセスを IP アドレスによって特定のフォルダーに制限したり、ユーザー名とパスワードを構成したりできます。これらのオプションには、ディレクトリ リストが提供されるかどうか、ファイルの処理方法、出力を圧縮するかどうかなど、特定のファイルの処理も含まれます。
これらの設定は、使用されている設定がディスク上の場所を参照していることを指定する などの httpd.conf 内のコンテナとして表示され、または参照が URL 内のパスであることを示す などのコンテナとして表示されます。リスト 2 は、実際の Directory コンテナーを示しています。

リスト 2. ルート ディレクトリに適用されるディレクトリ コンテナ
                                            <ディレクトリ />
許可オーバーライドなし
オプションフォローSymLinks

リスト 2 では、Directory タグと /Directory タグのペアの間の構成が、指定されたディレクトリとそのディレクトリ下のすべてに適用されます。この場合、指定されたディレクトリはルート ディレクトリです。ここで、AllowOverride タグは、ユーザーがオプションを上書きできないことを示します (これについては後で詳しく説明します)。 FollowSymLinks オプションが有効になっているため、ファイルが Web ファイルを含むディレクトリの外にある場合でも、Apache が以前のシンボリック リンクを参照してリクエストを処理できるようになります。これは、Web ディレクトリ内のファイルが /etc/passwd へのシンボリック リンクである場合、Web サーバーは要求されたときにそのファイルを正常に提供することを意味します。 -FollowSymLinks を使用すると、この機能は無効になり、同じ要求によってクライアントにエラーが返されます。
このラストシーンは2つの懸念を引き起こすものです。最初の側面はパフォーマンスに関連しています。 FollowSymLinks が無効になっている場合、Apache はそのファイル名を使用しているすべてのコンポーネント (ディレクトリとファイル自体) をチェックして、それらがシンボリック リンクではないことを確認する必要があります。これにより、追加のオーバーヘッド (ディスク操作) が発生します。 FollowSymLinksIfOwnerMatch という別のオプションは、ファイル所有者が接続所有者と同じである場合にシンボリック リンクを使用します。最高のパフォーマンスを得るには、リスト 2 のオプションを使用してください。
この時点で、セキュリティを重視する読者は注意する必要があります。セキュリティは常に機能とリスクの間のトレードオフです。私たちの場合、機能は速度であり、リスクはシステム上のファイルへの不正アクセスを許可することです。リスク軽減策の 1 つは、LAMP アプリケーション サーバーが通常 1 つの特定の機能に重点を置き、ユーザーが危険なシンボリック リンクを作成できないようにすることです。シンボリック リンクを有効にする必要がある場合は、リスト 3 に示すように、シンボリック リンクをファイル システムの特定の領域に制限できます。

リスト 3. FollowSymLinks をユーザーのディレクトリに制限する
                                            <ディレクトリ />
オプションフォローSymLinks

<ディレクトリ /home/*/public_html>

オプション -SymLinks をフォロー

リスト 3 では、ユーザーのホーム ディレクトリ内の public_html ディレクトリとそのすべてのサブディレクトリから FollowSymLinks オプションが削除されています。

ご覧のとおり、マスター サーバー構成を通じて、ディレクトリごとにオプションを個別に構成できます。ユーザーは、ディレクトリに .htaccess ファイルを配置するだけで、このサーバー設定を自分でオーバーライドできます (管理者がAllowOverrides ステートメントでこれを許可している場合)。このファイルには、.htaccess ファイルを含むディレクトリが要求されるたびにロードされて適用される追加のサーバー ディレクティブが含まれています。ユーザーのいないシステムの問題については以前に議論しましたが、多くの LAMP アプリケーションはこの機能を利用してアクセスを制御し、URL 書き換えを実装するため、その仕組みを理解する必要があります。
たとえ、AllowOverrides ステートメントによってユーザーが望ましくないことを実行できないとしても、Apache は .htaccess ファイルをチェックして、実行すべき作業があるかどうかを確認する必要があります。親ディレクトリでは、サブディレクトリからのリクエストによって処理されるディレクティブを指定できます。これは、Apache がディレクトリ ツリーのすべてのコンポーネントでリクエストされたファイルを検索する必要があることを意味します。ご想像のとおり、これにより、リクエストごとに大量のディスク操作が発生します。
最も簡単な解決策は、書き換えを禁止することです。これにより、Apache が .htaccess をチェックする必要がなくなります。それ以降の特別な構成は、httpd.conf に直接配置されます。リスト 4 は、ユーザーのプロジェクト ディレクトリのパスワード チェックを、.htaccess ファイルに入れてAllowOverrides に依存するのではなく、httpd.conf に追加したコードを示しています。

リスト 4. .htaccess 構成を httpd.conf に移動する

                                            <ディレクトリ /home/user/public_html/project/>
AuthUserFile /home/user/.htpasswd
認証名「uber 秘密プロジェクト」
認証タイプ基本
有効なユーザーが必要です


構成を httpd.conf に移動し、AllowOverrides を無効にすると、ディスク使用量を削減できます。 1 人のユーザーのプロジェクトは多くのクリックを集めないかもしれませんが、このテクノロジーが混雑したサイトに適用されるとどれほど強力になるかを想像してみてください。

場合によっては、.htaccess ファイルの使用を完全に排除することができない場合があります。たとえば、リスト 5 では、オプションはファイル システムの特定の部分に制限されており、オーバーライドの範囲を指定することもできます。

リスト 5. .htaccess チェックのスコープ設定

                                            <ディレクトリ />

オーバーライドを許可しない


<ディレクトリ /home/*/public_html>
AllowOverrides AuthConfig

リスト 5 を実装した後、Apache は親ディレクトリで .htaccess ファイルを探しますが、この機能は残りのファイル システムでは無効になっているため、public_html ディレクトリで停止します。たとえば、リクエストが /home/user/public_html/project/notes.html にマップされたファイルに対するものである場合、public_html ディレクトリとプロジェクト ディレクトリのみが検索されます。
各ディレクトリを個別に構成する場合の最後のヒント: 順番に実行してください。 Apache のチューニングに関する記事には、サーバーに接続されているすべての IP アドレスを逆解決しようとするのはリソースの無駄であるため、HostnameLookups off ディレクティブを使用して DNS ルックアップを無効にする必要があることが記載されています。ただし、ホスト名ベースの制約により、Web サーバーはクライアントの IP アドレスの逆引き参照とその結果の前方参照を実行して、名前の信頼性を検証する必要があります。したがって、クライアントのホスト名ベースのアクセス制御の使用を避け、使用する必要がある場合にはその範囲を制限することが賢明です。
持続的な接続
クライアントが Web サーバーに接続する場合、クライアントは同じ TCP 接続を介して複数のリクエストを行うことができるため、複数の接続に伴う待ち時間が短縮されます。これは、Web ページが複数の画像を参照する場合に便利です。クライアントは、単一の接続でページを要求し、その後すべての画像を要求できます。欠点は、サーバー上のワーカー プロセスが次のリクエストに進む前に、クライアントがセッションを閉じるのを待たなければならないことです。
Apache を使用すると、永続的な接続 (キープアライブと呼ばれる) の処理方法を構成できます。 httpd.conf グローバル KeepAlive 5 を使用すると、接続が強制的に閉じられる前に、サーバーは接続上で 5 つのリクエストを処理できます。この値を 0 に設定すると、永続的な接続が無効になります。 KeepAliveTimeout もグローバル レベルで、Apache がセッションを閉じる前に別の接続を待機する時間を決定します。
永続的な接続の処理は、「1 つのサイズですべてに適合する」構成ではありません。一部の Web サイトではキープアライブを無効にする方が適切ですが (KeepAlive 0)、有効にすると大きなメリットが得られます。唯一の解決策は、両方の構成を試して、どちらがより適しているかを自分の目で確認することです。ただし、キープアライブが有効な場合は、2 などの小さいタイムアウト (KeepAliveTimeout 2) を使用することが賢明です。これにより、別のリクエストを行うクライアントに十分な時間が確保され、ワー​​カー プロセスが決して来る可能性のない次のリクエストを待ってアイドル状態になることがなくなります。
圧縮
Web サーバーは、出力をクライアントに送り返す前に圧縮できます。これにより、Web サーバーの CPU サイクルが犠牲になり、インターネット経由で送信されるページが小さくなります。 CPU オーバーヘッドに余裕のあるサーバーにとって、これはページのダウンロードを高速化する優れた方法です。ページが元のサイズの 3 分の 1 に圧縮されることも珍しくありません。
通常、画像はすでに圧縮されているため、圧縮はテキスト出力に限定する必要があります。 Apache は mod_deflate を通じて圧縮を提供します。 mod_deflate は簡単に有効にできますが、複雑すぎるため、多くのマニュアルで説明されています。この記事では圧縮の設定については説明しませんが、適切なドキュメントへのリンクを提供します (「参考文献」セクションを参照)。
PHPのチューニング
PHP はアプリケーション コードを実行するエンジンです。使用する予定のモジュールのみをインストールし、すべての静的ファイルではなく、スクリプト ファイル (通常は .php で終わるファイル) にのみ PHP を使用するように Web サーバーを構成する必要があります。
オペコードキャッシュ
PHP スクリプトが要求されると、PHP はスクリプトを読み取り、実行されるコードのバイナリ表現である Zend オペコードにコンパイルします。このオペコードは PHP によって実行され、破棄されます。オペコード キャッシュは、このコンパイルされたオペコードを保存し、次回ページが呼び出されたときに再利用します。これにより時間を大幅に節約できます。利用可能なキャッシュは複数ありますが、私がより一般的に使用するキャッシュは eAccelerator です。
eAccelerator をインストールするには、コンピュータに PHP 開発ライブラリが必要です。 Linux ディストリビューションによってファイルの保存場所が異なるため、eAccelerator の Web サイトからインストール手順を直接入手することをお勧めします (リンクについては「リソース」セクションを参照)。また、ディストリビューションにすでにオペコード キャッシュが含まれている可能性もあり、これをインストールするだけで済みます。
システムに eAccelerator をインストールする方法に関係なく、注意すべき構成オプションがいくつかあります。設定ファイルは通常、/etc/php.d/eaccelerator.ini です。 eaccelerator.shm_size は、コンパイルされたスクリプトが保存される共有キャッシュのサイズを定義します。値はメガバイト (MB) 単位です。用途に応じて適切なサイズを決定してください。 eAccelerator は、メモリ使用量を含むキャッシュのステータスを表示するスクリプトを提供します。64MB が適切な選択です (eaccelerator.shm_size="64")。選択した値が受け入れられない場合は、カーネルの最大共有メモリ サイズを変更する必要があります。 kernel.shmmax=67108864 を /etc/sysctl.conf に追加し、sysctl -p を実行して設定を有効にします。 kernel.shmmax 値の単位はバイトです。
共有メモリの割り当てが制限を超える場合、eAccelerator は古いスクリプトをメモリから消去する必要があります。デフォルトでは、これは無効になっています。eaccelerator.shm_ttl = "60" は、eAccelerator が共有メモリを使い果たしたときに、60 秒以内にアクセスされなかったすべてのスクリプトをクリアすることを指定します。
もう 1 つの人気のある eAccelerator の代替品は、Alternative PHP Cache (APC) です。 Zend のベンダーは、効率をさらに向上させるオプティマイザを含む商用オペコード キャッシュも提供しています。
php.ini
PHP の設定は php.ini で行われます。表 1 に示す 4 つの重要な設定は、PHP が使用できるシステム リソースの量を制御します。

表 1. php.ini のリソース関連の設定
設定 説明 推奨値
max_execution_time スクリプトが使用できる CPU 秒数 30
max_input_time スクリプトが入力データを待つ時間 (秒) 60
Memory_limit スクリプトがキャンセルされるまでに使用できるメモリ量 (バイト) 32M
Output_buffering データをクライアントに送信する前にキャッシュする必要があるデータ量 (バイト) 4096
正確な数はアプリケーションによって大きく異なります。ユーザーから大きなファイルを受信して​​いる場合は、php.ini で変更するかコードでオーバーライドすることにより、max_input_time を増やす必要がある場合があります。同様に、CPU やメモリをより多く使用するプログラムでは、より大きな設定が必要になる場合があります。目的は過剰なプログラムの影響を軽減することであるため、これらの設定をグローバルに無効にすることはお勧めできません。 max_execution_time についてもう 1 つ注意すべき点があります。これは絶対時間ではなく、プロセスの CPU 時間を表します。したがって、大量の I/O とわずかな計算を行うプログラムは、max_execution_time よりもはるかに長く実行される可能性があります。これが、max_input_time が max_execution_time より大きくなる可能性がある理由です。
PHP 実行可能ファイルで使用できるログ レコードの数は構成可能です。運用環境では、最も重要なログを除くすべてのログを無効にすると、ディスクへの書き込みを減らすことができます。問題のトラブルシューティングにログを使用する必要がある場合は、オンデマンドでのログ記録を有効にすることができます。 error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR を使用すると、スクリプトから多くの無駄なコンテンツを削除しながら、問題を検出できる十分なログが有効になります。

http://www.bkjia.com/PHPjc/478737.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/478737.html技術記事 Apache は高度に構成可能なソフトウェアです。機能が豊富ですが、それぞれの機能が高価です。 Apache のチューニングは、ある程度、適切な方法でリソースを割り当てています...