ApacheとNGINX-パフォーマンスの面で誰が勝ちますか？

公開: 2022-04-02

ApacheとNGINXは、（NGINXのリリース以来）最もホットな議論の1つです。これは、どちらもLiteSpeedとOpenLiteSpeedが続く最も一般的なWebサーバーの1つだからです。

ApacheとNGINXは、世界のWebサイトのほぼ60％に電力を供給しています。 ApacheとNGINXは、パフォーマンスと機能の点で類似しています。 一方、それらのアーキテクチャ、セキュリティ、およびパフォーマンスはすべて異なります。

これら2つのサーバーはどちらも優れているため、どちらかを選択するのは難しい場合があります。 各Webサーバーには独自の長所と短所があるため、最良のオプションを可能にすることが重要です。

ここでopenlitespeedとnginxの議論を確認することもできます。

目次

ApacheとNGINXの速度比較

ApacheとNGINXの議論を深く掘り下げる前に。 まず、簡単な速度テストを行います。ここでは、次のシナリオでテストを実行します。

  • 5キロバイトの小さな静的ファイルをテストしてみましょう
  • サイズ1MBの静的ファイル
  • 単純なPHPHelloWorldアプリケーションのテスト
  • WordPressのApacheとNGINXのベンチマーク

openlitespeedとnginxのテストに同じ手順を使用しました。 OpenLiteSpeedは、基本的な.htaccess書き換えルールもサポートしているため、NGINXの優れた代替手段であり、ApacheからOpenLiteSpeedに簡単に移行できます。

5キロバイトの小さな静的ファイルをテストしてみましょう

最終評決：両方のサーバーは、小さな静的ファイルで同じように動作しました。

Apache

ApacheとNGINX

NGINX

サイズ1MBの静的ファイル

最終評決：NGINXは明らかに大きな静的ファイルで勝ちました。

Apache

NGINX

単純なPHPHelloWorldアプリケーションのテスト

最終評決：両方のサーバーは、helloworldphpアプリケーションで同じように動作しました。

Apache

NGINX

WordPressのApacheとNGINXのベンチマーク

最終評決：NGINXは明らかにWordPressサイトで勝ちました。 このガイドを使用して、WooCommerceストアをスピードアップできます

Apache

NGINX

テストの結果-ApacheとNGINX

テストでわかるように、NGINXは速度の点でApacheよりも比較的優れています。 結果は次のとおりです。

1.5Kバイトの小さな静的ファイルをテストします。

このテストでは、ApacheとNGINXの両方が比較的同じ結果を出していることがわかります。

2.サイズ1MBの大きな静的ファイルをテストします。

このテストでは、NGINXの速度がApacheよりも飛躍的に優れていることがわかります。 NGINXの平均応答時間ははるかに短くなっています。

3.単純なPHPHelloWorldアプリケーションをテストします

このテストでは、ApacheとNGINXの両方が比較的同じ結果を出していることがわかります。

4.WordPress用のApacheとNGINXのテスト

このテストでは、NGINXの平均応答時間はApacheの平均応答時間よりもはるかに短く、NGINXよりも高速であることがわかります。

Apache

ApacheをオープンソースのWebサーバーとして維持している開発者のコ​​ミュニティがあります。 プロセス駆動型アーキテクチャを使用して、接続要求ごとに新しいスレッドを作成します。
さらに、Apacheは、Webサーバーの機能を向上させるために使用できるさまざまなモジュールを提供します。 Apacheは、拡張機能とモジュールを使用することで、さまざまな環境のニーズを満たすために、高速で信頼性が高く、安全で、高度にカスタマイズ可能です。

接続処理アーキテクチャ

