PHP processing speed apache 2.4 mpm-prefork mod_php 5.4 vs nginx 1.2.x PHP-FPM 5.4

Question

I've been looking for days to see if someone has done a good, documented, PHP processing speed comparison between

• apache-mpm-prefork 2.4 with mod_php 5.4

and

• nginx 1.2.x + PHP-FPM 5.4

Why I'm looking: The only test I saw are abount benchmarks, serving full pages or Hello, World -like test, without proper documentation on what exactly was tested. I don't care about the request/seconds, the hardware, but I do need to see what PHP script was tested and with what exact configuration.

Why these two: mod_php was known to be the fastest on processing PHP ( no static files, no request/response measuring, just processing the PHP itself ) but a lot has changed since then, including apache version. Nginx and PHP-FPM eats a lot less memory, so it'd be a good reason to change architecture but if they're not fast enough in this case, the change would be irrelevant.

I know if I'm unable to find one I have to do it myself but I can't believe no one has done a test like this so far :)

Housebreaking

"just processing the PHP itself" Neither mod_php nor php-fpm does php processing itself. They just call an embed interpreter that does all job for them. And the php interpreter is the same in both cases. – Freeness

No, it's not, or, more precisely, not entirely. In the first case the interpreter is built as a module for apache, meaning it's basically running inside apache, as a part of it, while the second is FPM, which is a FastCGI service that's been shipped with PHP for a while. However the answer will obviously include the communication time between nginx and the FPM server, which, in this case is part of the processing time. Sorry if the question was not entirely clear. – Housebreaking

Answer 1

I have completed this test on CentOS 6.3 using nginx 1.2.7, apache 2.4.3 and php 5.4.12 all compiled with no changes to default.

./configure
make && make install

With the exception of php where I enabled php-fpm

./configure --enable-fpm

All servers have 100% default config except as noted below. All testing was done on a test server, with no load and a reboot between tests. The server has a Intel(R) Xeon(R) CPU E3-1230, 1GB RAM and 2 x 60GB SSD in RAID 1. Tests were run using ab -n 50000 -c 500 http://127.0.0.1/test.php

Test PHP script:

<?php

$testing = 0;

for ($i = 0; $i < 1000; $i++) {

    $testing++;

}

echo $testing;

I also had to enable php in nginx.conf as it's not enabled by default.

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    include        fastcgi_params;
}

Nginx - PHP-FPM on 127.0.0.1:9000

Concurrency Level:      500
Time taken for tests:   10.932 seconds
Complete requests:      50000
Failed requests:        336
   (Connect: 0, Receive: 0, Length: 336, Exceptions: 0)
Write errors:           0
Non-2xx responses:      336
Total transferred:      7837824 bytes
HTML transferred:       379088 bytes
Requests per second:    4573.83 [#/sec] (mean)
Time per request:       109.317 [ms] (mean)
Time per request:       0.219 [ms] (mean, across all concurrent requests)
Transfer rate:          700.17 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   34 338.5      0    7000
Processing:     0   34 166.5     23    8120
Waiting:        0   34 166.5     23    8120
Total:         13   68 409.2     23    9846

Percentage of the requests served within a certain time (ms)
  50%     23
  66%     28
  75%     32
  80%     33
  90%     34
  95%     46
  98%     61
  99%   1030
 100%   9846 (longest request)

Nginx - PHP-FPM via socket (config change to fastcgi_pass)

fastcgi_pass   unix:/var/lib/php/php.sock;

Concurrency Level:      500
Time taken for tests:   7.054 seconds
Complete requests:      50000
Failed requests:        351
   (Connect: 0, Receive: 0, Length: 351, Exceptions: 0)
Write errors:           0
Non-2xx responses:      351
Total transferred:      7846209 bytes
HTML transferred:       387083 bytes
Requests per second:    7087.70 [#/sec] (mean)
Time per request:       70.545 [ms] (mean)
Time per request:       0.141 [ms] (mean, across all concurrent requests)
Transfer rate:          1086.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   26 252.5      0    7001
Processing:     0   24 112.9     17    3683
Waiting:        0   24 112.9     17    3683
Total:          7   50 306.4     17    7001

Percentage of the requests served within a certain time (ms)
  50%     17
  66%     19
  75%     20
  80%     21
  90%     23
  95%     31
  98%     55
  99%   1019
 100%   7001 (longest request)

Apache - mod_php

Concurrency Level:      500
Time taken for tests:   10.979 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Total transferred:      9800000 bytes
HTML transferred:       200000 bytes
Requests per second:    4554.02 [#/sec] (mean)
Time per request:       109.793 [ms] (mean)
Time per request:       0.220 [ms] (mean, across all concurrent requests)
Transfer rate:          871.67 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   22 230.2      1    7006
Processing:     0   58 426.0     18    9612
Waiting:        0   58 425.9     18    9611
Total:          5   80 523.8     19   10613

Percentage of the requests served within a certain time (ms)
  50%     19
  66%     23
  75%     25
  80%     26
  90%     31
  95%     36
  98%   1012
  99%   1889
 100%  10613 (longest request)

I'll be more than happy to tune apache further, but it seems apache just can't keep up. The clear winner is nginx with php-fpm via socket.

Bezel

thanks for this, it's quite interesting, although there's a thing that conserns me: there are Failed requests with both nginx setups while this does not happened with apache. Do you have any idea why? – Housebreaking

This is the error [error] 725#0: *200854 connect() to unix:/var/lib/php/php.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.0", upstream: "fastcgi://unix:/var/lib/php/php.sock:", host: "127.0.0.1" every so often, on a standard configuration you will receive a 502 bad gateway when nginx can't pass to the back end, or the back end 'goes away'. – Bezel

you could try rasing a kernel param, namely the net.core.somaxconn in sysctl.conf, up to 8192 for example, that should be enough not to generate error like this. – Housebreaking

Setting pm.max_requests to something other than unlimited may also help solve the problem. – Bezel

apache with mpm_prefork with 0 request failed interest me much more than a turbo server with (n+1) possible request failed. – Undesirable

Answer 2

It seems you are comparing apples with oranges, or more to put it more accurately, you are confounding the results by adjusting two variables. Surely, it would be more sensible to compare Apache+fastcgi+php-fpm against nginx+php-fpm? You'd expect the php-fpm part to be the same, so then you would be measuring the better of Apache_fastcgi vs nginx.

Alopecia

I needed answers to this specific scenario since the question for the company was to decide which direction to move to. – Housebreaking