Scratchbook

Das Leben ist immer anders als die Realität.

Zehntausend Anfragen pro Sekunde.

Claude, 6. November 2010, 02:35 Uhr

Kunde möchte eine voraussichtlich stark frequentierte Seite mit Typo3 bei sich hosten.
Erwartet werden 5000 Benutzer gleichzeitig – die geschätzt alle 10 Sekunden klicken. Ergibt 500 Requests/s. Wir sollen die Architektur vorschlagen.

Und da sie dann alles selber verwalten möchten, soll das Betriebssystem ein Windows sein.

Windows

Gut. Opensource-Software läuft auf Windows, ja. Ich hab‘ dann mal verschiedenes ausprobiert.

Apache

Ich werde keinen Apache einsetzen, da dieser Bastelserver bei jedem Request einen neuen Prozess startet, mit allen Schikanen wie PHP und den geladenen Modulen. Da platzt irgendwann der Arbeitsspeicher.

Lighttpd

Lighttpd verfolgt einen anderen Ansatz: Ein Prozess „Webserver“. Dynamische Inhalte werden über die FastCGI-Schnittstelle an PHP-Prozesse geschickt. Diese Prozesse bleiben nach der Anfrage noch am leben, und so wird da nicht ständig gruusig im RAM rumgewurschtelt.

MySQL

Angedacht war ein Master-Slave MySQL „Cluster“ – auf dem Master wird geschrieben, die Slaves sitzen bei den Webservern und beantworten die Anfragen zeitnah. Dumm nur, wenn Typo3 bei jedem „lesen“ auch noch schreibt – so muss bei jedem Request alles auf die armen Sklaven repliziert werden. Nicht schick.

Dann hab‘ ich weitergeschaut. Wie lässt sich MySQL noch skalieren?
Eigentlich überhaupt nicht! Selbst Twitter hat einen grossen MySQL Chübel.
Das Ding ist halt keine CouchDB…

Und die hauseigene Clusterfunktionalität unterstützt weder MyISAM noch InnoDB. Wie praktisch.
Ausserdem lassen sich Schreib- und Leseanfragen nur mit Skripts und Hacks auf Master/Slave aufteilen.

Also gut, neue Strategie. MySQL skaliert nicht, das arme Kind braucht Schutz. Wir müssen vorher was machen. Vorher im Sinne von: Beim Webserver…

Nginx

„Ich brauch einen schnellen Reverse-Proxy“, hab ich Google gefragt. Denn Squid ist mir für die obigen Anforderungen zu lahm.

Nginx“ les‘ ich immer wieder. Nginx – „Engine-X“; das sei ein schneller Reverseproxy, und nebenbei kann er auch Webserver und FastCGI Anfragen.
Ich lese weiter… Er kann FastCGI Anfragen cachen (!!) 😮
Ist ja geil. Webserver UND Reverse-Proxy in einem!

Dann schmeissen wir mal das Caching an und schauen.
Lighttpd: 1000 Req/s
Nginx mit FastCGI-Cache: 2400 Req/s

Nice. In meinem Parallels läuft das tipptopp.

Am nächsten Tag gleich das heilige Nginx auf den Windows Server 2008 schmeissen. Starten.
Fehler.

„Google, was is’n los?“ – mmh, die Caching-Sachen vom Nginx laufen ab Windows Vista nimmer, „due to address space layout randomization being enabled in these Windows versions.“ Fuck you. Eine ganze Nacht für nix!

Dann eben doch ein Squid.
Mickrige 170 Req/s.

Linux

Es juckt und zwickt. Meine Neugier knistert. Bisher liess ich Nginx ja bloss unter Windows laufen… Aber wie muss das Teil wohl auf meinem Gentoo Linux abgehen? Nix wie los! Ausprobieren.

emerge nginx. +fastcgi

Typo3 drauf.

Apachebench anwerf. Jetzt kommt der absolute oberkrasse Megahammer. Traut euren Augen. Ich musste auch 4x schauen und 6x testen:


Document Path:          /t3/
Document Length:        9435 bytes

Concurrency Level:      200
Time taken for tests:   0.983 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      97526218 bytes
HTML transferred:       94411864 bytes
Requests per second:    10172.62 [#/sec] (mean)
Time per request:       19.661 [ms] (mean)
Time per request:       0.098 [ms] (mean, across all concurrent requests)
Transfer rate:          96884.48 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    3   1.8      2      14
Processing:     5   14  14.8     14     395
Waiting:        2   12  14.7     12     392
Total:          9   17  14.6     16     398

Percentage of the requests served within a certain time (ms)
  50%     16
  66%     16
  75%     17
  80%     19
  90%     21
  95%     23
  98%     25
  99%     27
 100%    398 (longest request)

Das hämmert und ballert und rockt wie sau!

Der fackelt tatsächlich zehntausend (!!!) Requests pro Sekunde ab!
Ich hab‘ den Server nicht tot gekriegt. Leider kann ich nicht höher; bei über 200 Concurrent Connections motzt mein Apachebench „too many open files“. Tja.

Ist ja nur ein zweijähriger Server mit 2.33 GHz. Aber halt ein Gentoo Linux mit einem angepassten Kernel 😈

10’000 Anfragen pro Sekunde.
Beinahe 100 Megabyte pro Sekunde.
98 Nanosekunden pro Anfrage.

Mach DAS mal nach, du Windows!

Hier übrigens der Vergleich der zwei Infrastrukturen:


Einmal Linux… Einmal 10’000 Req/s pro Server bitte – mal 2 😛


…Und einmal Windows. Muss 4 Squiddies zusätzlich aufstellen, kommt aber nur an einen 25stel der Leistung des obigen Systems an. Und dafür auch noch Geld zahlen.

Man sollte schlechte Software nicht mit top Hardware erschlagen. Sondern schlechte Hardware mit top Software.