Nginx対Apache-実際の使用法の比較と統計情報はありますか?


45

遊ぶための新しいサーバーがあり、空白のキャンバスを見つめています。好きなものを置くことができます。私はApacheに慣れていますが、nginxがApacheよりもはるかに多くのトラフィックを10、100倍、さらに多く処理できることを聞き続けています。それだけでなく、「はるかに高速」です。

記事を検索すると、Drupalに関係のないものがたくさん見つかります。または、Drupal関連の記事に出くわすと、1)構成ファイルのセットアップ方法を簡単に説明した構成ファイル、または2)「いいえ、nginxを使用しないで、PHPでApacheを使用する」と言います。 fcgid」と表示されますが、その理由についての説明はありません。

それで、Drupalに関しては、ここでの現実は何ですか?

例として、この2bits.comの記事に沿って何かを探しています。ここでは、著者はfcgidを使用してApache mod_phpとApacheをかなり詳細に調査し、それぞれの長所と短所を比較検討し、実世界での影響を示すケーススタディを提供しました。この記事には、自分の状況に最適なアプローチについて知識に基づいた決定を下すのに十分な情報があります。

その著者はmod_phpとfcgidを比較していますが、私はApacheとNginxの同じタイプの包括的で現実的な世界を探しています。

誰もがNginxに切り替えて、Apacheと比較した違いによって「吹き飛ばされ」ましたか?既にAPC、Memcache、およびVarnishのようなアグレッシブキャッシングを使用している高度に最適化された環境であっても、変更する変数がApacheをNginxに置き換えるだけである場合、この新しい代替テクノロジーへの投資に値するほどの違いをもたらします?

このサーバーにアクセスするサイトは、1か月に平均200万PVを取得します。セントOS 6を実行するLAMPスタック。8コアのRAMを備えた4コアCPU。MemcachedとAPCはこのミックスの一部になります。Drupalのインストールについて特別なことはありません-基本的には、約50モジュールのバニラ7です。


2
特定のサイトのパフォーマンスを調整する場合は、他の人の作業に依存するよりも、独自のテストを実行する方が適切です。たとえば、匿名ユーザーとログインユーザーの混在が大きな要因です。あなたが主に匿名のトラフィックを取得しているサイトのパフォーマンス統計を見て、あなたのものがそのようではない場合、あなたも気にしないかもしれません。しかし、サイトの大部分が匿名のトラフィックを持っている場合、私の経験では、VarnishをWebサーバーの前に置くと、背後で実行するサーバーよりもはるかに大きな違いが生じます。
アルフレッドアームストロング

回答:


60

厳密に言えば、これはあなたが尋ねている質問には答えません。とにかく役立つことを願っています。

Apache / Nginx / Lighttpd / other Webサーバー。どちらを選ぶかは重要ですか?要するに、いいえ

はるかに長い答え:

もし、唯一の場合、Webサーバーのパフォーマンスにまったく注意を払う必要がある場合、非常に多くのユーザーがログインしています。ユーザーが匿名の場合、そのレイヤーでの最適化から理論的に導き出すことができる違いは、リソースをよりキャッシュ可能にすることと比較して絶対に見劣りします。cssファイルに適切なキャッシュヘッダーがある場合、UAは2回目も要求しません。それは重要です。Varnishまたは同様のソフトウェアソリューションでページをキャッシュできる場合、そのページの提供はハッシュルックアップを行い、RAMから直接大量のデータを返すだけです。それは重要です。これらのシナリオの両方で、HTTPデーモンが関与することはなく、PHPは呼び出されません。Drupalはブートストラップしません。RAMに大量のモジュールをロードする必要はありません。時間のかかるデータベースクエリは実行されません。

複雑なページで、ログインしているユーザーに対してコールドキャッシュからページ全体の読み込みを実行する場合。多くのことが起こっています。はい。Webサーバーは、着信要求の処理、ヘッダーの設定、および応答の返送に関与しています。しかし、かかる時間は、Drupalが完全なブートストラップを実行し、その応答を出力するという状況においても関係ありません。何百ものデータベースクエリが実行されている可能性があります。PHPの非常に複雑なロジックは、パーサーによって評価されます。多くのモジュールがRAMにロードされています。これらのいずれかのパフォーマンスを改善すると、パフォーマンスに大きく貢献する可能性が高くなります。

議論のため:他のすべてを最適化するのに多くの時間を費やしたとしましょう。

  1. あなたは実行APC(またはオプティマイザ+)とPHPの最新かつ最速のバージョンを。
  2. DBクエリはほとんどありません。
  3. PHPロジックが削減されました。
  4. ワニスにできることをキャッシュします。
  5. 多くのクライアント側をキャッシュできるようにサイト全体を再構築し、ECMAScriptで多くの面倒な作業を行いました。

