Nginx vs Apache - Existe-t-il des statistiques d'utilisation et de comparaison réelles?

J'ai un nouveau serveur pour jouer, et je regarde une toile vierge. Je peux mettre tout ce que je veux dessus. Bien que je sois à l'aise avec Apache, j'entends beaucoup dire que nginx peut gérer beaucoup plus de trafic qu'Apache, avec des facteurs de 10, 100, voire plus. Non seulement c'est "beaucoup beaucoup plus rapide".

Lorsque je recherche des articles, je peux trouver beaucoup de choses sans lien avec Drupal. Ou, quand je rencontre un article lié à Drupal, c'est soit 1) le fichier de configuration de quelqu'un avec une tentative rapide pour expliquer comment le configurer, soit 2) c'est quelqu'un qui dit "non, n'utilisez pas nginx, utilisez Apache avec PHP fcgid "mais il n'y a jamais d'explication quant à pourquoi.

Donc, en ce qui concerne Drupal, quelle est la réalité ici?

Par exemple, je cherche quelque chose dans les lignes de cet article de 2bits.com . Ici, l'auteur a jeté un regard assez approfondi sur Apache mod_php vs Apache avec fcgid, en soupesant le pour et le contre de chacun, et a fourni une étude de cas pour illustrer l'impact dans le monde réel. Cet article contient suffisamment d'informations pour que je puisse prendre une décision éclairée quant à l'approche la mieux adaptée à ma situation.

Tandis que cet auteur compare mod_php à fcgid, je recherche le même type de regard complet et réaliste sur Apache vs Nginx.

N'importe qui est passé à Nginx et a été "époustouflé" par la différence qu'il fait par rapport à Apache? Même pour les environnements hautement optimisés qui utilisent déjà APC, Memcache et la mise en cache agressive comme Varnish, lorsque la seule variable qui change, remplace Apache par Nginx, fait suffisamment de différence en soi pour justifier des investissements dans cette nouvelle technologie alternative. ?

Le site qui ira sur ce serveur reçoit en moyenne 2 millions de VP par mois. Pile LAMP sous Cent OS 6. CPU à 4 cœurs avec 8 GIGS de RAM. Memcached et APC feront partie du mélange. Rien d’exceptionnel à propos de l’installation de Drupal - en gros vanilla 7 avec environ 50 modules.

Strictement parlant, cela ne répond pas à la question que vous posez. J'espère que c'est utile quand même.

Apache / Nginx / Lighttpd / autre serveur Web. Est-ce que c'est celui que je choisis? En bref, non .

La réponse beaucoup plus longue:

Si et seulement si, vous avez un très grand pourcentage d’utilisateurs connectés, si vous vous souciez de la performance de votre serveur Web. Si vos utilisateurs sont anonymes, toute différence que vous pouvez théoriquement tirer de l'optimisation au niveau de ces couches est tout à fait irréprochable par rapport à une meilleure mise en cache de vos ressources. Si vos fichiers CSS ont des en-têtes de cache appropriés, l'UA ne les demandera même pas une seconde fois. C'est important. Si vous pouvez mettre en cache vos pages dans Varnish ou dans une solution logicielle similaire, vous devez afficher cette page en effectuant une recherche par hachage, puis en renvoyant une grande quantité de données directement à partir de la RAM. C'est important. Dans ces deux scénarios, le démon HTTP n'est jamais impliqué, PHP n'est pas invoqué. Drupal ne pas bootstrap. Aucun ensemble important de modules ne doit être chargé dans la RAM, aucune requête fastidieuse de la base de données n'est exécutée.

Lorsque vous effectuez un chargement complet de la page, à partir d'un cache froid, pour un utilisateur connecté, sur une page complexe; beaucoup de choses se passent. Oui, le serveur Web est impliqué dans le traitement de la demande entrante, la définition de certains en-têtes et le renvoi de la réponse. Mais le temps que cela prend n'est même pas pertinent dans le contexte où Drupal exécute un bootstrap complet et affiche sa réponse. Des centaines de requêtes de base de données pourraient être exécutées. La logique très complexe en PHP est évaluée par l'analyseur. Beaucoup de modules sont en cours de chargement dans la RAM. L’amélioration de la performance de l’une de ces choses est beaucoup plus susceptible d’apporter une contribution sérieuse à la performance.

Par souci d'argumentation: Disons que vous avez passé beaucoup de temps à optimiser vos performances.

1. Vous exécutez APC (Ou Optimizer + ) et la version la plus récente et la plus rapide de PHP.
2. Les requêtes DB sont peu nombreuses.
3. La logique PHP a été réduite.
4. Vous cachez ce que vous pouvez dans Varnish.
5. Vous avez restructuré l'ensemble de votre site afin de pouvoir mettre en cache beaucoup de clients et de faire beaucoup d'efforts dans ECMAScript .

Si vous avez beaucoup d'utilisateurs connectés et que vous avez résolu tous les problèmes ci-dessus, vous pouvez probablement faire la différence en réglant les performances ou en remplaçant votre serveur Web. Cependant, devinez quoi. Votre site est si complexe et les habitudes d'utilisation de vos utilisateurs sont uniques . Il n'y a pas de réponse générique. Vous devrez configurer tous les serveurs Web différents derrière un équilibreur de charge et voir comment ils se comportent, dans votre scénario .

Ce qui précède était une tentative logique de parvenir à la conclusion que l'optimisation du serveur Web par la performance de gestion du temps représente probablement une mauvaise utilisation du temps. J'aimerais bien que quelqu'un trouve des trous dans ce qui précède, j'apprendrais probablement quelque chose de nouveau grâce à cela. :)

