Apacheの最大パフォーマンスのための設定

ApacheはオープンソースのHTTPサーバー実装です。インターネット上で最も人気のあるウェブサーバーです。Netcraftによって実施された2005年12月のウェブサーバー調査[1]によると、インターネット上のウェブサイトの約70%がApacheを使用しています。

1. Apacheサーバーのパフォーマンス

Apacheサーバーのパフォーマンスは、RAMやより高速なCPUなどの追加ハードウェアリソースを追加することで改善できます。しかし、ほとんどの場合、サーバーのカスタム設定によって同じ結果を得ることができます。この記事では、特にLinuxシステム上で、既存のハードウェアリソースを使用してApacheから最大パフォーマンスを引き出す方法を見ていきます。もちろん、サーバーが頻繁にスワップしないように、特に十分なRAMがあることが前提とされています。最初の2つのセクションでは、さまざまなコンパイル時および実行時の設定オプションについて見ていきます。実行時のセクションでは、Apacheがprefork MPMでコンパイルされていることを前提としています。次に、HTTP圧縮とキャッシングについて説明します。最後に、静的コンテンツと動的コンテンツを提供するために別々のサーバーを使用することについて議論します。ApacheとLinuxのコンパイルおよび設定に関する基本的な知識があることが前提です。

2 コンパイル時の設定オプション

2.1 必要なモジュールのみをロードする:

Apache HTTPサーバーはモジュール式のプログラムであり、管理者は一連のモジュールを選択することでサーバーに含める機能を選択できます[2]。モジュールは、httpdバイナリに静的にコンパイルされるか、動的共有オブジェクト（DSO）としてコンパイルされることがあります。DSOモジュールは、サーバーが構築されるときにコンパイルされるか、後でapxsユーティリティを使用してコンパイルして追加できます。モジュールmod_soは、DSOサポートを有効にするためにApacheコアに静的にコンパイルされる必要があります。

必要なモジュールのみを使用してApacheを実行します。これによりメモリフットプリントが削減され、サーバーのパフォーマンスが向上します。モジュールを静的にコンパイルすることで、動的にロードされたモジュールをサポートするために使用されるRAMを節約できますが、モジュールを追加または削除するたびにApacheを再コンパイルする必要があります。これがDSOメカニズムが便利な理由です。一度mod_soモジュールが静的にコンパイルされれば、httpd.confファイルのLoadModuleコマンドを使用して、他のモジュールを追加または削除できます。もちろん、サーバーが構築されたときにコンパイルされていなかった場合は、apxsを使用してモジュールをコンパイルする必要があります。

2.2 適切なMPMを選択する:

Apacheサーバーには、マシン上のネットワークポートにバインドし、リクエストを受け入れ、リクエストを処理するために子プロセスをディスパッチする責任を持つ複数のマルチプロセッシングモジュール（MPM）が付属しています[3]。同時にサーバーにロードできるMPMは1つだけです。

MPMの選択は、OSがスレッドをサポートしているかどうか、利用可能なメモリの量、スケーラビリティと安定性のバランス、非スレッドセーフなサードパーティモジュールが使用されているかどうかなど、さまざまな要因に依存します。Linuxシステムは、workerのようなスレッド化されたMPMまたはpreforkのような非スレッド化されたMPMを使用することができます:

Worker MPMは複数の子プロセスを使用します。各子プロセス内でマルチスレッドであり、各スレッドは単一の接続を処理します。Workerは高速で非常にスケーラブルで、メモリフットプリントは比較的低いです。複数のプロセッサに適しています。一方、workerは故障したモジュールに対して耐性が低く、故障したスレッドは子プロセス内のすべてのスレッドに影響を与える可能性があります。

Prefork MPMは複数の子プロセスを使用し、各子プロセスは1回の接続を処理します。PreforkはシングルまたはダブルCPUシステムに適しており、速度はworkerと同等で、故障したモジュールやクラッシュした子プロセスに対して非常に耐性があります。しかし、メモリ使用量は高く、トラフィックが増えるとメモリ使用量も増加します。

