検索

ホームページ >バックエンド開発 >PHPチュートリアル >Apache vs Nginxパフォーマンス：最適化技術

Apache vs Nginxパフォーマンス：最適化技術

Joseph Gordon-Levitt
Joseph Gordon-Levittオリジナル
2025-02-08 10:07:08887ブラウズ

Apache vs Nginx Performance: Optimization Techniques

キーポイント

  • ApacheとNginxはどちらも強力なWebサーバーですが、パフォーマンス機能はプロセス駆動型モデルを採用しています。
  • Apacheの主要な最適化には、接続をより効率的に処理するためのプレフォルト、ワーカー、イベントなどのマルチプロセスモジュール（MPM）のチューニング、可能な限りファイルシステムのパフォーマンスを削減するために.htaccessを無効にすることが含まれます。
  • NGINXの場合、主要なパフォーマンスの強化には、正しいワーカープロセスと接続カウントの設定、KeepALIVE接続を活用してTCPオーバーヘッドを削減し、コンテンツをより速く配信するためのキャッシュポリシーの実装が含まれます。
  • 2つのサーバーは、サーバーハードウェア構成（RAMの追加やSSDの使用など）を調整して、Webサービスプロセスのニーズに適応することにより、さらに最適化できます。
  • 逆プロキシセットアップでApacheとnginxを使用すると、2つのサーバーを利用できます。Nginxは静的コンテンツとロードバランシングを処理し、Apacheは動的コンテンツを処理します。
    • HTOP、新しい遺物、特定の負荷テストソフトウェアを使用した継続的な監視とテストは、ボトルネックを効果的に特定し、サーバーのパフォーマンスを最適化するために重要です。
数年前、Apache FoundationのWebサーバー（「Apache」と呼ばれる）は非常に一般的であったため、「Webサーバー」という言葉と同義語になりました。 Linuxシステム上のデーモンは

httpd（http Processのみを意味します）という名前で、メインのLinux分布にプリインストールされています。

1995年に出版され、ウィキペディアは「ワールドワイドウェブの初期の開発で重要な役割を果たした」と言っていると引用しました。 W3Techsによると、それは依然として最も一般的に使用されるWebサーバーソフトウェアです。ただし、過去10年間でいくつかの傾向を示し、他のソリューションとの比較を示すレポートに基づいて、その市場シェアは減少しています。 NetcraftとBuiltはわずかに異なるレポートを提供しますが、Apacheの市場シェアは下降傾向にあることに同意しますが、Nginxの市場シェアは増加しています。

nginx（発音

エンジンx）は、2004年にIgor Sysoevによってリリースされ、Apacheを超えることを明確に目標としています。 NginxのWebサイトには、これら2つのテクノロジーを比較する価値のある記事があります。最初は、主に静的ファイルを提供するために、主にApacheの補完として使用されていましたが、さまざまなWebサーバータスクを処理するために進化し続けるにつれて着実に成長しています。

逆プロキシ、ロードバランサー、およびHTTPキャッシュとして一般的に使用されます。 CDNおよびビデオストリーミングプロバイダーは、それを使用して、パフォーマンスに不可欠なコンテンツ配信システムを構築します。

Apacheは長い間存在しており、多くのモジュールを選択できます。 Apacheサーバーの管理は、ユーザーフレンドリーであることがよく知られています。動的モジュールの読み込みにより、メインサーバーバイナリを再コンパイルせずに、さまざまなモジュールをコンパイルしてApacheスタックに追加できます。通常、モジュールはLinux Distributionリポジトリにあり、インストール後、システムパッケージマネージャーを介してA2ENMODのようなコマンドを使用して優雅にスタックに追加できます。 Nginxはまだこの柔軟性を見ていません。 HTTP/2をサポートするためにNGINXをセットアップするガイドを見ると、モジュールはNGINXがビルドする必要があるもの - ビルド時に構成されています。