ログインしているユーザーが多く、上記のすべてを処理している場合は、おそらくパフォーマンスチューニングを行うか、Webサーバーを交換することで違いを生むことができます。しかし、何を推測します。サイトは非常に複雑であり、特定のユーザーの使用パターンは独特です。一般的な答えはありません。シナリオの下でロードバランサーの背後にあるすべての異なるWebサーバーをセットアップし、それらの動作を確認する必要があります

上記は、Webサーバーの最適化に時間パフォーマンスを費やすことは時間の不適切な使用である可能性が高いという結論に論理的に到達する試みでした。私は誰かに上記の穴を選んでもらいたいのですが、おそらくそこから何か新しいことを学ぶでしょう。:)

その他の注意事項:

  1. 中にDrupalConコペンハーゲン基調講演、PHPクリエイターラスマス・ラードフは、nginxの自分自身を使用して、Drupalのパフォーマンスの話題に言えば、言った「人々は常にWebサーバについて私に尋ねる...それは本当に問題で、Webサーバは無関係かなり多くあるしません」 。(ビデオでは大体26:30)
  2. Facebookは、「わずかな」100%でPHPコードを高速化するために、Drupal自体よりも大幅に大きいコードベースであるHiphopの作成に無数の時間を費やしました。Hiphopで調べたところ$ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1、1.512.481行のコードで構成されていることがわかりました。これは、PHPの速度を改善するために費やされた非常に多くの作業です。PHPの速度が彼らにとって非常に重要だからだと思います。
  3. 優れたキャッシングは、Webサーバーのチューニングよりもはるかに大きな効果をもたらすと述べましたか?
  4. Apache 2.4のリリースにより、Jim Jagielskiは基本的に、Apache 2.4はイベントベースのサーバーよりも高速であると主張しています
  5. この質問が出てきたThe Dream TeamDrupalのパフォーマンスとスケーラビリティに注目しました。選択するすべての答えは、パフォーマンスとは無関係でした。「どの設定方法を既に知っているか」や「最も簡単な技術スタックを構築できるようにする」などのことは、他のものよりも選ぶ理由として挙げられています。パフォーマンスは状況に影響しませんでした

4
CSS、JS、および画像リクエストの大部分がWebサーバーに到達するのを防ぐために、CDNを忘れないでください。
mpdonadio

素晴らしい点!drupal.stackexchange.com/questions/24180 / ...をいつか書き直す必要があると思います。Apache / Nginxについての議論は、パフォーマンスの最適化の包括的なリストを作成するのに最適な場所とは思えません。
レサリオン

1
これは素晴らしい答えです。ちょっとした注意:「ECMAScript」と「JavaScript」を同じ意味で使用しないでください。JavaScriptにはECMAScriptよりも多くの機能があります。

あなたは、キャッシュがウェブサーバーの速度よりもはるかに重要であると言っています。何だと思う?Webサーバーが他のWebサーバーよりも少ないメモリを使用している場合、キャッシュ用により多くのRAMを使用できます。したがって、RAMをすべて消費しないようにWebサーバーを適切に調整すること重要であると言えますか?
pqnet 14

より少ないRAMを使用するようにサーバーを調整することはまったく問題ありませんが、高性能の領域に移行しようとしている場合は、専用サーバーでニスを実行する可能性が高いため、httpサーバーとキャッシュが同じメモリを奪い合うことはありません。
レサリオン

32

OK、この質問はすでに答えられていますが、私はもう一度ネクロマンシングをしています。主に、これらの答えが意味をなさないという意味が嫌いであり、ウェブ開発者として情熱を持ってキャッシングが嫌いだからです。

Apacheとnginxの違いは、「どれだけ速くリクエストを処理できるか」ではなく、同じ量のハードウェア(特にリソースが限られている場合)で処理できるリクエストの数です。

Apacheはプロセスベースのサーバーです。つまり、リクエストごとにプロセスを分岐します。Nginxはイベントベースのサーバーです。つまり、プロセスまたはスレッドの代わりに(非同期)イベントループを使用します。

また、プロセスベースのサーバー(Apacheなど)、たとえば10'0000の同時リクエストなどの重い負荷の下では、非同期イベントベースのサーバー(nginxなど)とほぼ同等に実行できますが、nginxはわずかメガバイトのRAM。ApacheはWebサーバーだけで数百メガバイトを必要とします(Webアプリケーションを含まないため、はるかに多くのリソースを必要とします)。

そのため、負荷が重くなると、Apacheが大量のRAMを消費し、パフォーマンスが驚くほど低下します。

さらに重要なことに、RAMの消費量が多いということは、Apacheが同じハードウェアでnginxよりも少ないリクエストを処理できることを意味します。 nginxよりもApacheを使用すると、ROI(投資収益率)が低下します。

X同時接続で使用される合計メモリ(少ないほど良い)

メモリ使用量

1セットのハードウェア上のX同時接続で1秒あたりに処理できるリクエスト(多いほど良い)

1秒あたりのリクエスト

出典:ApacheBench、dreamhost.com提供

このデジタル海洋文書も参照してください。
どうやら、それはあなたがApache用に選択した接続処理アーキテクチャに依存しています。


