Apache サーバー構成ガイド (2)

apache|サーバー|戦略

著者: Wang Bo

MinSpareServers 5MaxSpareServers 10

子プロセスを使用して HTTP リクエストを処理する Web サーバーでは、顧客のリクエストを処理するために最初に子プロセスを生成する必要があるため、応答時間はわずかに遅れます。ただし、Apache サーバーは、この問題を解決するために、システム内に常駐する複数のアイドル サブプロセスを事前に生成する特別なテクノロジーを使用しており、リクエストが発生すると、これらのアイドル サブプロセスがすぐに処理に使用されます。子プロセスの生成による遅延がないこと。動作中にクライアント要求の数が増加すると、開始される子プロセスの数も増加します。ただし、これらのサーバー コピーは HTTP 要求の処理後すぐに終了せず、次の要求を待機するコンピューター内に残ります。ただし、予備のサブプロセスのコピーの数は、減らさずに増やすことはできません。処理タスクを持たない予備のサブプロセスが多すぎると、サーバーの処理能力を占有してしまうため、適切な値を維持するには、予備のサブプロセスの数も制限する必要があります。顧客のリクエストにタイムリーに対応できるようにすることで、無駄なプロセスを削減することもできます。

したがって、パラメータ MinSpareServers を使用してアイドル状態の子プロセスの最小数を設定し、

パラメータ MaxSpareServers を使用してアイドル状態の子プロセスの最大数を制限すると、冗長なサーバー プロセスのコピーが終了します。サーバーのパフォーマンスが高く、頻繁にアクセスされる場合は、これら 2 つのパラメーターの設定を増やす必要があります。高負荷の専門的な Web サイトの場合、これら 2 つの値

はほぼ同じで、システムがサポートするサーバー レプリカの最大数と同等である必要があり、不必要なレプリカ

の終了も削減されます。


StartServers 5

StartServers パラメーターは、httpd の開始時に開始されるサブプロセスのコピーの数を設定するために使用されます。このパラメーターは、上記で定義された MinSpareServers パラメーターと MaxSpareServers パラメーターに関連しており、どちらもアイドル状態のサブプロセスを開始するために使用されます。サーバーの応答速度を向上させます。このパラメータは、最初の 2 つの値の間の値に設定する必要があります。MinSpareServers より小さくても、MaxS pareServers より大きくても意味がありません。


MaxClients 150

一方で、サーバーの容量には結局のところ限界があり、同時に無限数の接続リクエストを処理することは不可能であるため、パラメータMaxclientsを使用して最大数を指定します。サーバーがサポートする同時アクセス クライアントの数に応じて、この値の設定が大きすぎると、システムがビジー状態のときに多数の顧客にサービスを提供するために、非常に多くのプロセスを切り替える必要が生じ、各顧客への応答が遅くなり、全体的なパフォーマンスが低下します。効率。 。この値を小さい値に設定すると、システムがビジー状態のときに一部のクライアント接続要求が拒否されます。サーバーのパフォーマンスが高い場合は、この値の設定を適切に増やすことができます。プロフェッショナルな Web サイトでは、サーバーの効率を向上させる戦略を使用する必要があるため、このパラメータがハードウェア自体の制限を超えることはできません。アクセス拒否が頻繁に発生する場合は、サーバー ハードウェアをアップグレードする必要があることを意味します。顧客のブラウザの応答速度をあまり気にしない、または接続を拒否するより応答速度が遅いほうが良いと考えている非プロフェッショナルな Web サイトの場合は、ハードウェア条件をわずかに超えてこのパラメータを設定できます。

このパラメータは MinSpareServers と MaxSpareServers の設定を制限しており、このパラメータの設定より大きく

すべきではありません。


MaxRequestsPerChild 30

サブプロセスを使用してサービスを提供する Web サービス 一般的な方法は、サブプロセスが接続を提供することです。これによって生じる問題は、各接続でサブプロセスの生成と終了というシステム操作が必要になることです。 -プロセス、作成 この追加の処理は、コンピューターの処理能力の多くを消費します。したがって、子プロセスが複数の接続リクエストを処理できるようにするのが最善の方法であり、Apache は接続の完了後に子プロセスを終了せずにこの方法を採用します。ただし、次のサービス要求を待機するシステム内に留まるため、パフォーマンスが大幅に向上します。

ただし、子プロセスは処理中にメモリの申請と解放を継続的に行う必要があるため、回数が多すぎると

メモリのゴミが発生し、システムの安定性やシステムリソースの有効利用に影響を及ぼします。したがって、コピーが一定数のリクエストを処理した後、サブプロセスのコピーを終了し、元の

httpd プロセスからクリーンなコピーを再コピーすることができ、これによりシステムの安定性が向上します。このように、各

子プロセスによって処理されるサービス リクエストの数は、MaxRe QuestPerChild によって定義されます。 デフォルトの設定値は 30 です。

この値は、安定性の高い Linux システムにとっては控えめすぎます。0 に設定すると、各コピーの無制限のサービス処理がサポートされます。


#3000を聴く