Apache市場の優位性に貢献するもう1つの機能は、.htaccessファイルです。これはApacheのキラーであり、ディレクトリレベルでのサーバー構成を制御できるため、共有ホスティング環境に優先ソリューションになっています。 Apacheが提供するサーバー上の各ディレクトリは、独自の.htaccessファイルを持つことができます。

nginxには、同等のソリューションがないだけでなく、パフォーマンスの影響によりこの使用を防ぎます。

Apache vs Nginx Performance: Optimization Techniques

1995年から2005年までのサーバーメーカー市場シェア。 Netcraftのデータ

LiteSpeedまたはLSWSは、パフォーマンスを犠牲にすることなくApacheに匹敵する柔軟性のレベルがそのレベルのサーバー競争相手です。 Apacheスタイルの.htaccess、mod_security、およびmod_rewriteをサポートしており、設定を共有するために検討する価値があります。 Apacheの直接代替品として計画されており、CpanelとPleskで使用できます。 2015年以来、HTTP/2をサポートしています。

Litespeedには、OpenLiteSpeed、LSWS Standard、およびLSWS Enterpriseの3つのライセンスレベルがあります。 StandardとEnterpriseには、サーバー自体に組み込まれており、.htaccessファイル（各ディレクトリ）の書き換えルールを使用して制御できます。また、いくつかのDDOS緩和「バッテリー」が組み込まれています。これは、イベント主導のアーキテクチャと組み合わさって、パフォーマンスに焦点を当てたホスティングプロバイダーをターゲットにしている強力な競争相手になりますが、小規模なサーバーやWebサイトでもセットアップする価値があります。

ハードウェアの予防策

システムを最適化する場合、ハードウェア設定への注意を強調することはできません。セットアップにどのソリューションを選択しても、十分なRAMを持つことが重要です。 WebサーバーのプロセスまたはPHPのような通訳者に十分なRAMがない場合、それらは交換を開始し、実際に交換することは、ハードディスクを使用してRAMメモリを補充することを意味します。これの効果は、このメモリにアクセスするたびにレイテンシを増やすことです。これは、2番目のポイント - ハードディスクスペースを思い出させます。高速SSDストレージを使用することは、Webサイト速度のもう1つの重要な要素です。また、CPUの可用性とサーバーデータセンターとターゲットオーディエンスの間の物理的距離に注意する必要があります。

パフォーマンスチューニングのハードウェアの側面をより深く理解するために、Dropboxには良い記事があります。

監視

現在のサーバースタックのパフォーマンスを詳細に監視する実用的な方法はHTOPです。これはLinux、Unix、およびMacOSに適しており、プロセスのカラフルな概要を提供します。

Apache vs Nginx Performance: Optimization Techniques

その他の監視ツールには、New Relic（フルセットのツールを備えた高度なソリューション）とNetData（優れたスケーラビリティ、細粒メトリック、小型VPSシステムおよびサーバーネットワーク監視用のカスタマイズ可能なWebダッシュボードを提供するオープンソースソリューション）が含まれます。電子メール、Slack、Pushbullet、Telegram、Twilioなどを介して、アプリケーションまたはシステムプロセスのアラートを送信できます。

Apache vs Nginx Performance: Optimization Techniques

Monitは、システムを監視するもう1つのヘッドレスオープンソースツールであり、特定の条件が満たされたときに警告するように構成することができます。

テストシステム

AB（Apache Benchmark）は、Apache Foundationの単純な負荷テストツールであり、Siegeは別の負荷テストプログラムです。この記事では、それらをセットアップする方法について説明します。ABに関するより高度なヒントをいくつか紹介します。包囲のより深い理解がここにあります。

Webインターフェイスを好む場合、LocustはWebサイトのパフォーマンスのテストに非常に便利なPythonベースのツールです。

Apache vs Nginx Performance: Optimization Techniques

Locustをインストールした後、発売するディレクトリにLocustFileを作成する必要があります。 

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>
その後、コマンドラインから起動するだけです：

<code>locust --host=https://my-website.com
</code>
これらの負荷テストツールに関する警告：DDOS攻撃の効果があるため、テストを自分のWebサイトに制限することをお勧めします。