Apacheには、クライアント要求の処理方法を制御する多数のマルチプロセッシングモジュール（ApacheではMPMと呼ばれます）があります。 基本的に、これにより、管理者は接続処理アーキテクチャをすばやく切り替えることができます。

  • mpm-Prefor：このマルチプロセッシングモジュール（MPM）は、スレッド化されていないプリフォークWebサーバーを実装します。 各サーバープロセスは着信要求に応答でき、サーバープールのサイズは親プロセスによって管理されます。 スレッドセーフではないライブラリを操作するためにスレッド化を回避する必要があるサイトに適しています。 また、各リクエストを分離するための最高のMPMであり、1つの問題が他のリクエストに影響を与えないようにします。
  • mpm-worker：ハイブリッドマルチプロセスマルチスレッドサーバーは、このマルチプロセッシングモジュール（MPM）によって実装されます。 スレッドを使用してリクエストを配信するため、プロセスベースのサーバーよりも少ないシステムリソースで多数のリクエストを処理できます。 それぞれが多くのスレッドを持つ多数のプロセスを利用可能に保つことにより、プロセスベースのサーバーの安定性の多くを保持します。
  • mpm-event：イベントMulti-Processing Module（MPM）は、特定の処理をリスナースレッドに委任し、ワーカースレッドを解放して新しい要求を処理することにより、複数の要求を同時に処理できるようにすることを目的としています。
    Apacheは柔軟な設計であり、さまざまな接続および要求処理アルゴリズムから選択できます。 インターネットの状況が変化するにつれて、提示される選択肢は主にサーバーの進化と同時実行性に対する需要の高まりの産物です。

静的コンテンツと動的コンテンツ

静的コンテンツは、標準のファイルベースのメカニズムを使用してApacheサーバーで処理できます。 上記のMPMアプローチは、これらの手順の実行に主に責任があります。

Apacheは、各ワーカーインスタンスに言語固有のプロセッサを含めることで、動的コンテンツをさらに処理できます。 これにより、Webサーバー内の外部コンポーネントを使用せずに動的コンテンツを実行できます。 動的にロード可能なモジュールを使用して、これらの動的プロセッサを有効にすることができます。

Apacheは動的コンテンツを内部で処理できるため、通常、動的処理の構成が簡単です。 コンテンツ要件が変更された場合、モジュールは簡単に交換でき、通信を追加のソフトウェアと調整する必要はありません。

分散構成と集中構成

Apacheは、コンテンツフォルダー自体の隠しファイル内のディレクティブを分析および解釈することにより、ディレクトリごとにさらに構成できるようにするオプションを追加します。 .htaccessファイルはこれらのファイルの名前です。

これらのファイルはコンテンツフォルダ内にあるため、Apacheは要求されたファイルへのパスの各コンポーネントで.htaccessファイルを探し、そこで見つかったディレクティブを適用します。 これにより、URLの書き換え、アクセス制限、承認と認証、さらにはキャッシュポリシーに一般的に使用される、分散型Webサーバーのセットアップが効果的に可能になります。

上記の例はすべてメインのApache構成ファイルで設定できますが、 .htaccessファイルには多くの利点があります。 まず、リクエストパスに沿って検出されるたびに評価されるため、サーバーをリロードしなくても実装されます。 次に、非特権ユーザーが、構成ファイルに対する完全な権限を与えることなく、自分のWebコンテンツの特定の部分を制御できるようにします。

コンテンツ管理システムなどの特定のWebソフトウェアは、中央構成ファイルにアクセスしなくても、環境を簡単にカスタマイズできるようになりました。 共有ホスティングプロバイダーはこれを利用して、クライアントに特定のディレクトリへのアクセスを提供しながら、コアセットアップの制御を維持します。

ファイルとURIベースの解釈

Apacheは、リクエストを物理ファイルシステムリソースまたはより抽象的な評価を必要とするURI宛先として解釈できます。 一般に、Apacheは前者に<Directory>または<File>ブロックを使用しますが、 <Location>ブロックはより抽象的なリソースに使用されます。

ApacheはゼロからWebサーバーとして構築されているため、デフォルトではリクエストをファイルシステムリソースとして解釈します。 実際のファイルを見つけるには、ドキュメントルートから開始し、ホストとポート番号の後にリクエストの一部を追加します。 Webでは、ファイルシステム階層は基本的に使用可能なドキュメントツリーで表されます。

リクエストが基盤となるファイルシステムと一致しない場合、Apacheはいくつかのオプションを提供します。 たとえば、Aliasディレクティブを使用して、別の場所にマップできます。 ファイルシステムの代わりに<Location>ブロックを使用すると、URIを直接操作できます。 ファイルシステム全体に構成をより柔軟に適用するために、正規表現のバリエーションも利用できます。

