Hallo,
ich betreibe einen Webserver (Zwei Xeon-Prozessoren, je 3 GHz, HT aktiviert, virtuell also 4 Prozessoren, 2 GB RAM, Debian Etch, Apache 2.2). Auf diesem laufen ein Apache, ein Java Application Server (Tomcat) und testweise gerade ein thttpd.
Folgendes Problem: http-Abrufe sind schnell genug, https-Abrufe um einen Faktor 10 langsamer (und damit zu langsam).
Im Benchmark habe ich via "ab" jeweils 100 Seiten parallel abrufen lassen (das ist unsere Zielgröße, wenn er 100 Seiten durchgängig in unter einer Sekunde schafft, dann schafft er die angepeilten 1000 User, die etwa alle 10 s den nächsten Link anklicken).
Für statische Seiten ergibt sich als Gesamtdauer für alle Abrufe:
Apache/http: 0,26 s Apache/https: 2,5 s thttpd/http: 4,89 s (am "dicken" Apachen scheints also nicht zu liegen)
Für dynamische Inhalte vom Java Appl. Server (der darf nur per HTTPS erreichbar sein):
Apache/https: 2,91 s
(Wie geschrieben sind Werte unterhalb von 1 s nötig)
Ich schlussfolgere aus den Werten, dass mir Optimierungen am JBoss und der Java-App nichts bringen werden (da er für 100 Java-Seiten offensichtlich nur 0,4 s benötigt). "Schuld" scheint hingegen https: Die Verzehnfachung der Dauer von 0,26 s bei http zu 2,5 s bei https für Auslieferung der exakt selben Seiten ist erheblich.
Was habt ihr so an CPU-Verbrauch für HTTPS bei euren Servern? Hat jemand Ideen, wie man die https-Leistung das Apache steigern könnte? Hat jemand "RSA Service Processor Cards" oder dergleichen im Einsatz? Gibt es sowas als PCI-Karten oder nur onboard bei den schweren Geschützen von IBM und SUN?
Auch andere Anregungen sind sehr gern gesehen!
Danke im Voraus & Viele Grüße Fabian
Hallo,
aktuell bietet das System u.a. den Cipher AES-256 an. Ist dieser möglicherweise "federführend" für den hohen CPU-Bedarf verantwortlich? Kennt jemand eine vertrauenswürdige Aufstellung der vermuteten Sicherheit (bzw. wie lange ein Knacken vermutlich bräuchte) der verfügbaren Cipher und ihrer CPU-Hungrigkeit?
Danke & Viele Grüße Fabian
On Sunday 25 November 2007, Fabian Hänsel wrote:
ich betreibe einen Webserver (Zwei Xeon-Prozessoren, je 3 GHz, HT aktiviert, virtuell also 4 Prozessoren, 2 GB RAM, Debian Etch, Apache 2.2). Auf diesem laufen ein Apache, ein Java Application Server (Tomcat) und testweise gerade ein thttpd.
Folgendes Problem: http-Abrufe sind schnell genug, https-Abrufe um einen Faktor 10 langsamer (und damit zu langsam).
Faktor 10 klingt für Verschlüsselung erstmal nicht völlig abwegig. Normal wäre aber Faktor 4.
Im Benchmark habe ich via "ab" jeweils 100 Seiten parallel abrufen lassen (das ist unsere Zielgröße, wenn er 100 Seiten durchgängig in unter einer Sekunde schafft, dann schafft er die angepeilten 1000 User, die etwa alle 10 s den nächsten Link anklicken).
Was ist das? Ein Web-Spiel? Kein normaler User klickt aller 10s!
Für statische Seiten ergibt sich als Gesamtdauer für alle Abrufe:
Apache/http: 0,26 s Apache/https: 2,5 s thttpd/http: 4,89 s (am "dicken" Apachen scheints also nicht zu liegen)
Wieviel ist vom Swap belegt?
Ist das Dateisystem in Ordnung?
Sind die Platten ordentlich angebunden? (vernünftige Kabel und korrekte DMA-Settings)
Wie groß sind diese Dateien eigentlich?
Was sind die Eigenschaften von Deinem Zertifikat? (welcher Algorithmus, wie lang ist der Schlüssel, wie signiert, ....)
Für dynamische Inhalte vom Java Appl. Server (der darf nur per HTTPS erreichbar sein):
Apache/https: 2,91 s
(Wie geschrieben sind Werte unterhalb von 1 s nötig)
Ich schlussfolgere aus den Werten, dass mir Optimierungen am JBoss und der Java-App nichts bringen werden (da er für 100 Java-Seiten offensichtlich nur 0,4 s benötigt). "Schuld" scheint hingegen https: Die Verzehnfachung der Dauer von 0,26 s bei http zu 2,5 s bei https für Auslieferung der exakt selben Seiten ist erheblich.
Ich vermute das Problem an einer anderen Stelle. Beobachte mal den Speicher und die Prozessliste während Du den Benchmark fährst.
Was habt ihr so an CPU-Verbrauch für HTTPS bei euren Servern? Hat jemand Ideen, wie man die https-Leistung das Apache steigern könnte?
NULL-Cipher... ;-)
Hat jemand "RSA Service Processor Cards" oder dergleichen im Einsatz? Gibt es sowas als PCI-Karten oder nur onboard bei den schweren Geschützen von IBM und SUN?
Sowas braucht man eigentlich erst ab einer Serverbelastung in der Gegend von eBay oder Amazon.
aktuell bietet das System u.a. den Cipher AES-256 an. Ist dieser möglicherweise "federführend" für den hohen CPU-Bedarf verantwortlich? Kennt jemand eine vertrauenswürdige Aufstellung der vermuteten Sicherheit (bzw. wie lange ein Knacken vermutlich bräuchte) der verfügbaren Cipher und ihrer CPU-Hungrigkeit?
Sicherheit:
Im Moment geht man davon aus dass alles oberhalb einer Komplexität(*) von 110 Bit (in etwa) unerreichbar ist. Alle AES-Varianten befinden sich oberhalb dieser Grenze (es sind erst eine Handvoll Bits heruntergekratzt).
(*)Komplexität ist nicht zu verwechseln mit Breite des Schlüssels, nur bei idealen Ciphern ist diese identisch.
Performance:
Cipher sind üblicherweise das geringste Problem. Der Public-Key-Teil des SSL-Handshake ist wesentlich aufwändiger und meistens war es doch nur exzessives Swapping.
Konrad
Am 25.11.2007 um 22:02 schrieb Fabian Hänsel:
Im Benchmark habe ich via "ab" jeweils 100 Seiten parallel abrufen lassen (das ist unsere Zielgröße, wenn er 100 Seiten durchgängig in unter einer Sekunde schafft, dann schafft er die angepeilten 1000 User, die etwa alle 10 s den nächsten Link anklicken).
Ich denke, Du solltest das Testverfahren anders gestalten. HTTP/1.1 kennt "keep-alive" für die unterliegenden Verbindungen. Das teure an SSL/TLS ist die Phase des Schlüsseltausches [1]. Wenn Du also nicht ständig neue Verbindungen aufbauen mußt, sondern welche wiederverwenden kannst, spart das den Schlüsseltausch. Ändere doch mal das Testprocedere auf inkrementelles Aufbauen vieler Verbindungen als Phase eins, und dann erst o.g. Last-Tests mit den bestehenden Verbindungen. Ich halte es für 1000 Nutzer über 10 Sekunden relativ unrealistisch, daß alle im (nahezu) selben Moment Deine Seite zum 1. Mal anklicken (und damit den Schlüsseltausch auslösen).
HTH, Sebastian
[1] "http://blog.koehntopp.de/archives/1840-Wie-teuer-ist-SSL.html" -- Jeder ist notwendigerweise der Held seiner eigenen Lebensgeschichte.
Hallo!
Ich denke, Du solltest das Testverfahren anders gestalten. HTTP/1.1 kennt "keep-alive" für die unterliegenden Verbindungen.
Ich denke, das hat er schon bedacht. Denn er baut nicht für jedes Bild usw. eine Verbindung auf, sondern nur für den neuen Klick nach 10 Sekunden. Und dann ist keep-alive meist schon abgelaufen, sonst müsste der Apache2 1000 Verbindungen im RAM halten und sehr viele Threads laufen haben, was er nicht schaffen dürfte.
Ich habe auch nur 2 Gig und war deshalb gezwungen, keep-alive auf 2 Sekunden zu stellen. Ist das ungünstig?
Thomas
Am 27.11.2007 um 11:36 schrieb Thomas Schmidt:
Ich denke, Du solltest das Testverfahren anders gestalten. HTTP/1.1 kennt "keep-alive" für die unterliegenden Verbindungen.
Ich denke, das hat er schon bedacht. Denn er baut nicht für jedes Bild usw. eine Verbindung auf, sondern nur für den neuen Klick nach 10 Sekunden.
Und ich meinte, daß er das in seinen Testfällen nicht berücksichtigt: 10 Sekunden eine SSL-Verbindung halten ist billiger als eine neue Verbindung+SSL zu starten, zumindest in Sachen Rechenzeit. Allerdings haben wir darüber bisher nur spekuliert. Daher Frage an Fabian: sind es immer dieselben 1000 Nutzer, oder immer neue? Sprich: müssen immer neue Verbindungen aufgebaut werden, oder können die alten wieder benutzt werden?
MfG Sebastian -- Jeder ist notwendigerweise der Held seiner eigenen Lebensgeschichte.
lug-dd@mailman.schlittermann.de