Apache

を調整します

ApacheのMPMモジュール

Apacheは1995年以前のインターネットの初期にさかのぼります。サーバーを実行するための許容可能な方法は、各着信TCP接続で新しいプロセスを生成し、それに返信することでした。より多くの接続が入っている場合、より多くのワーカープロセスが作成され、それらを処理します。新しいプロセスを生成するコストは非常に高く、Apache開発者は、特定の数のプロセスを事前にメイクするPrefork

モードを設計しました。各プロセスに埋め込まれた動的言語通訳（MOD_PHPなど）は依然としてコストがかかり、Apacheのデフォルト設定によりサーバーがクラッシュします。各プロセスは、1つの着信接続のみを処理できます。 このモデルは、ApacheのMPM（マルチプロセスモジュール）システムでMPM_PREFORK_MODULE

と呼ばれます。 Apacheのウェブサイトによると、このモードは自己調整できるため、ほとんど構成を必要としません。最も重要なことは、MaxRequestworkersの指令は、あなたが期待すると同じくらい多くの同時リクエストを処理するのに十分な大きさですが、確実にするのに十分なほど小さいすべてのプロセスには、十分な物理的RAM

があります。

着信トラフィックを処理するために生成された多数のアパッチプロセスを示す小さなイナゴロードテスト。

このパターンは、Apacheの悪名高い評判の主な理由かもしれないと付け加えることができます。リソースは非効率的です。

Apacheのバージョン2.0は、

プレフォルクモードの問題を解決しようとする他の2つのMPMをもたらします。それらは、ワーカーモジュールまたは mpm_worker_moduleおよびイベントモジュールです。

ワーカーモジュールはプロセスベースではありません。 ApacheのWebサイトを引用：

単一制御プロセス（親プロセス）は、子プロセスの開始を担当します。各子のプロセスは、スレッドスパーチャイルドディレクティブで指定された番号に基づいて固定数のサーバースレッドを作成し、接続をリッスンし、接続が到着したときに処理するためにサーバースレッドに渡すリスニングスレッドを作成します。

このモードはより多くのリソースを節約します。

Apacheのバージョン2.4は、3番目のMPM -Eventモジュールをもたらします。これは、Worker MPMに基づいており、HTTPリクエストが完了した後に眠いキープアライブ接続を管理する別のリスニングスレッドを追加します。これは、メモリフットプリントが小さい非ブロッキング非同期モードです。バージョン2.4の改善の詳細については、こちらをご覧ください。

仮想サーバーに約1200の投稿を備えたテストWooCommerceインストーラーをロードし、デフォルトのプレフィックモードとMOD_PHPでApache 2.4でテストしました。

最初に、https://tools.pingdom.comでlibapache2-mod-php7とmmpm_prefork_moduleを使用してテストしました。

Apache vs Nginx Performance: Optimization Techniques 次に、イベントMPMモジュールをテストしました。

/etc/apt/sources.list：

に多元宇宙を追加する必要があります

をインストールします 

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

php-fpmはapacheとは別のサービスであるため、再起動する必要があります。 

<code>locust --host=https://my-website.com
</code>
その後、プレフィックモジュールを無効にし、イベントモードとproxy_fcgiを有効にしました：

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>
このスニペットをApache仮想ホストに追加します：

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>
このポートは、/etc/php/7.0/fpm/pool.d/www.confのPHP-fpm構成と一致する必要があります。 PHP-FPM設定の詳細については、こちらをご覧ください。

次に、MPM_EVENT構成を/etc/apache2/mods-abailable/mpm_event.confで調整しました。このテストのために持っていたMini VPSリソースが制限されていることを思い出してください。 Apache Webサイトの各ディレクティブの詳細、およびイベントMPMのヒントはこちら。スタートアップサーバーは、どんなに忙しくても、一定量のメモリを消費することを忘れないでください。 MaxRequestworkersディレクティブは、許可されている同時リクエストの数を設定します。MaxConnectionSperChildを非ゼロ値に設定することは、可能なメモリリークを防ぐため重要です。 
<code>sudo service start php7.0-fpm
</code>
<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Pingdomでのテストは、ページの読み込み時間が半分以上短縮されたことを示しています。

