Apache mpm_prefork と PHP-FPM の効率の違い

by

2021年9月28日

4:05 PM

Apache mpm_prefork と PHP-FPM の効率の違い はコメントを受け付けていません

技術

こんにちは。福岡です。

Apache mpm_prefork + mod_php と mpm_event + PHP-FPM を使ったときの、同時アクセス数が増えたときの効率を調査しましたので紹介します。

WebClass はWebサーバにApacheと、スクリプトに PHP を用いています。同時多数のアクセスを扱うためのチューニングは常に問題です。同時多数のアクセスに立ち向かうため、Apache は今では mpm_event をデフォルトとしていますし、PHP も PHP-FPM を使うことで mpm_event と組み合わせることができます。PHP-FPM も正式機能になって10年経つので、すでに利用されている環境もかなりあると思います。

ネットの記事などを読んで MPM_EventとPHP-FPM が仕組みとして mpm_prefork より効率が良さそうだというのはわかっていたのですが、定量的にどこがどれくらい良いのか、いまいちしっくりくる説明を見たことがありませんでした。なので、今更かもしれませんが、測ってみました。

ここでは具体的に、以下について調査しました。

  • 同じ同時アクセスを受けた時、mpm_prefork とくらべて、PHP-FPM はどれくらい効率的に、もしくは安定してリクエストを処理できるか
  • プロセスの立ち上げ速度に差はあるか

結果は以下でした。

  • 用意したPHPのプロセス数よりも多くの同時アクセスを受けている時には PHP-FPM のほうがレスポンスタイムを1/2倍にするくらい効率が良いことが分かりました。
  • プロセスを立ち上げる速度は Kernel や CPU 等の影響が大きく差がありませんでしたが、一気に同時アクセスを受けてからプロセスを立ち上げ始める初動では PHP-FPM のほうが良い動きでした。

ベンチマークに使う PHP プログラム

ベンチマークコマンドは以下のようにして単一URLに ab コマンドで同時アクセスをかけ、レスポンス時間を確認しました。

ab -c 300 -n 1000 http://10.0.0.104/webclass/wait1.php

アクセス先PHPプログラム wait1.php は、１±0.25 [s] だけ待って 'OK' の文字を返します。想定として、プログラムファイルはキャッシュメモリ上に乗っていてIO負荷が殆どかからない、PHPのスクリプトとしても処理はDBサーバからの結果を待つだけでほとんどやることがない状況を想定しています。

<?php
function msleep($milliseconds) {
    return usleep($milliseconds * 1000); 
}
$interval = 1000;
$var = 500; 
msleep(1000 + (rand(0, $var)-$var/2));

echo 'OK';

したがって、スクリプトの処理時間はCPUの負荷状況に影響を受けにくく、CPUが空いていても1秒より早く応答は返さないし、CPUに多少負荷がかかっていてもスクリプトの処理自体はあまり時間が延びません。

このプログラムに対するアクセスのレスポンス時間を計測し、どれだけ１ｓから離れるかを比較することで、Apache と PHP-FPM の効率だけを比較・評価できると考えました。

計測環境

AWS EC2 インスタンス(m4.large) でDebian 10 + WebClass 11.11.3 を構築しました。

  • CPU Intel® Xeon CPU E5-2686 v4 @ 2.30GHz x2
  • Mem 8G + Swap File 3G
  • Debian 10.9
    • Apache 2.4.38 (Debian)
    • PHP 7.3.29-1~deb10u1

同一VPC内に m4.large のDebian10インスタンスを構築し、http プロトコルで ab コマンドによるベンチマークを計測しました。

  • CPU Intel® Xeon CPU E5-2686 v4 @ 2.30GHz x2
  • Mem 8G
  • Debian 10.9
  • Ab 2.3 Rev.1843412

計測中にはどちらのサーバでも Swap と Hardware Interrupt(Steal)が発生しないのを確認してあります。

計測環境チェック

wait1.php はほぼ待つだけなので、同時アクセスが多数発生してもCPUはあまり消費せず、ApacheとPHPの同時アクセス・複数プロセスのマネジメントの効率が良いほど応答時間は１ｓに近づくはず、という前提を確認します。

この前提条件の確認のため、mpm_prefork とphp7.3-fpm のそれぞれについて、300 プロセス用意した状態で100同時アクセスをかけて応答時間が１ｓ程度になることをチェックしておきました。

ab -c 100 -n  10000 http://10.0.0.104/webclass/wait1.php

MPM_Prefork + Mod_php 7.3 (MaxRequestWorkers=300 ) の結果

Mpm_prefork のケースでは、Apache のMPM設定は以下のようにしました。

StartServers   300
MinSpareServers 300
MaxSpareServers 300
MaxRequestWorkers 300
ServerLimit    300

abコマンドの結果は以下です。

