RootForum Community

Ich habe ein Performance-Problem mit einem Liveticker, den ich programmiert habe, für einen relativ kleinen Fußballverein (Oberliga, sollte also eigentlich lösbar sein). Hier zunächst die Fakten:

System: Linux suse101lamp 2.6.16.53-0.16-smp
Apache 2.2.3 (prefork)
PHP 5.2.0
Der Server hat 2 GB Speicher, Prozessor ist AMD Athlon(tm) 64 Processor 3700+

Ich habe vollen Zugriff auf den Server (kann allerdings aus bestimmten Gründen hier nicht von prefork auf worker wechseln, sollte dies nötig sein).
Ich habe versucht, die Optimierung soweit es geht hiernach durchzuführen:
http://www.h07.org/projects/apachetuning/


Der Liveticker funktioniert so, dass jemand im Stadion alle paar Minuten ein Statement abgibt und wichtige Änderungen wie Tore, Auswechslungen, Karten etc. eingibt.
Fans zu Hause schauen sich die Seite an, die dann in regelmäßigen Abständen neu geladen wird.

Allerdings sind Fußballfans ungeduldig und drücken gerne die Reload-Taste. Die Livetickerseite hat mit allen Grafiken eine Größe
zwischen 70-100 kB (je nach Spielstand und Summe der Eingaben).
Webalizer sagt nach einem Spieltag (also gute 2 Stunden Realzeit) hierzu (beispielsweise):
Hits: 893016
Files: 108640
Pages: 55447
Visits: 2397
KBytes: 1493570

Die Seite wurde zunächst dynamisch generiert, d.h. bei jedem Aufruf durch verschiedene Datenbankaufrufe zusammengesetzt. Hier war der Server schon relativ kurz nach dem Spielbeginn zusammengebrochen, allerdings hatte ich zu diesem Zeitpunkt noch nicht optimiert.

Nach einigen Optimierungsversuchen bin ich nun soweit, dass eine HTML-Seite generiert und abgespeichert wird, wenn es Änderungen gibt. Der Nutzer ruft also tatsächlich nur noch ein liveticker.html auf, trotzdem ist der Server teilweise nicht mehr erreichbar.

Während der harten Phase (also des Spiels) habe ich den Server mal beobachtet und folgendes feststellen können:

- Die Auslastung bei "top" ist nur geringfügig: 0,1-0,2

- Speicher war in der Zeit genügend vorhanden.

- Mit cat und grep finde ich raus, dass ca. 350-450 Liveticker-Aufrufe pro Minute erfolgen. Gegen Ende des Spiels werden es bis ca. 600. Hier kam der Aufruf der Webseiten auch ziemlich ins Stocken.

- Ich habe dann per "ps ax | grep http | wc -l" nachgeschaut und sah, dass die Anzahl der http-Prozesse am Limit waren (300 Stück).

- Gegen Ende habe ich den Wert auf 400 hochgesetzt (/etc/apache/server-tuning.conf ) und ein /etc/init.d/apache restart
gemacht. Beim Restart war der Server nun erstmal gierig beschäftigt (top ging bis auf 15, dann aber langsam (5 Minuten) wieder runter). Kurz danach hatte ich allerdings bei den Anzahl der Prozessen die 400 erreicht.

Was ich nicht verstehe: Es erfolgen ca. 400 Zugriffe auf eine HTML-Seite pro Minute (plus ein paar zu vernachlässige Zugriffe anderer Domains). Die Zugriffe sollten eigentlich in Millisekunden abgehandelt sein. Trotzdem sehe ich 400 httpd-Prozesse. Wieso geben die sich nicht wieder frei?

Hier der Inhalt der aktuellen server-tuning.conf (ohne BrowserMatch), inzwischen auf 600 ServerLimit erweitert.:
--->
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 30
ServerLimit 600
MaxClients 600
MaxRequestsPerChild 10000
</IfModule>
<IfModule worker.c>
StartServers 3
MinSpareThreads 25
MaxSpareThreads 75
ThreadLimit 64
MaxClients 150
ThreadsPerChild 25
MaxRequestsPerChild 10000
</IfModule>
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<---

Nun endlich die Frage der Fragen: Wie kann ich den Zugriff erheblich optimieren?