Apache vs Nginx Performance: Optimization Techniques Apacheを調整するためのその他のヒント：

disable.htaccess：htaccessを使用すると、再起動せずにサーバールートディレクトリの各ディレクトリの特定の構成を設定できます。したがって、各リクエストで.htaccessファイルを見つけるためにすべてのディレクトリを繰り返して、パフォーマンスの損失になります。

Apacheのドキュメントから引用：

：

一般的に言えば、.htaccessファイルは、プライマリサーバー構成ファイルにアクセスする許可がない場合にのみ使用する必要があります。 …一般的に言えば、.htaccessファイルはできるだけ回避する必要があります。メインサーバー構成ファイルの
セクションを使用するのと同じくらい効率的に.htaccessファイルに入れたいと思う構成を実行できます。

ソリューションは、/etc/apache2/apache2.confで無効にすることです

特定のディレクトリに必要な場合は、仮想ホストファイルの

<code>locust --host=https://my-website.com
</code>

セクションで有効にすることができます。 その他のヒントには以下が含まれます mod_expiresを使用してブラウザキャッシュを制御します - 有効期限がヘッダーを設定します。 

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>
hostnameLookupsをオフにしておく - hostnameLookupsオフは、Apache 1.3以来デフォルトでしたが、パフォーマンスの損失につながる可能性があるため、オフのままであることを確認してください。

apache2buddyは、システムを調整するためのトリックを実行できる簡単なスクリプトです フォーキングプロセスは、イベントループに比べて非常に高価です。イベントベースのHTTPサーバーが最終的に勝ちます。

Apache vs Nginx Performance: Optimization Techniques

この声明は、ハッカーニュースに関するかなり激しい議論を引き起こしましたが、私たちの経験では、MPM_Prefork ApacheからNginxに切り替えるだけで、通常、Webサイトがクラッシュするのを防ぐことを意味します。単にnginxに切り替えることは、通常、それ自体が回避策です。

nginxアーキテクチャのより包括的な視覚的説明は、こちらをご覧ください。

nginx設定

nginxは、Worker_Processesを/etc/nginx/nginx.conf（デフォルトは1）にAutoに設定することにより、労働者の数をPCコアの数（ApacheのMPM_Event構成で行ったように）に修正することをお勧めします。

worker_connections各ワーカープロセスが処理できる接続の数を設定します。デフォルトは512ですが、通常は増加できます。

KeepAlive接続は、パフォーマンスに影響するサーバーの側面であり、通常はベンチマークでは見えません。

Apache vs Nginx Performance: Optimization Techniques

NginxのWebサイトによると

：

HTTP KeepAlive接続は、レイテンシを削減し、Webページの読み込みをスピードアップする必要なパフォーマンス機能です。

新しいTCP接続を確立することは高価になる可能性があります。暗号化に関連する状況に言及することではありません。 HTTP/2プロトコルは、マルチプレックス機能でこれを軽減します。既存の接続を再利用すると、リクエスト時間を短縮できます。

ApacheのMPM_PREFORKとMPM_WORKERには同時性の制限がありますが、これはKeepALIVEイベントループとは対照的です。これは、Apache 2.4のMPM_EVENTモジュールである程度固定されており、NGINXの操作の唯一のデフォルトモードとして表示されます。 Nginxワーカーは、同時に何千もの着信接続を処理できます。逆プロキシまたはロードバランサーとして使用される場合、NginxはTCP接続オーバーヘッドなしでローカルキープアライブ接続プールを使用します。

Keepalive_Requestsは、クライアントが単一のキープライブ接続を介して行うことができるリクエストの数を規制する設定です。 keepalive_timeoutは、アイドルキープライブの接続が開いたままである時間を設定します。