3 実行時の設定オプション

3.1 DNSルックアップ:

HostnameLookupsディレクティブはDNSルックアップを有効にし、IPアドレスの代わりにホスト名をログに記録できるようにします。これは、リクエストが完了する前にDNSルックアップを完了する必要があるため、すべてのリクエストに遅延を追加します。HostnameLookupsは、Apache 1.3以降ではデフォルトでオフになっています。これをオフのままにし、logresolveのようなポストプロセッシングプログラムを使用してApacheのアクセスログファイル内のIPアドレスを解決します。logresolveはApacheに付属しています。

Allow fromまたはDeny fromディレクティブを使用する場合は、ドメイン名やホスト名の代わりにIPアドレスを使用してください。そうしないと、ドメイン名やホスト名が偽装されていないことを確認するために二重DNSルックアップが実行されます。

3.2 AllowOverride:

AllowOverrideが’None’に設定されていない場合、Apacheは訪問する各ディレクトリで.htaccessファイル（AccessFileNameディレクティブで指定された）を開こうとします。例えば:

DocumentRoot /var/www/html  
   
 AllowOverride all

URI /index.htmlに対するリクエストが行われると、Apacheは/.htaccess、/var/.htaccess、/var/www/.htaccess、および/var/www/html/.htaccessを開こうとします。これらの追加のファイルシステムルックアップは遅延を追加します。特定のディレクトリに対して.htaccessが必要な場合は、そのディレクトリのみに対して有効にしてください。

3.3 FollowSymLinksおよびSymLinksIfOwnerMatch:

FollowSymLinksオプションが設定されている場合、サーバーはこのディレクトリ内のシンボリックリンクを追跡します。SymLinksIfOwnerMatchが設定されている場合、サーバーはターゲットファイルまたはディレクトリがリンクと同じユーザーによって所有されている場合にのみシンボリックリンクを追跡します。

SymLinksIfOwnerMatchが設定されている場合、Apacheはリンクとターゲットファイルの所有権が一致するかどうかを確認するために追加のシステムコールを発行する必要があります。FollowSymLinksが設定されていない場合にも追加のシステムコールが必要です。例えば:

 DocumentRoot /vaw/www/html   
    
 Options SymLinksIfOwnerMatch

URI /index.htmlに対するリクエストが行われると、Apacheは/var、/var/www、/var/www/html、および/var/www/html/index.htmlでlstat()を実行します。これらの追加のシステムコールは遅延を追加します。lstatの結果はキャッシュされないため、すべてのリクエストで発生します。

最大のパフォーマンスを得るためには、どこでもFollowSymLinksを設定し、SymLinksIfOwnerMatchは決して設定しないでください。あるいは、特定のディレクトリに対してSymLinksIfOwnerMatchが必要な場合は、そのディレクトリのみに設定してください。

3.4 コンテンツネゴシエーション:

迅速な応答のためにコンテンツネゴシエーションを避けてください。サイトにコンテンツネゴシエーションが必要な場合は、Options MultiViewsディレクティブの代わりにtype-mapファイルを使用してください。MultiViewsを使用すると、Apacheはファイルのためにディレクトリをスキャンする必要があり、これが遅延を追加します。

3.5 MaxClients:

MaxClientsは、サーバーがサポートできる最大同時リクエストの制限を設定します。この数以上の子プロセスは生成されません。新しい接続がキューに入れられるほど低く設定すべきではなく、最終的にタイムアウトし、サーバーリソースが未使用のまま残ることになります。これを高く設定しすぎると、サーバーがスワッピングを開始し、応答時間が著しく低下します。MaxClientsの適切な値は次のように計算できます: MaxClients = ウェブサーバーに専用の総RAM / 最大子プロセスサイズ —- [4] 静的ファイルを提供するための子プロセスサイズは約2-3Mです。PHPなどの動的コンテンツの場合、約15Mになることがあります。ps -ylC httpd --sort:rssのRSS列は、Apacheプロセスによるスワップされていない物理メモリ使用量をキロバイト単位で示します。

