Vraag Hoeveel van een performance hit voor https vs http voor apache?


Hoe groot is een prestatiehit die https neemt in vergelijking met http voor dezelfde pagina? Stel dat ik 1000 requests / s kan afhandelen voor abc.php, hoeveel zal het verminderen als het via https wordt benaderd? Ik weet dat dit afhankelijk kan zijn van hardware, configuratie, besturingssysteem enz., Maar ik ben gewoon op zoek naar een algemene vuistregel / schatting.


50
2017-07-21 18:45


oorsprong


+1 Bedankt voor het stellen. :) - M.N
Het zou leuk zijn om hiervoor een geaccepteerd antwoord te zien. - Hyppy


antwoorden:


Voor een snelle en vuile test (dus geen enkele optimalisatie!) Heb ik de eenvoudige Ubuntu apache2-standaardwebsite (die alleen zegt "Het werkt!") Met zowel http als https (zelfondertekend certificaat) op een lokale Ubuntu 9.04 VM ingeschakeld en de apache uitgevoerd benchmark "ab"met 10.000 verzoeken (geen concurrency). Cliënt en server waren op dezelfde machine / VM:

resultaten voor http ("ab -n 10000 http://ubuntu904/index.html")

  • Tijd nodig voor testen: 2.664 seconden
  • Verzoeken per seconde: 3753.69 (# / sec)
  • Tijd per aanvraag: 0.266ms

resultaten voor https ("ab -n 10000 https://ubuntu904/index.html"):

  • Tijd nodig voor testen: 107,673 seconden
  • Verzoeken per seconde: 92,87 (# / sec)
  • Tijd per aanvraag: 10.767ms

Als u van dichterbij kijkt (bijvoorbeeld met tcpdump of wireshark) bij de tcp / ip-communicatie van a enkel verzoek u zult zien dat het http-geval 10 pakketten vereist tussen client en server, terwijl https 16 vereist: de latentie is veel hoger met https. (Meer over het belang van latentie hier)

Toeval toevoegen (ab keuze -k) naar de test verbetert de situatie omdat nu alle verzoeken dezelfde verbinding delen, dat wil zeggen dat de SSL-overhead lager is - maar https is nog steeds langzamer meetbaar:

resultaten voor http met keep-alive ("ab -k -n 10000 http://ubuntu904/index.html")

  • Tijd nodig voor testen: 1.200 seconden
  • Verzoeken per seconde: 8334,86 (# / sec)
  • Tijd per aanvraag: 0,120ms

resultaten voor https met keep-alive ("ab -k -n 10000 https://ubuntu904/index.html"):

  • Tijd nodig voor testen: 2.711 seconden
  • Verzoeken per seconde: 3688.12 (# / sec)
  • Tijd per aanvraag: 0,271 ms

Conclusie:

  • In deze eenvoudige testcase is https veel langzamer dan http.
  • Het is een goed idee om https-ondersteuning en benchmark in te schakelen jouw website om te zien of u wilt betalen voor de https-overhead.
  • Gebruik wireshark om een ​​indruk te krijgen van de SSL-overhead.

57
2017-07-22 00:25



+1 Goed gedaan. Bedankt voor het plaatsen van de cijfers. - M.N
Kunnen we wat specificaties krijgen over de hardware van die machine? codering is in hoge mate afhankelijk van de processorkracht. - Matt Simmons
Ik heb onlangs heel wat tests op een VPS gedaan en het enige belangrijkste dat prestatie bewerkstelligde, was het cijfer dat werd gebruikt. Als u coderingen beperkt tot 128 bits, kunt u ongeveer 500-600 verzoeken per seconde ontvangen. Een 256-bits cijfer gebruiken dat een seconde kleiner wordt dan <100 verzoeken. Ik geloof dat toen ik mijn eigen testen deed, het 30 verzoeken per seconde waren. Vanzelfsprekend zijn de werkelijke aantallen afhankelijk van uw machine. - kovert
Matt Simmons, ik gebruikte een 2-core 64-bit Ubuntu 9.04 VM (VMware Fusion) op een Mac Pro in het begin van 2008 met 2x Quad-Core 2,8 GHz Intel Xeon CPU's. - knweiss
Uw antwoord heeft me belet een vraag te stellen die binnen 20 seconden zou zijn afgerond. Bedankt! - MonkeyZeus


Op moderne servers zou ik zeggen dat uw knelpunt het netwerk en uw applicatie zou zijn, niet de codering. De TLS / SSL in apache zal worden geschreven in een redelijk geoptimaliseerde C, dus zal deze worden overschaduwd door je PHP-code, vooral als je dingen gaat doen zoals databasetoegang. Het gebruik van statische bestanden zal waarschijnlijk een grotere impact hebben, omdat de codering een groter deel van het hele proces zal uitmaken. Ik kan je geen concrete cijfers geven, maar het zou me verbazen als het meer dan 5% was en waarschijnlijk dichter bij een paar procent.


10
2017-07-21 18:53



David heeft gelijk, het hangt af van het soort inhoud dat je hebt. De goede manier zou zijn om te benchmarken met apache bench httpd.apache.org/docs/2.2/programs/ab.html - radius
Afgezien van de versleutelingssnelheid, hoe zit het dan met de SSL-handshake, zal dat enige invloed hebben op de serverprestaties en -doorvoer? - erotsppa
De SSL-handshake voegt een paar pakketten toe aan de voorkant van een verbinding. De impact hiervan zal enorm afhangen van de latentie van de verbinding tussen de server en de client. HTTP-keepalives zullen de impact van deze handshaking verminderen. - David Pashley


Neem niets aan, test het zelf! Op uw specifieke web-apps natuurlijk.


8
2017-07-21 22:04





Ik vind dat op moderne hardware, ik meer geneigd ben om I / O gebonden te zijn voor een bepaalde transactie dan dat ik processor (compute) gebonden ben. Dit geldt in het bijzonder wanneer het gaat om compressie en codering. 128-bits codering is tegenwoordig triviaal - ik word over het algemeen veel harder geraakt bij het bouwen en bezorgen van de uitgaande pagina's dan bij SSL, en ik heb al een paar jaar geen significant verschil in prestaties tussen http en https-verkeer opgemerkt.


1
2017-07-21 19:08





Ik heb de aanbeveling voor nginx gestaakt. In mijn eigen tests heeft het goed standgehouden als een toegewijde SSL-offloader.


1
2017-07-22 10:23





Natuurlijk, als de SSL-verwerking hard geraakt is, kunt u deze altijd van de server naar een speciale doos verplaatsen. Er is een mooie beschrijving van dit te doen met nginx voorbij hier. Dit is iets wat we hebben gedaan op servers met load 7 met hoge loadbalans.


0
2017-07-21 18:59





Ik kan bevestigen dat de toegevoegde belasting voor codering erg klein is in vergelijking met elk ander inbegrepen element (scripting, netwerk, ...)


0
2017-07-21 21:01





Uit mijn ervaring is de algemene regel direct gerelateerd aan hoe groot uw openbare sleutel is (bijv. 2048, vs 4096, vs 8192), alle duren aanzienlijk langer. Ik merk echter nauwelijks verschil in een desktop-omgeving, maar op mobiel zie je een verschil omdat het rekenkracht nodig heeft.

In het algemeen is het jammer, maar SSL heeft altijd en waarschijnlijk altijd een enorme prestatieboete genomen.


0
2018-04-18 22:15