KeepAliveは、nginxの上流サーバーへの接続に関連する設定です。これは、プロキシまたはロードバランサーとして機能する場合です。これは、労働者プロセスごとに無料のキープアライブ上流接続の数を意味します。

上流のキープアライブ接続を有効にするには、これらの命令をnginxメイン構成に入れる必要があります。

nginxアップストリーム接続は、NGX_HTTP_UPSTREAM_MODULEによって管理されます。 
<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

フロントエンドアプリケーションがバックエンドアプリケーションを更新のためにポーリングし続けている場合、KeepAlive_RequestsとKeepalive_Timeoutの増加により、作成する必要がある接続の数が制限されます。 KeepAliveディレクティブは、アップストリームサーバーへの他の接続を許可するために大きすぎてはなりません。

これらの設定の調整は、特定の状況に基づいており、テストする必要があります。これはおそらく、Keepaliveにデフォルトの設定がない理由の1つです。

Unixソケットを使用して

デフォルトでは、NGINXは個別のPHPプロセスを使用してPHPファイルリクエストを転送します。ここでは、プロキシとして機能します（php7.0-fpmでApacheを設定したときと同じです）。

通常、nginxを使用した仮想ホスト設定は次のとおりです。

FASTCGIとHTTPは異なるプロトコルであるため、最初の2行はいくつかのパラメーターとヘッダーをPHP -FPMに前進させ、3番目の行はローカルネットワークソケットを介してプロキシ要求の要求を指定します。 

<code>locust --host=https://my-website.com
</code>
これは、マルチサーバーのセットアップに実用的です。リクエストをプロキシにするリモートサーバーも指定できるためです。

ただし、単一のシステムでセットアップ全体をホストする場合は、UNIXソケットを使用してリスニングPHPプロセスに接続する必要があります。

unixソケットは、TCPよりも優れたパフォーマンスを持っていると考えられており、この設定はより安全であると考えられています。この設定の詳細については、この記事でRackspaceにご覧ください。

Unixソケットに関するこのヒントは、Apacheでも機能します。詳細はこちらをご覧ください。

GZIP_STATIC：Webサーバーのパフォーマンスに関する一般的な見解は、静的リソースを圧縮することです。これは通常、各リクエストで動的にリソースを圧縮することは高価になる可能性があるため、妥協して特定のしきい値を超えるファイルのみを圧縮しようとすることを意味します。 nginxには、通常のリソースの代わりに、gzipバージョンのファイル（拡張機能.gz）を提供できるGZIP_staticディレクティブがあります。

このようにして、nginxはstyle.cssの代わりにstyle.css.gzを提供しようとします（この場合、自分でgzippingを処理する必要があります）。 
<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>
この方法では、CPUサイクルは、各リクエストの動的圧縮で無駄になりません。

nginx

でキャッシュ

Nginxについてのストーリーは、コンテンツのキャッシュ方法について言及せずに不完全です。 Nginxキャッシュは非常に効率的であるため、多くのシステム管理者は、別のHTTPキャッシュ層（ワニスなど）があまり意味がないと考えています。 「シンプルさは特徴です。」 Nginxキャッシュを有効にすることは非常に簡単です。

これは、サーバーブロックの外側にある仮想ホストファイルに配置する指令です。 proxy_cache_pathパラメーターは、キャッシュを保存する任意のパスにすることができます。レベルは、NGINXがキャッシュコンテンツを保存するディレクトリレベルの数を指定します。パフォーマンスの理由から、通常、2つのレベルは問題ありません。ディレクトリをトラバースするのは時間がかかる場合があります。 keys_zoneパラメーターは、キャッシュキーを保存するために使用される共有メモリ領域の名前であり、10mはメモリ内のこれらのキーのスペースです（10MBで十分です。これは実際のキャッシュコンテンツのスペースではありません）。 max_sizeはオプションであり、キャッシュされた内容の上限を設定します - ここに10GBがあります。指定されていない場合、利用可能なすべてのスペースを占有します。非アクティブでは、コンテンツが要求される前にキャッシュにとどまることができる時間を指定し、Nginxによって削除されます。 

