さて、あなたが正しい答えを見つける前に-サーバーとテストメカニズムについて少し。
VDSを「ねじる」疑いを排除するために、この構成のフォーラム参加者の1人からテストのために親切に提供されたサードパーティサーバーでテストを実行しました。
AMD Athlon X2 5600+ 4 GB DDR2 2 x 400 GB HDD 、Linux Debian、最小インストール。 すべてのソフトウェアは、apt-getを介して標準的な方法でインストールされました。 PHPとApacheは両方とも最小モードに設定されていました。
テストオブジェクト用に、MySQLなしで動作する非常に軽量なMoscquitoブログを設定し、そこにいくつかの投稿とコメントを書き込みます。
まず、NginxとApacheのベンチマークを開始する前に、サーバーを再起動したことを伝えたいと思います。 ネットワークサブシステムは、操作を高速化するために少し工夫されています。
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
sysctl -w sysctl net.ipv4.tcp_window_scaling=1
sysctl -w sysctl net.ipv4.tcp_timestamps=1
sysctl -w sysctl net.ipv4.tcp_sack=1
sysctl -w net.ipv4.tcp_no_metrics_save=1
sysctl -w net.ipv4.tcp_moderate_rcvbuf=1
sysctl -w net.core.netdev_max_backlog=1000
sysctl -w net.ipv4.tcp_congestion_control=htcp
sysctl -w net.core.somaxconn=1000
ifconfig eth0 txqueuelen 1000
そして、テストされたベンチマークとベンチマーク自体の正しい作業の制限が増加しました。
ulimit -s unlimited
ulimit -n 1024000
両方のWebサーバーで、300秒のタイムアウトが設定されました（Apacheの標準、Nginxではそれよりも短い）。
PHP-FPM
プロセスはTCPソケットに関連付けられ、4つのプロセスからなる2つのプールがそれぞれ静的モードで作成されました。
nginx
それぞれ10240の接続を持つ2つのワーカー。phpはアップストリームとして接続されます。
upstream php {
server 127.0.0.1:9000 max_fails=1 fail_timeout=60s;
server 127.0.0.1:9001 max_fails=1 fail_timeout=60s;
}
アパッチ
キープアライブは無効で、MaxClientsとServerLimitは10240に設定されています
ベンチマークについて
20万個のボットがメインページに侵入し、5,000人の合法的なユーザーがサイトにアクセスするときに、DDOS攻撃の下でWebサイトの状況を作成しようとしました。
即興のDDOS攻撃はabで簡単に可能です。 しかし、ユーザーの場合、サイトマップを生成し、それを包囲する必要がありました。
テストには1時間かかり、abを使用してサイトの可用性レコードが記録されました。 以下は、画面で並行して実行した2つのコマンドです。
while true; do ab -r -t 300 -n 20000 -c 20000 213.239.211.15 >> nginx.log; sleep 5; done
while true; do siege -i -f urllist.txt -c 5000 -b -t1M ; sleep 5; done
当然、Apacheベンチマークでは、ログはapache.logに書き込まれました
チャートに移りましょう
ご覧のように、プロセスの数はApacheの操作中にのみ変更されます。MPMPreforkと呼ばれる理由もあります。 NginxとPHP-FPMは静的であり、大きなプラスです。
残念ながら、メモリグラフはあまり美しくありませんが、注意深く見ると、Apacheはより多くのメモリを消費しています。
プロセスとフォークの切り替えのグラフは、互いに非常に興味深い相関があります。
CPU使用率のレイアウトも明らかにApacheを支持していません。
ログを突破します
Nginx：
＃grep -c nginx.logに失敗しました 38 ＃grep Failed nginx.log | grep -v '失敗したリクエスト：0' 失敗したリクエスト：10629
復号化-1時間の操作で、Nginx + PHP-FPMバンドルは38回の反復を実行し、そのうち1回-10629回の誤った要求を埋めることができました。 これは、アップストリームにアクセスできないためでした-メインページへのリクエストのほとんどを実行することで包囲が試みられました。
Apache：
＃grep -c失敗したapache.log 23 ＃grep Failed apache.log | grep -v '失敗したリクエスト：0' 失敗したリクエスト：8730 失敗したリクエスト：2124 失敗したリクエスト：10539 失敗したリクエスト：7599 失敗したリクエスト：6027 失敗したリクエスト：1986 失敗したリクエスト：7578 失敗したリクエスト：270 失敗したリクエスト：9819 失敗したリクエスト：60 失敗したリクエスト：9369 失敗したリクエスト：8193 失敗したリクエスト：10248 失敗したリクエスト：684 失敗したリクエスト：7968
しかし、Apacheの場合、すべてが悪いです。たとえ「成功」した2回の包囲攻撃を取り消しても、エラーがあり、割り当てられた時間内に完了したリクエストが少なくなります。
したがって、テスト結果によると、Nginx + PHP-FPMバンドルは、38：23のスコアでApacheを破ります