2013-02-20 5 views
12

Ich habe seit Tagen suchen, um zu sehen, ob jemand eine gute, dokumentiert, PHP Verarbeitungsgeschwindigkeit Vergleich zwischenPHP Verarbeitungsgeschwindigkeit Apache 2.4 mpm-prefork Mod_php 5.4 vs nginx 1.2.x PHP-FPM 5.4

    getan hat
  • Apache-MPM-prefork 2.4 mit mod_php 5,4

und

  • nginx 1.2.x + PHP-FPM 5,4

Warum ich suche: Der einzige Test, den ich sah, sind Benchmarks, die volle Seiten oder Hello, World-like Test, ohne ordnungsgemäße Dokumentation auf, was genau getestet wurde. Ich interessiere mich nicht für die Anfrage/Sekunden, die Hardware, aber ich muss sehen, was PHP-Skript getestet wurde und mit welcher genauen Konfiguration.

Warum diese zwei: mod_php war bekannt als der schnellste bei der Verarbeitung von PHP (keine statischen Dateien, keine Anfrage/Antwort Messung, nur die Verarbeitung der PHP selbst), aber eine Menge hat sich seitdem geändert, einschließlich Apache-Version. Nginx und PHP-FPM verbrauchen viel weniger Speicher, also wäre es ein guter Grund, die Architektur zu ändern, aber wenn sie in diesem Fall nicht schnell genug sind, wäre die Änderung irrelevant.

Ich weiß, wenn ich nicht in der Lage bin zu finden, ich habe es selbst zu tun, aber ich kann einen Test wie es nicht glauben bisher niemand getan hat :)

+0

"nur die PHP-Verarbeitung selbst" Weder mod_php noch php-fpm verarbeitet PHP selbst. Sie rufen einfach einen eingebetteten Interpreter an, der alle Aufgaben für sie erledigt. Und der PHP-Interpreter ist in beiden Fällen derselbe. – VBart

+0

Nein, es ist nicht oder, genauer gesagt, nicht vollständig. Im ersten Fall ist der Interpreter als ein Modul für Apache aufgebaut, was bedeutet, dass er im Wesentlichen innerhalb von Apache läuft, während der zweite FPM ist, ein FastCGI-Dienst, der eine Zeit lang mit PHP ausgeliefert wurde. Die Antwort enthält jedoch offensichtlich die Kommunikationszeit zwischen nginx und dem FPM-Server, die in diesem Fall Teil der Verarbeitungszeit ist. Sorry, wenn die Frage nicht ganz klar war. – petermolnar

Antwort

12

ich diesen Test auf CentOS 6.3 abgeschlossen haben, mit nginx 1.2.7, apache 2.4.3 und php 5.4.12 alles kompiliert mit keine Änderungen an den Standard.

./configure 
make && make install 

Mit Ausnahme von PHP, wo ich php-fpm

./configure --enable-fpm 

Alle Server haben 100% Standardkonfiguration außer wie unten erwähnt aktiviert. Alle Tests wurden auf einem Testserver ohne Last und einem Neustart zwischen den Tests durchgeführt. Der Server verfügt über einen Intel (R) Xeon (R) Prozessor E3-1230, 1 GB RAM und 2 x 60 GB SSD in RAID 1. Die Tests wurden unter Verwendung laufen ab -n 50000 -c 500 http://127.0.0.1/test.php

Test-PHP-Skript:

<?php 

$testing = 0; 

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

    $testing++; 

} 

echo $testing; 

ich auch musste php in nginx.conf aktivieren, da es nicht standardmäßig aktiviert ist.

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 auf 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 über die Buchse (config Änderung 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) 

Ich werde mehr als glücklich sein zu tunen Apache weiter, aber es scheint, Apache kann einfach nicht mithalten. Der klare Gewinner ist nginx mit php-fpm via Socket.

+1

danke dafür, es ist ziemlich interessant, obwohl es eine Sache gibt, die mich konterkariert: Es gibt Fehlgeschlagene Anfragen mit beiden Nginx-Setups, während dies nicht mit Apache passiert ist. Hast du eine Ahnung warum? – petermolnar

+0

Dies ist der Fehler '[Fehler] 725 # 0: * 200854 connect() zu Unix: /var/lib/php/php.sock ist fehlgeschlagen (11: Ressource vorübergehend nicht verfügbar) während der Verbindung mit dem Upstream, Client: 127.0.0.1, Server: localhost, Anfrage: "GET /test.php HTTP/1.0", upstream: "fastcgi: // unix: /var/lib/php/php.sock:", host: "127.0.0.1" 'immer wieder Bei einer Standardkonfiguration erhalten Sie ein "502 bad gateway", wenn nginx nicht an das Back-End übergeben werden kann oder das Back-End "weggeht". – sjdaws

+0

Sie könnten versuchen, einen Kernel-Parameter, nämlich die net.core.somaconn in sysctl.conf, bis zu 8192 zum Beispiel, das sollte ausreichen, um Fehler wie diese zu erzeugen. – petermolnar

-4

Es scheint, dass Sie Äpfel mit Orangen vergleichen, oder mehr, um es genauer zu sagen, Sie verwirren die Ergebnisse, indem Sie zwei Variablen anpassen. Sicher wäre es sinnvoller Apache + fastcgi + php-fpm gegen nginx + php-fpm zu vergleichen? Sie würden erwarten, dass der php-fpm-Teil derselbe ist, also würden Sie das bessere von Apache_fastcgi vs nginx messen.

+0

Ich brauchte Antworten auf dieses spezielle Szenario, da die Frage für das Unternehmen war, in welche Richtung man sich bewegen sollte. – petermolnar