<code>locust --host=https://my-website.com
</code>
設定後、メモリ領域の名前をサーバーまたはロケーションブロックに含む次の行を追加します。

Nginxの追加断層耐性層は、ソースサーバー、アップストリームサーバー、またはサーバーダウンタイムでエラーが発生したときにキャッシュからアイテムを提供するようにNginxに指示することにより実装できます。

サーバーまたはロケーションブロックの指示の詳細については、nginxキャッシュをさらに調整するには、こちらを参照してください。 

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>
プロキシ

キャッシュ

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>
ディレクティブは静的リソースに使用されますが、通常、Webアプリケーションの動的な出力をキャッシュしたいのです。この場合、Proxyの代わりにfastCGI

キャッシュ

ディレクティブを使用します cache *： 上記の最後の行は、応答ヘッダーを設定して、コンテンツがキャッシュから渡されるかどうかを確認します。 次に、サーバーまたはロケーションブロックで、いくつかのキャッシュの例外を設定できます。たとえば、リクエストURLにクエリ文字列が存在する場合：

また、PHPの場合、サーバーの.phpブロックで、次のようなものを追加します。 
<code>sudo service start php7.0-fpm
</code>
上記の上記、fastcgi_cache* linesおよびfastcgi_no_cacheはキャッシュと除外を調節します。これらすべての指示への詳細な参照は、NGINXドキュメントWebサイトにあります。

詳細については、Nginxのスタッフはこのトピックに関する無料のウェビナーを提供しており、多くの電子書籍があります。

結論

Webサーバーのパフォーマンスとその背後にある理論の改善に役立ついくつかのテクノロジーを導入しようとしています。しかし、このトピックは決して網羅的なものではありません。まだ逆プロキシ設定やApacheとNginxで構成されるマルチサーバー設定をカバーしていません。両方のサーバーの最良の結果は、特定の実際のケースのテストと分析に依存します。これは終わりのないトピックです。

ApacheおよびNginxパフォーマンス最適化テクノロジーに関するFAQ

パフォーマンスと最適化の観点から、ApacheとNginxの重要な違いは何ですか？

ApacheとNginxはどちらも強力なWebサーバーですが、パフォーマンスと最適化機能には大きな違いがあります。 Apacheは、プロセス駆動型モデルを使用して各リクエストの新しいスレッドを作成する古いサーバーです。これにより、複数の同時接続を扱うときに、メモリ使用量が大量に使用される可能性があります。一方、Nginxは、メモリ使用量がほとんどなく、数千の接続を同時に処理できるようにするイベント駆動型アーキテクチャを使用します。これにより、特に静的コンテンツの配信と逆プロキシシナリオで、Nginxがより効率的かつ高速になります。

パフォーマンスを向上させるためにnginxを最適化するにはどうすればよいですか？

nginxを最適化してパフォーマンスを向上させるには、複数の方法があります。まず、労働者のプロセスとワーカーの接続を調整できます。ワーカープロセスは、CPUまたはコアの数に設定する必要がありますが、ワーカー接続は最大オープンファイル制限に設定する必要があります。次に、GZIP圧縮を有効にして、Nginxがクライアントに送信するデータのサイズを縮小できます。第三に、キャッシュを使用してメモリに頻繁にアクセスされるデータを保存して、ディスクI/O操作を削減できます。最後に、ロードバランスを使用して、複数のサーバーにネットワークトラフィックを広め、応答時間と全体的なパフォーマンスを改善できます。

パフォーマンスを向上させるためにApacheを最適化する方法は？

Apacheはさまざまな方法で最適化できます。まず、MaxClients指令を調整して、同時接続の最大数を制御できます。次に、MOD_DEFLATEをクライアントに送信する前にデータを圧縮できるようにして、帯域幅の使用を削減できます。第三に、CacheにMod_Cacheを使用して、メモリに頻繁にアクセスされるデータを保存して、ディスクI/O操作を削減できます。最後に、mod_proxy_balancerを使用してバランスを読み込み、複数のサーバーにネットワークトラフィックを広め、応答時間と全体的なパフォーマンスを改善できます。