Concurrency Level:      100
Time taken for tests:   101.782 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2260000 bytes
HTML transferred:       20000 bytes
Requests per second:    98.25 [#/sec] (mean)
Time per request:       1017.816 [ms] (mean)
Time per request:       10.178 [ms] (mean, across all concurrent requests)
Transfer rate:          21.68 [Kbytes/sec] received

応答時間が１ｓで、CPU負荷もほとんどかからなかったため、問題なさそうです。

MPM_event + php7.3-fpm (max_children=300 ) の結果

Mpm_event のケースでは、Apache のMPM設定は以下のようにしました。スレッドを100ずつ増やしていき、上限も2000にしてあるので、プロセスの起動とスレッド上限があまり影響しないようにしています。

StartServers      2
MinSpareServers 100
MaxSpareServers 100
ThreadLimit        300
ThreadsPerChild  100
MaxRequestWorkers 2000

PHP-FPM のプロセスモードは以下の設定です。

pm = dynamic
pm.max_children = 300
pm.start_servers = 50
pm.min_spare_servers = 20
pm.max_spare_serves = 50

なお、この設定は Prefork に揃えるには static にすればよかったと後で気づきました。

abコマンドの結果は以下です。

Concurrency Level:      100
Time taken for tests:   103.935 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      2300000 bytes
HTML transferred:       20000 bytes
Requests per second:    96.21 [#/sec] (mean)
Time per request:       1039.351 [ms] (mean)
Time per request:       10.394 [ms] (mean, across all concurrent requests)
Transfer rate:          21.61 [Kbytes/sec] received

dynamic/static の点は気になりますが、一応は応答時間が１ｓで、CPU負荷もほとんどかからなかったため、問題なさそうです。

レスポンス時間の計測結果

Prefork と PHP-FPM のワーカ数上限と、同時アクセス数を変えながら ab コマンドでレスポンス時間をプロットしたのが以下です。

グラフの凡例の名前「Prefork」もしくは「PHP-FPM」の横に書いた数字が、それぞれに設定したワーカーの上限です。

ｗait1.php は1±0.25s 待つだけなので、同時アクセスが多数発生しても CPU に掛かる負荷はわずかでした。ですので、MPM と PHP-FPM の効率がレスポンスタイム１ｓよりどれくらい上に離れてくか、に反映されると考えられます。１ｓでフラットなグラフになるほど、同時アクセスが増えても効率が落ちないことを意味します。

MPM_Prefork は、用意したプロセス未満の同時アクセスに対しては非常に効率が良いです。しかし、プロセス数を超える同時アクセスに対しては、著しく効率が悪化し、ab はエラーを計上することもありました。MaxRequestWorkers 900 で同時アクセス1500のケースでもCPUの利用時間は大して増えませんが、Load Average は 9.3 ほどになりました。エラーを計上したところより上の同時アクセス数はデータを取っていません。

PHP-FPM はプロセス数未満の同時アクセスに対して効率が良いのはMPM_Preforkと変わりません。一方、同時アクセス数がプロセス数よりも増えた時は、MPM_Prefork よりもレスポンス時間を1/2 程度に保てました。Load Averageは１いくか行かないか程度で、CPU使用率は低いままです。

プロセス数が足りない方に寄った計測をしているため、どちらの方式でもプロセス数を増やすことによる効率の悪化の様子は観察できませんでした。ただし、実際の運用ではプロセス数が増えるとスクリプトによるCPU利用量も増えるため、プロセス管理の効率の問題以前にCPUがボトルネックになることも考えられます。

プロセスの立ち上がり速度の計測

MPM_Prefork も PHP-FPM もワーカとしてプロセスを立ち上げます。一般にプロセスのフォークは重い処理になります。また、待機しているワーカ数よりも多くの同時アクセスがワッと来た時の反応にも影響します。WebClassですと、10時半から2限では試験をします！というとき、授業の開始時刻で一斉に学生が操作し始めるので侮れないパラメータになります。

２つの環境のそれぞれに、ワーカの最大値を５００に、初期待機ワーカ数を５０にした状態で待機させ、ab コマンドで同時５００アクセスをかけました。そこからプロセス数を１秒単位で数えていって、５００に達したところまでをグラフにしています。

グラフの凡例の名前「PHP-FPM」の横に書いた数字は min_spaire_servers の値です。最初は１０にして計測したところ著しくプロセス起動が遅かったので、５０の結果を加えてPreforkと比べられるようにしています。なお、これ以上値を増やしても、もしくは同時アクセス数を増やしても、速度は変わりませんでした。

プロセスの立ち上げ速度（グラフの傾き）は MPM_PreforkとPHP-FPM50で差がありません。これは Kernel や CPU などのもっと下のレイヤーの性能によるものと思います。ですが、同時アクセスが急にきてからプロセスを増やし始める反応はPHP−FPMのほうが良く、５００プロセス揃うまでの時間に３ｓの差が出ました。その結果、平均応答時間は初動の速いPHP-FPM のほうが短くなりました。

CPUへの負荷を見ると、MPM_Prefork はプロセス上限に至るまでは CPU も Load Averageも低いままですが、PHP-FPM のほうはCPU使用率と Load Average が Prefork よりも高くなりました。もしPHPにそれなりの処理が有る時、PHP-FPMのプロセスの立ち上げにどれくらい影響するかちょっと気になります。

まとめ

まずは基本的なところの違いを知りたいと思って、できるだけプロセス管理効率に的を絞った計測をしてみました。

MPM_Event については、PHP-FPMの計測でほぼ無視できるほどサクサクと１５００同時リクエストなどを抱えてくれていて、数字では示せませんでしたが流石だなと思いました。そのおかげで、PHP-FPM はワーカ数を絞っていても効率的に処理できるようになっていると思います。PHPのプロセス数を絞ることができれば、接続先のDBのワーカ数も減らすことができます。コア数とメモリが限られる環境での安定性に繋がります。また、この安定性を保ったまま、CPU とメモリを増やした分だけワーカ数を増やしていければ、１台のプロセッサでカバーできる同時アクセス数も増やしやすいかもしれません。このあたり、今後詰めていきたいところです。