2013-02-20 13 views
12

Ho cercato per giorni per vedere se qualcuno ha fatto un buon, documentato, il confronto tra la velocità di elaborazione PHPPHP apache velocità di elaborazione 2.4 mpm-prefork mod_php 5.4 vs nginx 1.2.x PHP-FPM 5.4

  • apache-mpm-prefork 2.4 con mod_php 5,4

e

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

Perché sto cercando: L'unico test che ho visto sono parametri di riferimento, che servono pagine complete o Hello, World-like test, senza una documentazione adeguata su ciò che è stato testato. Non mi interessa la richiesta/secondi, l'hardware, ma ho bisogno di vedere quale script PHP è stato testato e con quale configurazione esatta.

Perché questi due: mod_php era noto per essere il più veloce sul trattamento PHP (nessun file statici, nessuna misura richiesta/risposta, solo l'elaborazione del PHP stesso), ma molto è cambiato da allora, tra cui la versione di Apache. Nginx e PHP-FPM consumano molta meno memoria, quindi sarebbe un buon motivo per cambiare architettura, ma se non sono abbastanza veloci in questo caso, la modifica sarebbe irrilevante.

lo so se sono in grado di trovare uno che devo farlo io, ma non posso credere che nessuno ha fatto un test come questo finora :)

+0

"solo l'elaborazione del PHP stesso" Né mod_php né php-fpm esegue l'elaborazione php. Chiamano solo un interprete di embed che fa tutto il lavoro per loro. E l'interprete PHP è lo stesso in entrambi i casi. – VBart

+0

No, non è, o, più precisamente, non interamente. Nel primo caso l'interprete è costruito come un modulo per apache, il che significa che è fondamentalmente eseguito all'interno di apache, come parte di esso, mentre il secondo è FPM, che è un servizio FastCGI che è stato fornito con PHP per un po '. Tuttavia la risposta includerà ovviamente il tempo di comunicazione tra nginx e il server FPM, che, in questo caso, è parte del tempo di elaborazione. Scusa se la domanda non è stata del tutto chiara. – petermolnar

risposta

12

ho completato questo test su CentOS 6.3 utilizzando nginx 1.2.7, apache 2.4.3 e php 5.4.12 tutto compilato senza modifiche ai valori predefiniti.

./configure 
make && make install 

Con l'eccezione di php dove ho attivato php-fpm

./configure --enable-fpm 

Tutti i server hanno il 100% di configurazione di default ad eccezione di quanto indicato di seguito. Tutti i test sono stati eseguiti su un server di prova, senza carico e riavvio tra i test. Il server ha una (R) Xeon (R) CPU Intel E3-1230, 1GB di RAM e 2 x 60GB SSD in RAID 1. I test sono stati eseguiti utilizzando 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; 

anche io dovuto abilitare php in nginx.conf in quanto non è abilitato di 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 su 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 tramite presa (cambiamento di configurazione per 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) 

Sarò più che felice di sintonizzare apache ulteriormente, ma sembra che Apache non riesca a tenere il passo. Il chiaro vincitore è nginx con php-fpm via socket.

+1

grazie per questo, è abbastanza interessante, anche se c'è una cosa che mi preoccupa: ci sono richieste non riuscite con entrambe le configurazioni di nginx mentre questo non è successo con apache. Hai qualche idea del perché? – petermolnar

+0

Questo è l'errore '[errore] 725 # 0: * 200854 connect() per unix: /var/lib/php/php.sock non riuscito (11: risorsa temporaneamente non disponibile) durante la connessione a upstream, client: 127.0.0.1, server: localhost, richiesta: "GET /test.php HTTP/1.0", a monte: "fastcgi: // unix: /var/lib/php/php.sock:", host: "127.0.0.1" 'ogni tanto , in una configurazione standard riceverai un '502 gateway non valido 'quando nginx non può passare al back-end, o il back-end' se ne va '. – sjdaws

+0

si potrebbe provare a rasare un parametro del kernel, ovvero net.core.somaxconn in sysctl.conf, ad esempio fino a 8192, che dovrebbe essere sufficiente a non generare un errore come questo. – petermolnar

-4

Sembra che tu stia confrontando mele con arance, o più per dirla in modo più preciso, stai confondendo i risultati regolando due variabili. Sicuramente sarebbe più sensato confrontare Apache + fastcgi + php-fpm con nginx + php-fpm? Ti aspetteresti che la parte di php-fpm fosse la stessa, quindi dovresti misurare la migliore su Apache_fastcgi vs nginx.

+0

Avevo bisogno di risposte a questo specifico scenario poiché la domanda per la società era decidere in quale direzione andare. – petermolnar

Problemi correlati