Apacheは、基盤となるファイルシステムとWebスペースの両方で機能しますが、ファイルシステム技術を使用することを好みます。 ディレクトリごとの設定に.htaccessファイルを使用するなど、設計上の決定の一部はこれを反映しています。

係数

Apacheのモジュールシステムを使用すると、サーバーの実行中に必要に応じてモジュールを動的にロードおよびアンロードできます。 Apacheコアは常に存在しますが、モジュールを有効または無効にしたり、機能を追加または削除したり、メインサーバーに接続したりできます。

この機能は、Apacheによってさまざまなタスクに使用されます。 プラットフォームは成熟しているため、モジュールの大規模なライブラリが付属しています。 たとえば、Mod phpは、実行中の各ワーカーにPHPインタープリターを埋め込み、サーバーの重要な機能の一部を変更するために使用できます。

一方、モジュールは動的コンテンツを処理するだけではありません。 URLの書き換え、クライアントの認証、サーバーの強化、ログ記録、キャッシュ、圧縮、プロキシ、レートの制限、データの暗号化などの機能を利用できます。 多くの作業を追加することなく、拡張機能を提供できます。

サポート、互換性、エコシステム、およびドキュメント

Apacheは長い間使用されてきたため、多くのサポートがあります。 Apacheを他のソフトウェアに接続することを含むコアサーバーおよびタスクベースの状況では、アクセス可能なファーストパーティおよびサードパーティのドキュメントの実質的なライブラリがあります。

多くのツールとWebプロジェクトには、ドキュメントに加えて、Apache環境内で自身をブートストラップするためのツールが含まれています。 これは、プロジェクト自体、またはディストリビューションのパッケージングチームが管理するパッケージで提供される場合があります。

その市場シェアとそれが利用可能であった時間の長さのために; Apacheは、一般的にサードパーティプロジェクトからより多くのサポートを受けます。 管理者は、Apacheが広く使用されているだけでなく、 .htaccess分散管理機能のためにApacheが事実上単独で使用されている共有ホスティング環境でキャリアを開始するため、Apacheを使用した可能性が高くなります。

ApacheとNGINXの利点

多くのウェブマスターや開発者は、Apacheがはるかに古いため、NGINXよりもApacheを好みます。 Windows、Unix、およびLinuxオペレーティングシステムと互換性があります。

•ダイナミックな素材を提供するために、これは優れたパフォーマンスです。
•モジュールを動的にロードおよびアンロードします。
•システム全体の設定を無効にするために使用できるディレクトリごとの.htaccessファイルを提供します。
•サポートとドキュメントは優れています。
•モデルは、プロセスごとに1つの接続アプローチを使用します。
•これには、セキュリティの層を追加するmod_evasiveモジュールとmod_securityモジュールが含まれています。

ApacheとNGINXのデメリット

•同時に多数のリクエストを処理することはできません。
•NGINXと比較すると、静的コンテンツの表示に時間がかかります。
•広範なセットアップおよび管理機能を提供します。 結果として、それは初心者には適切ではありません。
•トラフィックの多いWebサイトには、パフォーマンスの問題があります。

NGINX

「C10k」問題を克服するために、ロシアのコーダーIgorSysoevがNGINXを発明しました。 Igorは目標を達成しました。NGINXは10,000を超える同時接続を簡単に管理できます。 新しい接続をより適切に処理するために、NGINXにはイベント駆動型の非同期設計があります。 NGINXは、多くの機能を提供するWebサーバーです。 以下にリストされているのはそれらのいくつかです：

•HTTPキャッシュとロードバランサー
•Apacheおよびその他のWebサーバーのフロントエンドプロキシ。
•HTTP、HTTPS、SMTP、POP3、およびIMAPプロトコルはすべて、このリバースプロキシサーバーによって提供されます。

NGINXは、リリース以来、リソースの使用量が少なく、低コストのハードウェアで効果的に拡張できるため、人気が高まっています。 NGINXは、静的な素材をすばやく提供することに特化したWebサーバーであり、動的な要求をそのようなタスクにより適したソフトウェアに転送するように設計されています。

