Combien de performance a frappé pour https vs http pour apache?


50

Quel est le résultat de la performance de https par rapport à http pour la même page? Supposons que je puisse traiter 1000 requêtes / s pour abc.php, de combien diminuera-t-il lorsqu’un accès via https? Je sais que cela pourrait dépendre du matériel, de la configuration, du système d'exploitation, etc., mais je cherche simplement une règle générale approximative / une estimation.


2
Ce serait bien de voir une réponse acceptée pour cela.
Hyppy

Réponses:


57

Pour un test rapide et sommaire (aucune optimisation!), J'ai activé le site Web par défaut Ubuntu apache2 (qui dit simplement "Ça marche!") Avec http et https (certificat auto-signé) sur une machine virtuelle Ubuntu 9.04 locale et ai exécuté l'apache. référence " ab" avec 10 000 requêtes (pas de simultanéité). Le client et le serveur étaient sur la même machine / machine virtuelle:

Résultats pour http (" ab -n 10000 http://ubuntu904/index.html")

  • Durée des tests: 2.664 secondes
  • Requêtes par seconde: 3753.69 (# / sec)
  • Temps par demande: 0.266ms

Résultats pour https (" ab -n 10000 https://ubuntu904/index.html"):

  • Temps nécessaire aux tests: 107.673 secondes
  • Requêtes par seconde: 92.87 (# / sec)
  • Temps par demande: 10.767ms

Si vous examinez de plus près (par exemple avec tcpdump ou wireshark) la communication tcp / ip d'une requête unique, vous verrez que le cas http nécessite 10 paquets entre le client et le serveur, alors que https en requiert 16: la latence est beaucoup plus élevée avec https. (Plus d'informations sur l'importance de la latence ici )

L'ajout de Keep-Alive ( aboption -k) au test améliore la situation, car toutes les demandes partagent désormais la même connexion, c'est-à-dire que la surcharge de SSL est plus faible, mais que https est toujours mesurable plus lentement:

Résultats pour http with keep-alive (" ab -k -n 10000 http://ubuntu904/index.html")

  • Durée des tests: 1.200 secondes
  • Requêtes par seconde: 8334.86 (# / sec)
  • Temps par demande: 0.120ms

Résultats pour https avec keep-alive (" ab -k -n 10000 https://ubuntu904/index.html"):

  • Temps nécessaire aux tests: 2,711 secondes
  • Requêtes par seconde: 3688.12 (# / sec)
  • Temps par demande: 0.271ms

Conclusion :

  • Dans ce cas de test simple, https est beaucoup plus lent que http.
  • Il est judicieux d'activer le support https et d'analyser votre site Web pour voir si vous souhaitez payer pour les frais généraux https.
  • Utilisez Wireshark pour avoir une idée de la surcharge de SSL.

1
+1 beau travail là-bas. Merci d'avoir posté les chiffres.
MN

Pouvons-nous obtenir des spécifications sur le matériel de cette machine? le cryptage dépend fortement de la puissance du processeur.
Matt Simmons

1
J'ai récemment fait beaucoup d'essais sur un VPS et la meilleure chose qui a affecté les performances était le chiffrement utilisé. Si vous limitez les chiffrements à 128 bits, vous devriez pouvoir obtenir environ 500 à 600 demandes par seconde. L'utilisation d'un chiffre de 256 bits qui passera à moins de 100 requêtes par seconde. Je pense que lorsque j'ai fait mes propres tests, 30 demandes par seconde étaient demandées. Évidemment, les chiffres réels dépendent de votre machine.
kovert

Matt Simmons, j’utilisais une machine virtuelle Ubuntu 9.04 64 bits à 2 cœurs exécutée sur un Mac Pro début 2008 avec des processeurs Intel Xeon 2x Quad-Core à 2,8 GHz.
knweiss

Votre réponse m'a empêché de poster une question qui aurait été fermée dans les 20 secondes. Merci!
MonkeyZeus

10

Sur les serveurs modernes, je dirais que votre goulot d'étranglement serait le réseau et votre application, pas le cryptage. Le TLS / SSL dans Apache sera écrit en C assez optimisé, il sera donc éclipsé par votre code PHP, surtout si vous allez faire des choses comme accéder à une base de données. Servir des fichiers statiques aura probablement un impact plus important, car le cryptage deviendra une partie importante du processus. Je ne peux pas vous donner de chiffres concrets, mais je serais surpris que ce soit plus de 5% et probablement plus près de deux pour cent.


2
David a raison, cela dépend du type de contenu que vous avez. La bonne façon serait de comparer avec apache banc httpd.apache.org/docs/2.2/programs/ab.html
rayon

Mis à part la vitesse de cryptage, qu'en est-il de la négociation SSL, cela aura-t-il un impact sur les performances et le débit du serveur?
erotsppa

La négociation SSL ajoutera quelques paquets à l'avant d'une connexion. L'impact de cela dépendra énormément de la latence de la connexion entre le serveur et le client. Keepalives HTTP réduira l'impact de cette poignée de main.
David Pashley


1

Je constate que sur du matériel moderne, je suis plus susceptible d'être lié à une transaction particulière qu'à un processeur (calcul). Cela est particulièrement vrai en matière de compression et de chiffrement. Le cryptage 128 bits est devenu trivial de nos jours. En général, la création et la livraison des pages sortantes sont beaucoup plus difficiles que l'utilisation de SSL. Je n'ai pas remarqué de différence significative de performances entre les trafics http et https en quelques années.


1

J'appuie la recommandation pour nginx. Dans mes propres tests, il a bien résisté en tant que déchargeur SSL dédié.


0

Bien sûr, si le traitement SSL frappe fort, vous pouvez toujours le déplacer hors serveur vers une zone dédiée. Il y a une belle écriture à faire avec nginx ici . C'est quelque chose que nous avons fait sur des serveurs à charge équilibrée de couche 7 très chargés.


0

Je peux confirmer que la charge supplémentaire de cryptage est très faible par rapport à tous les autres éléments inclus (scripts, réseau, ...)


0

D'après mon expérience, la règle générale est directement liée à la taille de votre clé publique (par exemple, 2048, vs 4096, par rapport à 8192), mais toutes prennent beaucoup plus de temps. Cependant, je peux difficilement remarquer une différence dans un environnement de bureau, mais le mobile est celui dans lequel vous voyez une différence car il faut de la puissance de calcul.

En général, c'est malheureux, mais SSL a toujours eu et aura probablement toujours un énorme impact négatif sur les performances.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.