Quelques autres notes:

1. Lors de la conférence DrupalCon à Copenhague , le créateur de PHP, Rasmus Lerdorf , utilisant Nginx lui-même, s'exprimant sur le thème des performances Drupal, a déclaré: "Les gens me posent toujours des questions sur les serveurs Web ... cela n'a pas d'importance, le serveur Web n'est pas pertinent" . (Environ à 26h30 dans la vidéo)
2. Facebook a passé d'innombrables heures à écrire Hiphop , une base de code bien plus grande que Drupal, pour accélérer le code PHP de 100%. J'ai examiné Hiphop avec $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1et j'ai trouvé qu'il consistait en 1.512.481 lignes de code. Cela représente un travail absolument insensé pour améliorer la vitesse de PHP. J'imagine que c'est parce que la vitesse de PHP compte beaucoup pour eux.
3. Ai-je mentionné qu'une bonne mise en cache aura un effet beaucoup plus important que le réglage du serveur Web?
4. Avec la sortie d'Apache 2.4, Jim Jagielski affirme essentiellement qu'Apache 2.4 est plus rapide que les serveurs basés sur des événements .
5. J'ai abordé Drupal Performance et l'évolutivité avec The Dream Team , où cette question a été posée. Toutes les réponses à choisir n'étaient pas liées à la performance. Des choses comme "Lequel savez-vous déjà configurer", et "Lequel vous permettra de construire la pile technologique la plus simple", étaient parmi les raisons évoquées. La performance n'est pas entrée dans l'image.

OK, même si cette question a déjà trouvé une réponse, je nécromancie encore une fois, principalement parce que je n'aime pas les implications de ces réponses sur le fait que cela ne fait aucune différence, et parce qu'en tant que développeur web, je déteste mettre en cache la cache. .

La différence entre Apache et nginx n’est pas tant «la rapidité avec laquelle ils peuvent répondre à une demande», mais le nombre de demandes qu’ils peuvent traiter avec la même quantité de matériel (en particulier avec des ressources limitées), ce qui est quelque peu différent.

Apache est un serveur basé sur des processus. Cela signifie un processus pour chaque demande. Nginx est un serveur basé sur des événements, ce qui signifie qu’il utilise une boucle d’événement (asynchrone) au lieu de processus ou de threads.

Et même si un serveur basé sur des processus (comme Apache) peut fonctionner plus ou moins à égalité avec un serveur basé sur des événements asynchrones (tel que nginx) sous de faibles charges, sous des charges plus lourdes, comme par exemple 10 000 requêtes simultanées, nginx n'utilise que quelques mégaoctets de RAM, alors qu'Apache nécessite plusieurs centaines de mégaoctets pour le serveur Web uniquement (sans compter l'application Web, qui nécessite beaucoup plus de ressources), si cela est possible.

Ainsi, sous des charges plus lourdes, vous constaterez qu'Apache consomme beaucoup trop de RAM, ce qui, sans surprise, dégrade considérablement les performances.

Plus important encore, une consommation de mémoire vive plus élevée signifie qu’Apache est en mesure de traiter moins de demandes sur le même matériel que nginx, ce qui signifie qu’Apache nécessite plus de matériel pour le même nombre d’utilisateurs, ce qui signifie que votre coût total de possession est plus élevé. avec Apache qu'avec nginx, ce qui réduit votre retour sur investissement.

Mémoire totale utilisée par X connexions simultanées (moins c'est mieux)

Demandes pouvant être servies par seconde lors de X connexions simultanées sur 1 ensemble de matériel (plus c'est mieux)

Source: ApacheBench, par dreamhost.com

Voir aussi cette description numérique de l'océan .
Apparemment, cela dépend de l’architecture de gestion de la connexion choisie pour Apache.

Je suis passé d’Apache à Nginx / PHP-FPM il ya quelques mois.

J'ai fait quelques tests avec un site web Drupal, et testé plusieurs cas d'utilisation. Sur un serveur VPS avec 1 CPU et 512 Mo de RAM

Drupal avec seulement cache

Nginx

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

Apache

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Drupal avec cache et boost

Nginx

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Apache

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

référence pour l'utilisateur authentifié (chargement de page)

Nginx

Page load times : 2.85 s

Apache

Page load times : 5.4 s

Mais la puissance de Nginx est le système de cache

Drupal sans Boost et Nginx avec système de cache activé

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Vous devez utiliser la configuration de Perusio Nginx pour Drupal

Voici un test de performance de dix serveurs Web / variantes (par exemple, Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Trois des tests concernent Drupal.

Je pense que Hiawatha peut être le meilleur choix global. Censé avoir une compatibilité totale avec Drupal , met l'accent sur la sécurité (prévention du DoS, XSS, CSRF, prévention d'injection SQL), ainsi que des vitesses et une empreinte similaires à celles de Nginx.

Dans deux des trois tests Drupal, Hiawatha et Nginx surpassent Apache d'environ 150%, mais dans le test statique Drupal, Apache surpasse légèrement Nginx, tandis que Hiawatha dépasse le groupe d'environ 10%.

Je n'accepterai aucun de ces tests, mais cela donne un aperçu approximatif des performances dans différentes situations d'utilisation. Je pense que la performance seule ne devrait pas être la seule considération. La stabilité et la sécurité peuvent être les facteurs les plus importants.

ici est un test de charge résultats pour le fonctionnement même drupal matériel , mais avec des serveurs Web différents. (nginx et apache)

voici la conclusion de ce test:

sous un trafic important avec les mêmes ressources matérielles, nginx est bien meilleur qu'apache.