接続処理アーキテクチャ

NGINXは、Apacheの後に登場し、大規模なサイトが直面する同時実行性の問題をよりよく理解しました。 NGINXは、この情報を利用するために、非同期の非ブロッキングイベント駆動型接続処理アルゴリズムを使用してゼロから構築されました。

NGINXはワーカープロセスを生成します。各プロセスは数万の接続を処理できます。 ワーカープロセスは、イベントを定期的にチェックして処理する高速ループメカニズムを開発することでこれを実現します。 実際の作業を接続から切り離すことにより、各ワーカーは、新しいイベントが発生した場合にのみ接続に集中できます。

ワーカーの各接続はイベントループに配置され、他の接続と共存します。 イベントはループ内で非同期に処理されるため、ブロックされない方法で作業を行うことができます。 リンクは、閉じた後にループから削除されます。

NGINXは、接続処理方法のおかげで、最小限のリソースで非常に遠くまで拡張できます。 サーバーはシングルスレッドであり、新しい接続を処理するための追加のプロセスが生成されないため、サーバーに大きな負荷がかかっている場合でも、メモリとCPUの使用量は比較的一定に保たれます。

静的コンテンツと動的コンテンツ

NGINXは、動的コンテンツ処理をネイティブでサポートしていません。 NGINXは、PHPおよびその他の動的コンテンツ要求を処理のために外部プロセッサに渡してから、レンダリングされたコンテンツが返されるのを待つ必要があります。 その後、クライアントに調査結果を通知できます。

管理者にとって、これは、NGINXとプロセッサ間の通信が、NGINXが理解するプロトコル（http、FastCGI、SCGI、uWSGI、memcache）の1つを使用して構成する必要があることを意味します。 これにより、特に許可する接続数を見積もる場合、プロセッサへの呼び出しごとに新しい接続が必要になるため、状況が少し複雑になる可能性があります。

一方、この戦略にはいくつかの利点があります。 動的インタープリターのオーバーヘッドは、ワーカープロセスに含まれていないため、動的マテリアルに対してのみ存在します。 静的コンテンツは簡単な方法で送信でき、必要な場合にのみ通訳に相談します。 これはApacheでも可能ですが、前のセクションで説明した利点がなくなります。

分散構成と集中構成

NGINXは.htaccessファイルを理解せず、メイン構成ファイルの外部でディレクトリごとの構成を評価する方法がありません。 Apacheのアプローチほど用途が広いわけではありませんが、独自の利点があります。

パフォーマンスの向上は、ディレクトリレベルの設定の.htaccessアプローチに比べて最も顕著な利点です。 サーバーは、リクエストごとに、任意のディレクトリで.htaccessを許可する標準のApacheセットアップで、リクエストされたファイルに至るまでの各親ディレクトリでこれらのファイルをチェックします。 この検索で​​1つ以上の.htaccessファイルが見つかった場合は、それらを読み取って処理する必要があります。 NGINXは、単一のディレクトリクエリを実行し、ディレクトリのオーバーライドを許可しないことでリクエストごとにファイルを読み取ることで、リクエストをより迅速に処理できます（ファイルが従来のディレクトリ構造にあると想定）。

もう1つの利点は、安全であるということです。 ディレクトリレベルの構成アクセスを配布すると、セキュリティの責任が個々のユーザーに広がります。個々のユーザーは、適切にそうすることが信頼されている場合とされていない場合があります。 管理者がWebサーバーを完全に制御できるようにすることで、他のユーザーにアクセスが許可されたときに発生する可能性のあるいくつかのセキュリティの失敗を回避できます。

これらの問題が心配な場合は、Apacheで.htaccessの解釈を無効にすることができることに注意してください。

ファイルVSURIベースの解釈

NGINXは、プロキシサーバーとしてだけでなくWebサーバーとしても動作するように設計されています。 これらの2つのジョブに必要なアーキテクチャにより、主にURIで機能し、必要に応じてファイルシステムに変換されます。

これは、NGINX構成ファイルが構築および処理される方法で見られる場合があります。
NGINXにはファイルシステムディレクトリの構成を指定する方法がないため、URIを解析します。