HTTPリクエスト。 FreeBSD システムは同時に複数の IP アドレスを持つことができるため、サーバーが特定の BindAddress の IP アドレスに対する HTTP リクエストのみをリッスンするように指定することもできます。これが構成されていない場合、サーバーはすべての IP のリクエストに応答します。

サーバーが 1 つの IP アドレスのリクエストにのみ応答するように BindAddress パラメーターが使用されている場合でも、拡張 Listen パラメーターを使用して HTTP デーモンが他の IP アドレスのリクエストに応答するようにすることができます。このときの Listen パラメータの使用方法は、上記の 2 番目の例と同じです。このより複雑な使用法は、主に仮想ホストをセットアップするために使用されます。その後、VirtualHost パラメータを使用して、異なる IP を持つ仮想ホストを定義できます。ただし、この使用法は、以前の HTTP 1.0 標準で仮想ホストを設定する方法であり、実際にはあまり役に立ちません。 HTTP 1.1 では、単一の IP アドレスと複数のドメイン名を持つ仮想ホストのサポートが追加され、仮想ホストの設定がより意味のあるものになりました。


LoadModule mime_magic_module libexec/apache/mod_mime_magic.so

LoadModule info_module libexec/apache/mod_info.so

LoadModule speling_module libexec/apache/mod_speling.so

LoadModule proxy_モジュール libexec/apache/libproxy.so

LoadModule rewrite_module libexec /apache/mod_rewrite.so

LoadModule anon_auth_module libexec/apache/mod_auth_anon.so

LoadModule db_auth_module libexec/apache/mod_auth_db.so

LoadModule Digest_module libexec/apache/mod_digest.so

ロードモジュール cern_meta_module libexec/apache/mod_cern_meta。

LoadModuleexpires_module libexec/apache/mod_expires.so

LoadModule headers_module libexec/apache/mod_headers.so

LoadModule usertrack_module libexec/apache/mod_usertrack.so

LoadModule unique_id_module libexec/ap ache /mod_unique_id.so


ClearModuleList

AddModule mod_env.c

AddModule mod_log_config.c

AddModule mod_mime_magic.c

AddModule mod_mime.c

AddModule mod_negotiation.c

AddModule mod_status.c

AddModule mod_info.c

AddModule mod_include.c

AddModule mod_autoindex .c

AddModule mod_dir.c

AddModule mod_cgi.c

AddModule mod_asis.c

AddModule mod_imap.c

AddModule mod_actions.c

AddModule mod_speling.

AddModule mod_userdir.c

AddModule mod_proxy. c

AddModule mod_alias.c

AddModule mod_rewrite.c

AddModule mod_access.c

AddModule mod_auth.c

AddModule mod_auth_anon.c

AddModule mod_auth_db .c

モジュールの追加 mod_digest.c

モジュールの追加 mod_cern_meta.c

AddModule mod_expires.c

AddModule mod_headers.c

AddModule mod_usertrack.c

AddModule mod_so.c

AddModule mod_setenvif.c


Apache サーバーの重要な特徴は、モジュール構造です。これは、コンパイル中に新しいモジュールを通じて新しい機能を追加できることを意味するだけでなく、不要なモジュールをロードすることなく、そのモジュールを http サービス プログラムに動的にロードできることも意味します。 Apache の動的にロードされるモジュールを使用するには、Load Module パラメータと AddModule パラメータを設定するだけで済みます。ただし、DSO 機能を使いこなすのはまだ簡単ではありません。ここで設定を変更すると、サーバーが正常に起動できなくなる可能性があります。したがって、サーバーが提供する機能を増減したくない場合は、ここでの設定を変更しないでください。


上記のリストは、Linux のデフォルトの Apache サーバーでサポートされているモジュールを示しています。実際には、多くの

複数のモジュールは必要なく、不要なモジュールはメモリにロードされません。モジュールは、pache サーバーに静的に接続することも、動的にロードすることもできます。これは、Apache のデフォルトのアプローチではなく、すべての Apache 機能を動的にロード可能なモジュールにコンパイルするためのアプローチであり、パフォーマンスをほとんど犠牲にしません。


したがって、動的にロードする機能は依然としてパフォーマンスにわずかな影響を与えるため、Apache を再コンパイルして、必要な関数を Apache サーバーにコンパイルすることで、システムがクリーンになり、効率がわずかに向上します。通常、この目的のためだけに Apache を再コンパイルする必要はありません。他の機能を追加するために Apache を再コンパイルする必要がある場合は、他のモジュールを追加して、すべてのモジュールを Apache サーバーに静的に接続することをお勧めします。一部のユーザーは動的にロードされるモジュールを好むため、すべてのユーザーに動的にロードされるモジュールを使用することもできます。


これらのモジュールは、/usr/local/apache/libexec/ ディレクトリに配置されており、各モジュールは Apache サーバーの機能に対応しています。各モジュールの機能の詳細な説明にはかなりのスペースが必要です。各モジュールの具体的な機能と使用法については、後で該当する場所で説明します。


#ExtendedStatus On

Apache サーバーは、特別な HTTP リクエストを通じて独自の実行ステータスを報告できます。この

ExtendedStatus パラメータをオンにすると、サーバーはより包括的な実行ステータス情報を報告できるようになります。