6
「...どれだけ速くリクエストを処理できるかではなく、同じ量のハードウェアでどれだけ多くのリクエストを処理できるか...」で頭を釘付けにします。 。まったく同じハードウェアと他の変数のマシンがあり、apacheが200,000しかサービスできないnginxで1日に1,000,000人のユーザーにサービスを提供できる場合、確かにコストの観点から最良の選択はnginxです。特定のハードウェア構成を想定して、nginxがapacheと比較してできることの大きな違いを見ましたか?
blue928

2
現在のリリースであるApache 2.4には、イベントベースのモデルがあります:httpd.apache.org/docs/current/mod/event.html-
グレッグ

1
また、「ものをキャッシュしている限り問題ない」と言っている人にとっては、キャッシュを行うために必要なものを知っていますか?無料のRAMが必要です。
pqnet 14

「Nginxの方がすばらしい」という一般的な主張を頻繁に目にしますが、確かな証拠でこれを裏付ける人はめったにいません。それは常に「高度に設定されたnginxインスタンスが株式Apacheサーバーに勝ったので、他のクールな子供のようにnginxを使用しているのでクールだと証明できました」です。Nginxは、私が知っているすべての人にとって、Apacheよりもはるかに優れているかもしれませんが、それが事実であることを本当に示す人はいません。
レサリオン

@Letharion:完了(dreamhost.comによる)。リクエストに応じて追加。このベンチマーク結果でわかるように、nginxは明らかにメモリ効率が高くなっています。また、おそらく、同じコンピューター上の同じベンチマークで、stock-nginx-instanceがstock-Apache-instanceに勝っています。
困惑

16

数か月前にApacheからNginx / PHP-FPMに切り替えました。

drupal Webサイトでいくつかのベンチマークを作成し、いくつかのユースケースをテストしました。1 CPUおよび512 Mo RAMのVPSサーバー上

キャッシュのみのDrupal

Nginx

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

アパッチ

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

キャッシュとブーストを備えたDrupal

Nginx

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

アパッチ

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

認証されたユーザーのベンチマーク(ページの読み込み)

Nginx

Page load times : 2.85 s

アパッチ

Page load times : 5.4 s

しかし、Nginxのパワーはキャッシュシステムです

キャッシュシステムが有効になっているBoostおよびNginx なしの Drupal

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Drupalにはperusioの構成 Nginxを使用する必要があります


Apacheはどのように実行されていましたか、プリフォーム、FCGIなど?これらのテストを実行したときに、Apache構成は可能な限り最適化されていましたか?まったく同じPHP環境が実行されていましたか?
mpdonadio

PHP(5.3)環境はまったく同じでした。Apacheはmpm_preforkを実行しており、Apacheの設定(maxclient、MaxSpareServers、MaxRequestsPerChildなど)はPHP5-FPMとまったく同じ
でした-flocondetoile

4
これらは良い数値ですが、それらが真の比較であるかどうかはわかりません。Apache + FastCGI vs Apache + FCGI + PHPFPM vs Nginx + PHPFPMは、ApacheとNginxの違いをよりよく示します。
mpdonadio

MPDが指摘しているように、これは真の比較ではありません。真の画像を取得するには、両方でphp-fpmを実行する必要があります。

1
Nginxは、RAMが制限されたVPSアカウントに適していると思います。Apacheよりも小さいRAMフットプリントで快適に動作できるため(特に不要なモジュールをアンインストールしたままにしている場合)、オペコードキャッシュ(APCまたはPHP 5.5の組み込みOpCache)を実行するためのRAMが残っているため、MySQL / Postgresサーバーを提供しますデーモンは大きなバッファであり、レサリオンが正しく指摘する他の最適化も重要です。
ギャレットオルブライト

0

ここで性能試験 10のウェブサーバについては、/ varients(Apacheなど、nginxの、lighttpdの、ライトスピード、ハイアワサ、チェロキー)。3つのテストはDrupalに関連しています。

Hiawathaが全体的な最良の選択かもしれないと思っています。Drupalとの完全な互換性があると仮定すると、セキュリティ(DoS、XSS、CSRF、SQLインジェクション防止)、およびNginxと同様の速度とフットプリントが重視されます。

3つのDrupalテストのうち2つでは、HiawathaとNginxの両方がApacheを約150%上回るが、Drupalの静的テストでは、ApacheはNginxをわずかに上回るが、Hiawathaはパックを約10%上回る。

私はこれらのテストのいずれにも手を掛けませんが、さまざまな使用状況でのパフォーマンスの大まかなビューを提供します。パフォーマンスだけを考慮すべきではないと思います。安定性とセキュリティがより重要な要素になる場合があります。


0

これは、同じハードウェア上で異なるWebサーバーで実行されているdrupalの負荷テスト結果です。(nginxとapache)

このテストの結論は次のとおりです。

同じハードウェアリソースを使用した大量のトラフィックの下では、nginxはapacheよりも優れたパフォーマンスを発揮します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.