たとえば、サーバーブロックとロケーションブロックは、NGINXの最も重要な構成ブロックです。 サーバーブロックは要求されたホストの解釈を担当し、ロケーションブロックはホストとポートの後のURIの一致部分を担当します。 リクエストは現在、ファイルシステムの場所ではなくURIとして処理されています。

静的ファイルに対するすべての要求は、最終的にディスク上の場所にマップする必要があります。 NGINXは、最初にリクエストを処理するサーバーとロケーションブロックを選択し、次にドキュメントルートをURIと結合し、設定に基づいて必要に応じて変更します。

これは似ているように見えるかもしれませんが、リクエストをファイルシステムの場所ではなく主にURIとして解釈することで、NGINXがWeb、メール、およびプロキシサーバーとして機能しやすくなります。 NGINXは、特定のリクエストパターンにどのように応答するかを定義することで設定されます。 NGINXは、リクエストを配信する準備ができるまでファイルシステムを検査しません。そのため、 .htaccessファイルはサポートされていません。

モジュール

NGINXにもモジュールシステムがありますが、Apacheのものとはかなり異なります。 NGINXのモジュールは動的にロードできないため、選択してコアソフトウェアにコンパイルする必要があります。
この結果、NGINXは多くのユーザーにとってはるかに適応性が低くなります。 これは、ディストリビューションの標準パッケージスキームの外で独自に構築したソフトウェアを維持することを躊躇しているユーザーに特に当てはまります。 ほとんどのディストリビューションのパッケージには最も一般的に使用されるモジュールが含まれていますが、非標準のモジュールが必要な場合は、ソースからサーバーを自分で構築する必要があります。

一方、NGINXモジュールは、使用したい機能を含めるだけでサーバーに必要なものを正確に指定できるため、依然として非常に価値があります。 一部のユーザーは、任意のコンポーネントをサーバーに接続できないため、このアプローチの方が安全であると考える場合もあります。 これが考えられる状況にサーバーが置かれた場合、ほぼ確実にすでに侵害されています。

NGINXモジュールでは、Apacheモジュールと同じ機能の多くを利用できます。 プロキシサポート、圧縮、レート制限、ロギング、書き換え、ジオロケーション、認証、暗号化、ストリーミング、およびメール機能はすべて、NGINXモジュールを介して利用できます。

サポート、互換性、エコシステム、およびドキュメント

NGINXは、その高性能のために多くの人々がそれを使用するにつれて人気を集めていますが、それでも特定の重要な分野でやるべきことがいくつかあります。

初期の開発とドキュメントのほとんどはロシア語であったため、過去にNGINXの実質的な英語のドキュメントを見つけることは困難でした。 プロジェクトへの関心が高まるにつれ、ドキュメントが具体化されました。現在、NGINXサイトやサードパーティを通じて利用できる管理リソースがたくさんあります。

サードパーティアプリのサポートとドキュメントがより広く利用できるようになり、パッケージメンテナは、状況によってはApacheとNGINXを自動構成するためのオプションを提供し始めています。 プロジェクトのニーズ（権限、ヘッダーなど）が文書化されている限り、他のソフトウェアで動作するようにNGINXを構成することは、通常、サポートがなくても簡単です。

NGINXの利点

NGINX Webサーバーは、シンプル、軽量、高速です。 トラフィックの多いWebサイト用に特別に設計されています。

•CPUとメモリの使用量が少ない、イベント駆動型の非ブロッキングアーキテクチャを使用します。
•静的コンテンツの多くの最適化と配信オプションが含まれています。 その結果、静的コンテンツを2.5倍高速に提供し、Apacheよりも少ないメモリを使用します。
•マルチプロセッサシステムで見事に機能します。
•DDoS攻撃は、組み込みの構成オプションによって防止されます。

NGINXのデメリット

•動的コンテンツをネイティブに処理することはできません。
•使用可能なモジュールの数が少なくなります。
•LinuxおよびUnixオペレーティングシステムがサポートされていますが、Windowsのサポートは制限されています。
•Apacheでサポートされている.htaccessファイルは、NGINXではサポートされていません。
•ログ監視ソフトウェアの不足–手動でナビゲートする必要のあるファイルにログを保存するだけです。