Folgende Möglichkeiten fallen mir ein:
1. Dies wäre die beste, weil schnellste Methode: Obige Einstellungen für die Prefork-Moduleinstellungen ändern auf ...? Wie weit darf ich mit den Werten hochgehen, wie hängen diese sinnvoll zusammen?

2. Würde es etwas bringen, wenn ich den Liveticker umprogrammiere, also:
- Wieder als .php
- Inhalte statisch
- Änderungen dynamisch per Ajax (wo ja nur noch geringe Datenmengen übertragen werden).
Nachteil: Durch php (Parsen) würden wieder mehr Ressourcen benötigt.
Vorteil: Weniger zu übertragende Daten

3. Neuer Server, der dann als worker arbeitet.
Würde dies große Performance-Steigerungen bringen? Der würde sich dann zunächst für 165 Stunden in der Woche langweilen, könnte aber optimal konfiguriert werden.

Gibt es vielleicht noch andere Lösungen, die ich nicht genannt habe?

Anmu

Beim KSC läuft für den Liveticker während den Spielen ein eigener lighttpd auf Port 81, der wirklich nur die Liveticker-Seite(n) ausliefert. Das scheint ganz gut zu klappen. ;)

Mit deinem Caching-Ansatz (HTML-Seite alle X Minuten generieren und nur die statische Datei ausliefern) fährst du schonmal ganz gut. Du könntest diese Datei dann auch von einem eigens für statische Dateien optimierten Webserver ausliefern lassen (lighttpd, nginx, gatling...). Oder du versuchst, ob du mit den Caching-Einstellungen für HTTP oder mit META-Tags weiterkommst, so dass die Browser der Benutzer "merken" wenn sich nichts verändert hat und dann die Kopie aus dem lokalen Cache ziehen.

Du müsstest nun schauen, wie sich das während des Spiels entwickelt - Hintergrund ist, daß Killen und Starten der Apache-Prozesse enorm viel Zeit kostet, da der Apache ggfls. nur alle 1s einen neuen Serverprozeß startet.

Grundsätzlich wäre es eine Idee, so zu verfahren, wie Roger vorgeschlagen hat - eigener schlanker Server ohne PHP und viel Gerödel - jeder Apache-Prozess wird bei Dir um die 25MB schlucken, wenn es reicht.

Alternative 2 wäre ein Proxy oder sogar ein Cache vor dem eigentlichen Webserver - ich nehme gerne Pound, aber es gibt viele Alternativen, vor allem unter dem Aspekt, daß Pound selber nicht cached. Damit könntest Du die Anfragen etwas bequemer delegieren (z.B. an lighttpd oder einen zweiten Apache) oder den Ticker gleich aus dem Cache ausliefern.

anmu wrote: Was ich nicht verstehe: Es erfolgen ca. 400 Zugriffe auf eine HTML-Seite pro Minute (plus ein paar zu vernachlässige Zugriffe anderer Domains). Die Zugriffe sollten eigentlich in Millisekunden abgehandelt sein. Trotzdem sehe ich 400 httpd-Prozesse. Wieso geben die sich nicht wieder frei?

Könnte der Keepalive dran schuld sein ... ist der per Default an?

Keep-Alive deaktivieren und eine Kombination der Vorschläge von Roger Wilco und flo aufsetzen, gegebenenfalls per Flash oder AJAX erweitern.

Vielen Dank für Eure vielen und ausführlichen und tollen Antworten! An KeepAlive hatte ich gar nicht gedacht, aber das wird wohl der Hauptverursacher sein. Den habe ich erstmal ausgeschaltet.
Wenn der KSC als Bundesligaverein mit Lighttpd klar kommt, dann sollte ein Oberliga-Verein das auch schaffen. Wenn KeepAlive also doch nicht so viel gebracht hat, dann werde ich das auf jedenfall ausprobieren. Momentan ist allerdings ja gerade Saisonpause.

Viele Dank nochmal,
Anmu

Wenn eh gerade Saisonpause ist, würde ich die Zeit nutzen und komplett auf Lighttpd umsatteln. Lighttpd ist nämlich nicht nur schneller als der Apache, sondern benötigt auch nur einen Bruchteil der Systemressourcen, insbesondere RAM.
Damit seit Ihr dann auch den Zugriffszahlen nach dem Aufstieg gewachsen ;)