In der Technikwürze widmen wir uns in dieser Ausgabe verstärkt der Grundlage einer jeden Webseite: Dem Webserver. Ohne ist nicht viel los, erst Recht, wenn mehr als fünf Leute auf diesen zugreifen. Dazu reden wir mit Sebastian Heinisch. Er ist technisch verantwortlich für die Webseite feuerwache.net, die in einem Rechenzentrum in Hannover läuft. Die Webserver liefern die Inhalte mittels Lighttpd aus, die Datenbank wird per MySQL betrieben. Ein Pound Loadbalancer verteilt die Anfragen, die Server tauschen untereinander mittels Memcache die Daten aus. Lokal hat jede PHP Instanz auf einen xCache-Zugriff.
Ausgangslage
** openSuSE
** Standardrechner
- Serverüberlastungen kamen immer Regelmässiger
- Hektik brach aus, was nun?
Erste Optimierungsversuche
- Erst nur MySQL Server ausgelagert, brachte keine wirkliche Verbesserung
- Das Problem: Alles muss auf einmal umgestellt werden!
- Probleme mit mehreren Servern?
** Upload Dateien müssen Syncronisiert werden
** Sessions müssen übernommen werden
** Cache muss global gelöscht werden
Lösungen
** Schneller Webserver
** Wird u.a. von Youtube, thepiratebay, myspace eingsetzt
** FastCGI als PHP Schnittstelle
** xCache nutzen -> deutliche Performance Steigerung (PHP wird kompiliert)
** Speichert lokalen Cache (Variablen Cache) – Beispiel: “UserID to Username” (mittels xCache)
** Verteilt die Anfragen auf die einzelnen Webserver
** Unterschiedliche Methoden:
** User greift immer auf den gleichen Webserver zu
*** Vorteil: Kein Problem mit Sessions
*** Nachteil: Wenn Server weg, dann User weg
** User greift zufällig auf Server zu:
*** Effizientere Verteilung (Server mit wenig Auslastung wird bevorzugt)
*** Nachts können Server heruntergefahren werden (Stromkosten!)
** Achtung: User Sessions -> Memcache
** SEHR schnell – alle Daten aus dem Ram
** Hält die PHP-Sessions
** Speichert globalen Cache (Funktionscaching) – Beispiel “Feuerwache by ID”
** Wird u.a. von Facebook eingesetzt
** Speichert die Uploads der User und verteilt die über smbfs
** Keine Ahnung warum, aber bei mir schneller als NFS
- MySQL – von MyISAM auf InnoDB
** InnoDB transaktionssicher (commit, rollback etc.)
** Zeilensperre anstatt Tabellensperre
** Fremdschlüssel (on Delete)
** Mehr Speeeeed 🙂
Monitoring
- Alles sollte überwacht werden – RAM, CPU, Laufzeiten, HTTP-Antworten, DNS, Uhrzeit, Festplatte voll? etc.
** Alles was irgendwann zu Fehler führen könnte, wird auch zu Fehlern führen!
** iPhone Client
** SMS-Warnung
** E-Mail Warnung
** Gruppen
Wahl der Hardware
- Eigene Hardware:
** Direkter Zugriff
** Schneller HDD austausch bei ausfall
** Nicht auf einen Dienstleister angewiesen sein
** 2 Netze – Intern und Extern
- Mieten
** Günstiger
** nicht so flexibel
- Backup
** Im Rechenzentrum in dem auch das Spiel läuft
** Zusätzlich in anderes Rechenzentrum, anderer Anbieter (Strato)
Fazit
- Frühzeitig Gedanken machen
- Was machen die großen? – Facebook, YouTube, Google
- Hochwertige Hardware kaufen – man kauft sonst doppelt. Zum Beispiel bei 1he-server