MaxClientsよりも同時ユーザーが多い場合、リクエストはListenBacklogディレクティブに基づいてキューに入れられます。ServerLimitを増やしてMaxClientsを256以上に設定します。

3.6 MinSpareServers、MaxSpareServers、およびStartServers:

MaxSpareServersとMinSpareServersは、リクエストを待っている間に保持する子プロセスの数を決定します。MinSpareServersが低すぎると、一度に多数のリクエストが来た場合、Apacheはリクエストを処理するために追加の子プロセスを生成しなければなりません。子プロセスを作成することは比較的高価です。サーバーが子プロセスを作成するのに忙しい場合、クライアントリクエストを即座に処理できません。MaxSpareServersは高く設定しすぎないようにしてください。子プロセスはリソースを消費するため、リソースの問題を引き起こす可能性があります。

MinSpareServersとMaxSpareServersを調整して、Apacheが1秒あたり4つ以上の子プロセスを頻繁に生成する必要がないようにします（Apacheは1秒あたり最大32の子プロセスを生成できます）。1秒あたり4つ以上の子プロセスが生成されると、ErrorLogにメッセージが記録されます。

StartServersディレクティブは、起動時に作成される子サーバープロセスの数を設定します。ApacheはMinSpareServersの設定に達するまで子プロセスを作成し続けます。サーバーが頻繁に再起動されない場合、パフォーマンスにはあまり影響しません。リクエストが多く、Apacheが頻繁に再起動される場合は、これを比較的高い値に設定します。

3.7 MaxRequestsPerChild:

MaxRequestsPerChildディレクティブは、個々の子サーバープロセスが処理するリクエストの数の制限を設定します。MaxRequestsPerChildリクエストの後、子プロセスは終了します。デフォルトでは0に設定されており、これは子プロセスが決して期限切れにならないことを意味します。数千の値に設定するのが適切です。これにより、特定のリクエスト数を処理した後にプロセスが終了するため、メモリリークを防ぐのに役立ちます。新しいプロセスを作成するにはオーバーヘッドがあるため、これを低く設定しすぎないでください。

3.8 KeepAliveおよびKeepAliveTimeout:

KeepAliveディレクティブは、同じTCP接続を介して複数のリクエストを送信できるようにします。これは、画像が多く含まれるHTMLページを提供する際に特に便利です。KeepAliveがオフに設定されている場合、各画像ごとに別々のTCP接続を作成する必要があります。TCP接続の確立によるオーバーヘッドは、KeepAliveをオンにすることで排除できます。

KeepAliveTimeoutは、次のリクエストを待つ時間を決定します。これを低い値、たとえば2〜5秒の間に設定します。これが高すぎると、子プロセスはクライアントを待っている間に占有され、新しいクライアントを処理するために使用できなくなります。

4 HTTP圧縮とキャッシング

HTTP圧縮はHTTP/1.1で完全に指定されています。サーバーは、クライアントに送信される前にレスポンスペイロードにgzipまたはdeflateエンコーディング方式を使用します。クライアントはその後、ペイロードを解凍します。すべての主要なブラウザがこれをサポートしているため、クライアント側で追加のソフトウェアをインストールする必要はありません。圧縮を使用すると、帯域幅を節約し、応答時間を改善します。研究によると、平均圧縮率は75.2%です[5]。HTTP圧縮は、mod_deflateモジュールを使用してApacheで有効にできます。ペイロードは、ブラウザが圧縮を要求した場合にのみ圧縮され、それ以外の場合は非圧縮のコンテンツが提供されます。圧縮に対応したブラウザは、HTTPリクエストヘッダー「Accept-Encoding: gzip,deflate」を介してサーバーに圧縮されたコンテンツを好むことを通知します。サーバーは圧縮されたペイロードで応答し、レスポンスヘッダーは次のように設定されます:

Content-Encoding:  
gzip

以下の例では、telnetを使用してリクエストとレスポンスのヘッダーを表示します:

bash-3.00$ telnet www.webperformance.org 80  
 Trying 24.60.234.27...  
 Connected to www.webperformance.org (24.60.234.27).  
 Escape character is '^]'.  
 HEAD / HTTP/1.1  
 Host: www.webperformance.org  
 Accept-Encoding: gzip,deflate  
   
 HTTP/1.1 200 OK  
 Date: Sat, 31 Dec 2005 02:29:22 GMT  
 Server: Apache/2.0  
 X-Powered-By: PHP/5.1.1  
 Cache-Control: max-age=0  
 Expires: Sat, 31 Dec 2005 02:29:22 GMT  
 Vary: Accept-Encoding  
 Content-Encoding: gzip  
 Content-Length: 20  
 Content-Type: text/html; charset=ISO-8859-1

キャッシングでは、データのコピーがクライアントまたはプロキシサーバーに保存されるため、サーバーから頻繁に取得する必要がなくなります。これにより、帯域幅が節約され、サーバーへの負荷が減少し、遅延が減少します。キャッシュ制御はHTTPヘッダーを介して行われます。Apacheでは、これをmod_expiresおよびmod_headersモジュールを使用して実現できます。また、サーバー側キャッシングもあり、頻繁にアクセスされるコンテンツがメモリに保存され、迅速に提供されます。サーバー側キャッシングにはmod_cacheモジュールを使用できます。これはApacheバージョン2.2で安定しています。

5 静的コンテンツと動的コンテンツのための別々のサーバー

動的コンテンツを提供するApacheプロセスは、約3Mから20MのRAMを消費します。それは提供しているコンテンツに合わせて成長し、プロセスが終了するまで減少することはありません。たとえば、Apacheプロセスが動的コンテンツを提供するために20Mに成長したとします。リクエストが完了すると、他のリクエストを処理するために自由になります。画像のリクエストが来た場合、この20Mのプロセスが静的コンテンツを提供しており、1Mのプロセスでも提供できる可能性があります。メモリが非効率的に使用されています。

最小限のモジュールを静的にコンパイルした小さなApacheをフロントエンドサーバーとして使用して静的コンテンツを提供します。動的コンテンツのリクエストは、すべての必要なモジュールをコンパイルした重いApacheに転送されます。軽量のフロントエンドサーバーを使用する利点は、静的コンテンツが迅速に提供され、メモリ使用量が少なく、動的コンテンツのみが重いサーバーに渡されることです。

リクエストの転送は、mod_proxyおよびrewrite_moduleモジュールを使用して実現できます。たとえば、ポート80でリッスンしている軽量のApacheサーバーと、ポート8088でリッスンしている重いApacheがあるとします。次の設定を軽量のApacheで使用して、画像のリクエストを除くすべてのリクエストを重いサーバーに転送できます。

ProxyPassReverse / http://%{HTTP_HOST}:8088/  
 RewriteEngine on                                             ---- [9]  
 RewriteCond   %{REQUEST_URI} !.*\.(gif|png|jpg)$  
 RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]

画像を除くすべてのリクエストはバックエンドサーバーにプロキシされます。レスポンスはフロントエンドサーバーによって受信され、その後クライアントに供給されます。クライアントにとっては、すべてのレスポンスが単一のサーバーから来ているように見えます。

6 結論

Apacheを最大パフォーマンスのために設定することは難しく、厳密なルールはありません。ウェブサーバーの要件を理解し、さまざまな利用可能なオプションを試してみてください。abやhttperfのようなツールを使用してウェブサーバーのパフォーマンスを測定します。tuxやthttpdのような軽量サーバーもフロントエンドサーバーとして使用できます。データベースサーバーを使用する場合は、ボトルネックを作成しないように最適化されていることを確認してください。MySQLの場合、mtopを使用して遅いクエリを監視できます。PHPスクリプトのパフォーマンスは、Turck MMCacheのようなPHPキャッシング製品を使用することで改善できます。これにより、コンパイルされた状態でPHPスクリプトをキャッシュすることで、コンパイルによるオーバーヘッドが排除されます。