Nginx vs Apache - Existe-t-il des comparaisons et des statistiques d'utilisation réelles?
J'ai un nouveau serveur avec lequel jouer et je regarde une toile vierge. Je peux y mettre tout ce que je veux. Bien que je sois à l'aise avec Apache, j'entends toujours comment nginx peut gérer beaucoup plus de trafic qu'Apache, par des facteurs de 10, 100, voire plus. Non seulement c'est "beaucoup plus rapide".
Lorsque je recherche des articles, je peux trouver beaucoup de choses sans rapport avec Drupal. Ou, lorsque je rencontre un Drupal c'est soit 1) le fichier de configuration de quelqu'un avec une tentative rapide d'expliquer comment le configurer, ou 2) c'est quelqu'un qui dit "non, ne pas" t utiliser nginx, aller avec Apache avec PHP fcgid "mais il n'y a jamais d'explication pour savoir pourquoi.
Alors, quand il s'agit de Drupal, quelle est la réalité ici?
Par exemple, je cherche quelque chose dans le sens de cet article 2bits.com . Ici, l'auteur a jeté un regard assez complet sur Apache mod_php vs Apache avec fcgid, en pesant les avantages et les inconvénients de chacun, et a fourni une étude de cas pour illustrer l'impact dans le monde réel. Il y a suffisamment d'informations dans cet article pour que je puisse prendre une décision éclairée quant à l'approche qui conviendrait le mieux à ma situation.
Bien que cet auteur compare mod_php à fcgid, je recherche le même type de regard complet et réel sur Apache vs Nginx.
Quelqu'un est-il passé à Nginx et a été "époustouflé" par la différence que cela faisait par rapport à Apache? Même pour les environnements hautement optimisés qui utilisent déjà APC, Memcache et une mise en cache agressive comme Varnish, lorsque la seule variable qui change est le remplacement d'Apache par Nginx, cela fait suffisamment de différence en soi pour mériter d'investir dans cette nouvelle technologie alternative. ?
Le site qui ira sur ce serveur reçoit en moyenne 2 millions de PV par mois. Pile LAMP exécutant Cent OS 6. CPU 4 cœurs avec 8 GIGS de RAM. Memcached et APC feront partie du mix. Rien de spécial à propos de l'installation Drupal - essentiellement Vanilla 7 avec environ 50 modules.
À strictement parler, cela ne répond pas à la question que vous posez. J'espère que c'est utile de toute façon.
Apache / Nginx / Lighttpd /autre serveur Web. Est-ce important celui que je choisis? En bref, Non .
La réponse beaucoup plus longue:
Si, et seulement si, vous avez un très grand pourcentage de vos utilisateurs connectés, si vous vous souciez des performances de votre serveur Web. Si vos utilisateurs sont anonymes, toute différence que vous pouvez théoriquement tirer de l'optimisation de ces couches est absolument pâle par rapport à l'amélioration de la 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 la deuxième fois. C'est important. Si vous pouvez mettre vos pages en cache dans Varnish ou une solution logicielle similaire, alors servir cette page consiste à faire une recherche de hachage, puis à renvoyer une grande partie des données directement à partir de la RAM. C'est important. Dans ces deux scénarios, le démon HTTP n'est même jamais impliqué, PHP n'est pas invoqué. Drupal ne démarre pas. Aucun grand ensemble de modules ne doit être chargé dans la RAM, aucune requête de base de données longue n'est exécutée.
Lorsque vous effectuez un chargement de page complète, à partir d'un cache froid, pour un utilisateur connecté, sur une page complexe; beaucoup des 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 la transmission de la réponse. Mais le temps qui prend n'est même pas pertinent dans le contexte de Drupal exécutant un bootstrap et produisant sa réponse. Il pourrait y avoir des centaines de requêtes de base de données en cours exécuté. Logique très complexe en PHP est évalué par l'analyseur. De nombreux modules sont chargés dans la RAM. L'amélioration des performances de n'importe laquelle de ces choses, est beaucoup plus susceptible d'apporter une contribution sérieuse à performance.
Par souci d'argument: disons que vous avez passé beaucoup de temps à optimiser les performances.
- Vous exécutez APC (Ou Optimizer + ) et la version la plus récente et la plus rapide de PHP.
- Les requêtes DB sont peu nombreuses.
- La logique PHP a été réduite.
- Vous cachez ce que vous pouvez dans Varnish.
- Vous avez restructuré l'intégralité de votre site afin de pouvoir mettre en cache beaucoup de côté client, et faire beaucoup de travail dans ECMAScript .
Si vous avez beaucoup d'utilisateurs connectés et que vous avez traité tout ce qui précède, vous pouvez probablement faire une différence, mais en optimisant les performances ou en remplaçant votre serveur Web. Mais devinez quoi. Votre site est tellement complexe et les modèles d'utilisation de vos utilisateurs particuliers sont unique. Il n'y a pas de réponse générique. Vous devrez configurer tous les différents serveurs Web derrière un équilibreur de charge et voir comment ils se comportent, sous votre scénario.
Ce qui précède était une tentative de parvenir logiquement à la conclusion que passer du temps à optimiser les performances du serveur Web est probablement une mauvaise utilisation du temps. J'aimerais bien que quelqu'un fasse des trous dans ce qui précède, j'apprendrais probablement quelque chose de nouveau à partir de cela. :)
Quelques autres notes:
- Pendant le DrupalCon Copenhagen keynote , PHP creator Rasmus Lerdorf , utilisant Nginx lui-même, parlant du sujet Drupal performance, a déclaré "Les gens me posent toujours des questions sur les serveurs Web ... cela n'a pas vraiment d'importance, le serveur Web est à peu près hors de propos". (À peu près à 26h30 dans la vidéo)
- Facebook a passé d'innombrables heures à écrire Hiphop , une base de code significativement plus grande que Drupal elle-même, pour accélérer le code PHP à 100% "misérable". J'ai examiné Hiphop avec
$ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1et l'a trouvé composé de 1.512.481 lignes de code. C'est un travail absolument fou pour améliorer la vitesse de PHP. Je suppose que c'est parce que la vitesse de PHP compte beaucoup pour eux. - Ai-je mentionné qu'une bonne mise en cache va avoir un effet beaucoup plus important que le réglage du serveur Web?
- Avec la sortie d'Apache 2.4, Jim Jagielski prétend essentiellement qu'Apache 2.4 est plus rapide que les serveurs basés sur les événements .
- J'ai écouté Drupal Performance and Scalability with The Dream Team , où vient de se poser cette question. Toutes les réponses sur lesquelles choisir, n'étaient pas liées à la performance. Des choses comme "Laquelle savez-vous déjà configurer", et "Laquelle vous permettra de créer la pile technologique la plus simple", étaient parmi les raisons mentionnées pour prendre le pas sur l'autre. La performance n'a pas pas entré dans l'image.
OK, bien que cette question soit déjà répondue, je nécromancie une fois de plus, principalement parce que je n'aime pas les implications de ces réponses que cela ne fait aucune différence, et parce qu'en tant que développeur web, je déteste la mise en cache avec passion .
La différence entre Apache et nginx n'est pas tant "la rapidité avec laquelle ils peuvent servir une demande" mais le nombre de demandes qu'ils peuvent servir sur la même quantité de matériel (en particulier avec des ressources limitées), ce qui est quelque chose d'un peu différent.
Apache est un serveur basé sur les processus. Ce qui 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énements (asynchrone) au lieu de processus ou de threads.
Et tandis qu'un serveur basé sur les processus (comme Apache) peut fonctionner plus ou moins à égalité avec un serveur basé sur les événements asynchrones (comme nginx) sous de faibles charges , sous des charges plus lourdes comme par exemple 10'0000 demandes 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 seul (sans compter l'application Web, qui a besoin de beaucoup plus de ressources elle-même), si elle pourrait le faire du tout.
Donc, sous des charges plus lourdes, vous verrez qu'Apache consomme beaucoup trop de RAM, ce qui sans surprise dégrade considérablement les performances.
Plus important encore, une consommation RAM 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 vous avez un TCO (coût total de possession) plus élevé avec Apache qu'avec nginx, ce qui réduit votre ROI (retour sur investissement).
Mémoire totale utilisée par X connexions simultanées (moins c'est mieux)
Demandes pouvant être servies par seconde à X connexions simultanées sur 1 ensemble de matériel (plus c'est mieux)
Source: ApacheBench, par dreamhost.com
Voir aussi cet océan numérique writup.
Apparemment, cela dépend de l'architecture de gestion de connexion que vous choisissez pour Apache.
Je suis passé d'Apache à Nginx/PHP-FPM il y a quelques mois.
J'ai fait quelques benchmarck 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 la 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 le 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 pour 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 pleine Drupal , met l'accent sur la sécurité (DoS, XSS, CSRF, prévention des injections SQL), et des vitesses et un encombrement similaires à 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 surpasse le peloton d'environ 10%.
Je ne voudrais pas accrocher mon chapeau à l'un de ces tests, mais cela donne une vue d'ensemble 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 drupal fonctionnant sur le même matériel mais avec un site web différent serveurs (nginx et Apache)
voici la conclusion de ce test:
sous un trafic important avec les mêmes ressources matérielles, nginx fonctionne bien mieux qu'Apache.