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