ApacheとNginxを同時に使用できますか？

はい、逆プロキシ設定でApacheとNginxの両方を使用できます。この構成では、nginxはクライアント要求を処理するフロントエンドサーバーとして機能し、Apacheはこれらのリクエストを処理するバックエンドサーバーとして機能します。このセットアップは、両方のサーバーの利点を組み合わせて、Nginxは静的コンテンツを効率的に処理し、Apacheは動的なコンテンツ処理を提供します。

nginxは、静的コンテンツと動的コンテンツをさまざまな方法でどのように処理しますか？

nginxは、イベント駆動型アーキテクチャのために静的コンテンツを提供することに優れています。これにより、最小限のメモリ使用量と同時に数千の同時接続を処理できます。動的なコンテンツの場合、NGINXはリクエストをアプリケーションサーバー（PHP-FPMなど）に渡すか、それらをApacheサーバーにプロキシできます。ただし、NGINXは、ApacheがMOD_PHPモジュールを使用するように、ローカルで動的コンテンツを処理しません。

Apacheは、静的コンテンツと動的コンテンツをさまざまな方法でどのように処理しますか？

Apacheは静的コンテンツと動的なコンテンツを提供できます。静的コンテンツの場合、Apacheはコアモジュールを使用します。動的なコンテンツの場合、ApacheはMOD_PHPなどの追加のモジュールを使用してPHPスクリプトを処理します。ただし、Apacheのプロセス駆動型モデルは、複数の同時接続を扱う際に大量のメモリ使用量につながる可能性があり、静的コンテンツの配信に関してNginxよりも効率が低くなります。

サーバーの最適化は、ウェブサイトのパフォーマンスにどのような影響を与えますか？

サーバーの最適化により、ウェブサイトのパフォーマンスが大幅に向上する可能性があります。サーバーの応答時間を短縮し、サーバーが処理できる同時接続の数を増やし、帯域幅の使用量を減らすことができます。これにより、ページの読み込み時間が短縮され、ユーザーエクスペリエンスが向上し、SEOランキングが改善されます。

apacheとnginxを選択する方法は？

apacheとnginxを選択することは、特定のニーズに依存します。多くの同時接続を効率的に処理できるサーバーが必要な場合、または主に静的コンテンツを提供できる場合は、Nginxがより良い選択かもしれません。動的なコンテンツ処理を強力にサポートするサーバーが必要な場合、または構成用に.htaccessファイルに依存している場合、Apacheがより適切になる場合があります。

ApacheとNginxの一般的なパフォーマンスの問題は何ですか？

Apacheの一般的なパフォーマンスの問題には、複数の並行接続を処理するときの高いメモリ使用量と応答時間が遅いことが含まれます。 Nginxの場合、一般的な問題には、ワーカープロセスと接続の不適切な構成、および動的なコンテンツ処理機能の欠如が含まれます。

ApacheとNginxのパフォーマンスを監視する方法は？

さまざまなツールを使用して、ApacheとNginxのパフォーマンスを監視できます。 Apacheの場合、mod_statusモジュールを使用してサーバーステータス情報を提供できます。 nginxの場合、stub_statusモジュールを使用できます。さらに、New Relic、DataDog、Nagiosなどのサードパーティ監視ツールを使用して、より詳細なパフォーマンスメトリックとアラートを取得できます。

以上がApache vs Nginxパフォーマンス：最適化技術の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

Python php perl nginx 架构 css cURL auto 字符串 循环 栈 堆 Event 线程 并发 事件 异步 macos apache http https linux 性能优化 ddos unix 服务器网络 数据中心 负载均衡 cms SEO
声明：
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
前の記事：JWT（JSON Web Tokens）によるPHP認証次の記事：JWT（JSON Web Tokens）によるPHP認証

関連記事

続きを見る