ApacheとNGINXを一緒に使用するには

ApacheとNGINXの両方の長所と短所を確認した後、どちらのサーバーがニーズにより適しているかを判断できるはずです。 ただし、多くのユーザーは、両方のサーバーを一緒に使用すると、各サーバーの利点を活用できることに気付きます。

この連携の標準構成は、Apacheの前でリバースプロキシとしてNGINXを使用することです。 これにより、NGINXはすべてのクライアントリクエストを処理できるようになります。 これは、NGINXの迅速な処理速度と、一度に多数の接続を管理する機能を利用しています。

ファイルは、NGINXが優れている静的コンテンツのクライアントに迅速かつ直接提供されます。 NGINXは、PHPスクリプトなどの動的コンテンツのリクエストをApacheにプロキシし、Apacheは結果を処理して、レンダリングされたページを提供します。 その後、NGINXを介して資料をクライアントに返すことができます。

多くのユーザーにとって、この設計はNGINXが仕分け機として機能することを可能にするため、うまく機能します。 可能なすべてのリクエストを処理し、処理方法がわからないリクエストを渡します。 Apacheサーバーが処理するように要求されるリクエストの数を減らすことで、Apacheプロセスまたはスレッドが占有されているときに発生するブロッキングの一部を減らすことができます。

必要に応じてバックエンドサーバーを追加することで、この配置でスケールアウトできます。 NGINXは、サーバーのプールにリクエストを転送するように簡単にセットアップできるため、構成のフォールトトレランスとパフォーマンスが向上します。

ApacheとNGINXをいつ使用するのですか？

この記事で説明するように、ApacheとNGINXはどちらも、強力で、適応性があり、万能の優れたWebサーバーです。 トラフィックの多いWebサイトの場合、動的な素材を提供するにはApacheが最適ですが、静的なコンテンツやメディアストリームを提供するにはNGINXが最適です。 これと同じくらい簡単です：

いつApacheを使用できますか

•共有ホスティングプランを利用している場合。
•多数のリソースを備えた役立つコミュニティに感謝する場合は、ここが最適です。
•Apacheは、セットアップが簡単なため、Web開発者の間で人気があります。

いつNGINXを使用できますか

•VPSまたは専用サーバーがある場合。
•あなたは、静的コンテンツがたくさんある人気のあるWebサイトの所有者です。
•着信トラフィックを管理し、低速のアップストリームサーバーに分散する場合。

ApacheとNGINX：2022年にサーバーにどちらを選択する必要がありますか？

あなたのホスティング会社が提供するものはどれでもあなたが使うべきものです。 多くの場合、選択肢はありません。 多くのWebプロバイダーは同じ戦略に従います。これは、ApacheとNGINXのどちらを使用するかを決定する場合に従う必要があります。

•一定のセットアップが必要なサーバーをホストする場合、またはユーザーに構成オプションを提供する場合は、Apacheが適しています。
•一方、NGINXは、超高速のパフォーマンス、堅実なセキュリティ、およびユーザーではなく構成を管理する機能が必要な場合に最適です。

その基本的なアーキテクチャにより、Apacheはパフォーマンスの点でより多くのRAMを使用できます。 トラフィックが多い場合、特に管理する静的マテリアルが多い場合は、NGINXのパフォーマンスが向上します。

したがって、コンテンツの保存と提供をキャッシュに依存している場合は、NGINXが理想的なソリューションになる可能性があります。 NGINXは動的なマテリアルを提供できないことに注意してください。 したがって、パフォーマンスは、サーバーが使用するプロキシの有効性に影響されます。

結論

ご覧のとおり、ApacheとNGINXは強力で、適応性があり、機能があります。 個々のニーズを評価し、予想されるパターンをテストすることが、適切なサーバーを選択するための主要な基準です。

これらのプロジェクトの中で、生のパフォーマンス、機能、およびそれぞれの実装にかかる時間には大きな違いがあります。 ただし、多くの場合、これらは無視してはならない一連のトレードオフの結果です。 大事なことを言い忘れましたが、万能のWebサーバーのようなものはないので、ニーズに合ったオプションを選択してください。