[Theorie] Große Seiten auf verteilten Systemen

[theomega]

Hallo Leute,
ich werde wohl irgendwann (wann genau weiß ich noch nicht, schätze so auf ca. 12 Monate, also noch lange hin, aber ich denke halt trotzdem drüber nach) vor einem Problem stehen:
Es geht darum eine Seite zu hosten die danke stetig wachsender Besucherzahlen immer mehr Last auf dem Server produziert. Im Moment läuft das ganze auf zwei Servern mit der Aufteilung:
1. Server:
Apache mit PHP als Modul
Alle dynamischen Seiten

2. Server:
MySQL 4.x
Statische Inhalte per LIGHTTPD

Beide Server sind Athlon64 3200+ mit jeweils 2GB Ram. Die Hauptlast wird durch ein Forum (PHP mit MySQL) erzeugt.

Die Aufteilung hat sich bewährt wenngleich es sich inzwischen abzeichnet dass irgendwann (siehe oben) der erste Server nichtmehr reichen wird. Der zweite Server ist im Moment noch nicht sonderlich ausgelastet. Ich habe mir also überlegt welche Möglichkeiten mir bleiben:

1. Optimierung der Scripte:
Wir auf jeden Fall geschehen, nur habe ich das schon mehrmals gemacht und viel ist nichtmehr drin

2. Optimierung der Apache-Einstellungen:
Habe ich mich auch schon dran versucht, viel hat es nicht bewegt

3. Einen weiteren Server.
Die Frage ist nur, was damit machen. Meine Idee war irgendwas mit einem verteilten System zu drehen. Nur fehlt mir da leider die Erfahrung. Deshalb hier mein Post.

Wer hat einfach eine Idee? Es geht hier weniger um Anleitungen als um einfache Denkanstösse.

Danke
TO

[Roger Wilco]

2. Optimierung der Apache-Einstellungen:
Habe ich mich auch schon dran versucht, viel hat es nicht bewegt

Was hast du wie verändert und was hat sich an der Performanz dadurch verändert? Generell wären mehr Informationen nicht schlecht. Hast du bspw. den konkreten Flaschenhals deiner Seite schon gefunden? (-> langsame SQL-Abfragen, schlechte Festplattenperformanz, Bandbreite ausgenutzt/schlechte Netzwerkkarte usw.)

Meine Idee war irgendwas mit einem verteilten System zu drehen. Nur fehlt mir da leider die Erfahrung. Deshalb hier mein Post.

Unter http://poocs.net/articles/2006/03/13/th ... ng-stage-1 und http://poocs.net/articles/2006/03/20/th ... ng-stage-2 findest du ein paar interessante Hinweise.

[flo]

Eventuell könntest Du das Forum auf einen extra-Server auslagern und die Forums-DB in die Hauptdatenbank replizieren, so daß Du auf die Daten auch von der Seite aus noch Zugriff hast - so würde wenigstens das Forum die Website nicht ausbremsen und Du könntest noch ein bichen Performance rausholen.

Ansonsten evtl. noch ein Upgrade auf MySQL5, ich habe den Eindruck, daß dies etwas performanter ist als das 4er.

flo.

[theomega]

Was hast du wie verändert und was hat sich an der Performanz dadurch verändert? Generell wären mehr Informationen nicht schlecht. Hast du bspw. den konkreten Flaschenhals deiner Seite schon gefunden? (-> langsame SQL-Abfragen, schlechte Festplattenperformanz, Bandbreite ausgenutzt/schlechte Netzwerkkarte usw.)

Ich habe ein bischen an den eigentlichen Apache-Einstellungen herumgespielt. Eine so detailierte Analyse wie du schreibst ist mir leider nicht möglich, ich weiß nicht so genau wie ich das alles untersuchen kann woran es liegt. Die Verbindung zwischen den beiden Servern läuft über eine OpenVPN Verbindung. Ich habe die (Aber nur ganz leise) Vermutung das hier eines der Hindernisse liegt. Ich habe schon versuch das ganze durch einen einfachen SSH-Tunnel zu ersetzten, das hat aber keine veränderung gebracht.
Die Artikel werde ich mir mal anschaun, danke.

Eventuell könntest Du das Forum auf einen extra-Server auslagern und die Forums-DB in die Hauptdatenbank replizieren, so daß Du auf die Daten auch von der Seite aus noch Zugriff hast - so würde wenigstens das Forum die Website nicht ausbremsen und Du könntest noch ein bichen Performance rausholen.

Ist leider nicht möglich, die Seite bestehht fast ausschließlich aus dem Forum. Es handelt sich eigentlich um eine große Online-Community mit einigen Zusatzfeatures aussen herum, aber das Forum ist die Hauptsache.

Ansonsten evtl. noch ein Upgrade auf MySQL5, ich habe den Eindruck, daß dies etwas performanter ist als das 4er.

Werde ich mir anschaun müssen, keine Ahnung ob Debian dafür überhaupt packages hat.

Ich habe mir noch folgendes überlegt:
Dieses ganze Forum ist ein einzer Flickenteppich. Ich denke ihr kennt das: Die Scripte sind mit den Features gewachsen, überall wurde noch was eingefügt was alles ziemlich unübersichtlich und auch langsam gemacht hat. Deshalb denke ich über ein komplettes Rewrite nach. Allerdings sind dann einige Fragen offen:
1. Welche Programmiersprache nutzen: PHP will ich eigentlich nicht nochmal machen, ist ein ziemlicher Flickenteppich. Mein Favorit wäre ein Java-Servlet auf der Basis von Hibernate und Velocity (kein Struts (*bäh*) und auch kein jsp (*nochmehrbäh*)). Meine Erfahrungen in Java-Programmierung (auch auf Servlet-Seite) sind recht gut, deshalb diese Wahl. Nur stellt sich auch hier die Frage: Wie sieht es mit der Verteilbarkeit aus? Kann ich so einfach auf 2 Servern einen Apache Tomcat laufen lassen und von einen weiteren Server aus die Requests irgendwie verteilen?

2. Welche Distribution nutzen: Debian ist ja gut und schön, nur dieses hinterherhinken hinter den Versionen stört mich. Nachdem ich auf meinem Server daheim sehr gute Erfahrungen mit Gentoo gemacht habe denke ich darüber nach.

Evtl kann mir bei den Überlegungen auch jemand helfen

Gruß und Danke euch beiden
TO

[ephigenie]

Ich würde den lighttpd unbedingt auch für die dynamischen Inhalte einsetzen ...

Der Performancegewinn ist deutlich spürbar! Gerade bei vielen Zugriffen ist das Prefork - modell von Apache am Ende.

Alternativ könnte man noch einen Blick auf apache2.2 mit Event Handler legen - allerdings ist das neue fastcgi - modul für das proxy - framework (mod_proxy_fcgi) noch nicht stable genug für produktiv - einsatz (ist ja auch noch nicht offiziell in der dist. enthalten)

Damit könnte man dann ganz gut arbeiten.

Wenn du sagst du betreibst ein Forum, dann sind die statischen Inhalte nicht sooo relevant (lighttpd kann, solange deine Festplatten das mitmachen, sehr schnell eine 100Mbit Leitung auslasten)

Deswegen würde ich mysql-replikation gegenseitig betreiben (also über kreuz - alternativ auch nur master-slave) und auf beiden lighttpd + fastcgi - vielleicht mit pound als frontend.

[theomega]

Hy,
das mit dem lighttpd auch für die Dynamischen Inhalte wollte ich sowiso mal testen, mal schaun was das bringt. Wie soll ich dann php am besten einbinden? Per FastCGI?

Das mit der Datenbankreplikation ist zwar eine gute Idee, nur limitiert im Moment auf keinen Fall der Datenbank-Server (siehe meine Beschreibung oben). Die Last (=Load) des ersten Servers ist sicher zehmal so hoch wie die des zweiten (1.5 zu 0.15).

Danke trotzdem
TO

[isotopp]

Das mit der Datenbankreplikation ist zwar eine gute Idee, nur limitiert im Moment auf keinen Fall der Datenbank-Server (siehe meine Beschreibung oben).

Doch, wahrscheinlich ist genau das der Fall. Die meisten Datenbank-APIs machen Abfragen synchron, d.h. warten auf die Ankunft der letzten Zeile der Ergebnisse der ersten Abfrage bevor sie die zweite Abfrage stellen. Wenn Du einen OpenVPN-Tunnel zwischen Anwendung und Datenbank knallst, hast Du da 30-40ms Delay drin, während eine lokale Datenbank deutlich unter 1ms Delay pro Abfrage drin hat. Je nachdem wie schlecht Dein SQL ist (und wieviele Abfragen pro Seite Du stellst), kann sich das schnell summieren: 20 Queries mit 50ms Gesamtzeit sind nun einmal eine Sekunde (statt einer zwanzigstel Sekunde).

Und das ist nur Kommunikationsoverhead - da hat die Datenbank noch keinen Handschlag getan.

[theomega]

Hy,
danke für die Klarstellung, versteh ich das jetzt richtig, der Vorschlag ist zwei identische Server zu machen:

Server 1,2:
Lighttpd zur Auslierferung sämtlicher Daten
MySQL-Server

die beiden MySQL synchronisieren sich gegenseitig. Ich brauche doch dann aber noch einen dritten Server der das umschalten übernimmt und per NFS/o.ä. die Daten bereitstellt für die beiden anderen Server.

Wenn das so stimmt und das wirklich soviel bringen sollte: Wiso empfiehlt man dann allgemein immer den Datenbank-Server auszulagern? Wenn ich es richtig weiß ist auch dieses Forum hier so getrennt gemacht.

Gruß und Danke
TO

[ephigenie]

Jepp per Fastcgi -

bei mir ist da der Load vom 20-60 auf 3-8 gesunken...
bei gleichzeitig stetig steigenden Userzahlen ...

[Joe User]

Wenn Du schon an einen (teilweisen) Rewrite denkst, würde es sich anbieten, die SELECTs auf den lokalen MySQLd (slave) zu fahren und den Rest (UPDATE, INSERT, etc.) auf den dedizierten MySQLd (master) zu fahren...

[ephigenie]

naja - das würde ja heißen replikation ...

und das will er ja eigentlich nicht...

Obwohl es mit einem dediziertem mysql-server für Schreibzugriffe, der auf die beiden Webserver eine Replizierung fährt für read-only zugriffe sicherlich eine deutlich bessere Lösung ist.

Mich persönlich stört daran nur der SPOF mit einem "master" server.

Ich weiss gar nicht, ob man vom einem mysql-cluster aus nochmal replizieren kann, glaub ich aber nicht - d.h. es bleibt ein hot-standby System (mit drdbd oder enbd + heartbeat)...

BTW. hat jemand schon erfahrungen mit OCFS2 + mysql ? können 2 mysql-instanzen auf dieselben Datenbank-Files schreibend zugreifen (quasi - gleichzeitig versteht sich) ?

[flo]

die beiden MySQL synchronisieren sich gegenseitig. Ich brauche doch dann aber noch einen dritten Server der das Umschalten übernimmt und per NFS/o.ä. die Daten bereitstellt für die beiden anderen Server.

Momentan läuft ja bei Dir noch alles im Grünen Bereich - da ist das Problem, daß Du den Flaschenhals momentan nur abschätzen kannst. Möglich wäre auch, die DBs zu clustern. Bei allem "Auseinanderziehen" darfst Du den Aspekt "Single-Point-of Failure" natürlich auch nicht außer Acht lassen.

Wenn das so stimmt und das wirklich soviel bringen sollte: Wiso empfiehlt man dann allgemein immer den Datenbank-Server auszulagern? Wenn ich es richtig weiß ist auch dieses Forum hier so getrennt gemacht.

Betreffend Rootserver ist es so, daß die Ressourcen der Rechner ziemlich begrenzt sind - da ist es dann günstiger, die Dienste zu verteilen um damit die Möglichkeiten des (Gesamt-)Systems zu skalieren und gegebenenfalls auch eine gewisse Ausfallsicherheit zu erreichen. Ein hochperformanter MySQL-Server und gleichzeitig ein Apache mit 200 Instanzen bremsen sich mit typischen 512MB RAM aus, vor allem, wenn es sich um eine typische Maschine handelt, bei der noch der DNS, Plesk, Postfix, Courier und weiß ich nicht alles laufen.

flo.

[theomega]

Hallo,
danke für die Erklärungen.
Zum einen ist der Server mit 2GB Ram ja schon besser als die 0815-Rootserver ausgestattet.
Wie groß ist jetzt der Faktor mit dem Datenbank-Zugriff per Netzwerk wirklich? ISt das wirklich so ein extremer Zeitverlust. Welche Möglichkeiten außer OpenVPN würden sich den anbieten? Ich könnte mal bei meinem hoster nachfragen ob er ein Cross-Over-Kabel zwischen den beiden Servern ziehen kann, aber ob das geht weiß nicht. Würde das was bringen? Die beiden Server haben leider nur eine externe IP und darüber würde ich nur ungerne unverschlüsselt Daten übertragen.

Danke
TO

[isotopp]

Wie groß ist jetzt der Faktor mit dem Datenbank-Zugriff per Netzwerk wirklich?

Das können wir Dir nicht sagen, das kannst Du nur selber messen: Wie viele Queries machst Du pro Seite und wie groß ist die Latenz (der Ping) von a nach b? Der Verlust pro Seite ist das Produkt beider Zahlen.

Würde das was bringen?

Das können wir Dir nicht sagen, das kannst Du nur selber messen: Wie gross ist de Ping dann? Der Gewinn pro Seite ist (Anzahl der Queries pro Seite)*(Differenz der beiden Ping-Methoden).

[theomega]

Hy,
also der Ping zwischen den beiden Servern ist unterhalb von 0,7ms. Wieviel hat man bei einer Crossover-Verbindung? Kann ich leider nicht testen, aber kommt man damit darunter? Ich meine für mein Gefühl ist das doch recht wenig, oder?

Wie sieht es mit Java aus? Hat bezüglich Loadbalancing mit einem Apache Tomcat jemand Erfahrung? Eigentlich ist ja Java/Servlets bei Firmen sehr beliebt und die müssten doch auch je nach Seitengröße ein LoadBalancing realisieren.

Danke auf jeden Fall
TO

[andreask2]

Hallo!

Bei sowas macht es meist wenig Sinn auf gut Glück irgendwelche Maßnahmen durchzuführen. Das heißt zum einen, dass Du jede Maßnahme messen musst, z.B. mit siege oder ab. Ideal wäre es, wenn Du hierfür den Server kurzzeitig "vom Netz nehmen" könntest, also irgendwann Nachts zu Wartungszwecken höchstens noch eine Meldung per lighttpd auslieferst, um aussagekräftige Ergebnisse zu erhalten.

Dann würde ich als erstes mal Apache2 Und MySQL so so konfigurieren, dass sie langsame Skripte (%D) bzw. Queries loggen. Somit kommt man an die berühmten 20% Code die 80% der Performance verbrauchen, es lohnt sich also genau hier mit Optimierungen anzufangen.

Als nächstes dann xdebug installieren (nicht ständig mitlaufen lassen, weil es PHP ein bisschen bremst), dann kannst Du per Profiler genau sehen, wo die Bremsen in Deinen Scripten zu finden sind: http://xdebug.org/docs-profiling2.php

Eine gute Präsentation zum Thema Profiling:
http://www.omniti.com/~george/talks/Pro ... s-2004.pdf (1.5 MB)

Also einfach xdebug installieren, Profiling einschalten, und ein Verzeichnis konfigurieren, in das xdebug die Profiling Dateien schreibt. Die kannst Du Dir dann mit WinCacheGrind/KCacheGrind ansehen. Ist wirklich einfach! Möglicherweise siehst Du da, dass die MySQL-Funktionen gar nicht so viel Zeit kosten, dafür irgendwas ganz anderes, womit Du nie gerechnet hättest...

Dass der MySQL-Server weniger belastet ist als der Apache, ist gerade bei einem Forum schonmal ein gutes Zeichen. Einige gute Tipps zur Konfiguration von PHP findest Du oben in den Kommentaren der php.ini-recommended: http://cvs.php.net/viewcvs.cgi/php-src/ ... iew=markup

Allgemein würde ich bei PHP empfehlen, eine möglichst aktuelle (5.1) Version zu verwenden, die ist gerade bei komplexerem Code ne Ecke schneller als 5.0 und 4.x (5.1.3 wird nochmal einiges verbessern, da wurde vor wenigen Tagen noch einiges rausgeholt, siehe Benchmark-Links unten). Dann auf jeden Fall ein Opcode Cache, für 5.1 bietet sich hier PECL::APC an, der hat in meinen Augen hierfür die beste Unterstützung. Wenn Du Apache verwendest, PHP statisch einkompilieren, oder bei neueren Version NICHT --with-pic verwenden (warum findest Du hier).

Und natürlich die ganzen anderen Tipps aus den unten verlinkten Präsentationen beachten (passende Compiler Flags, möglichst wenige Extensions, optimale Puffer-Größen...).

Und ich würde auch Lighttpd / FastCGI + PHP einem Apache + mod_php vorziehen, auf jeden Fall kein threaded MPM für Apache, denn ZTS(Zend Thread Safety) bremst PHP merklich aus, vor allem da Du statische Inhalte sowieso schon getrennt hast wäre das selten dämlich. Abgesehen davon kannst Du mit ZTS APC nicht verwenden.

Dann nach Möglichkeit cachen, cachen und nochmal cachen.
- Auf HTTP-Ebene: http://aktuell.de.selfhtml.org/artikel/ ... index.html, Squid Reverse-Proxy Cache, Lighttpd Optimierung, Apache Optimierung
- Auf PHP-Ebene: Opcode Caching, Content Caching (apc_fetch(), apc_store(), memcached, Smarty Cache, PEAR::Cache_Lite...)
- Auf Datenbank-Ebene: Query-Cache und überhaupt: http://dev.mysql.com/doc/refman/5.0/en/ ... ation.html

Zwei wirklich gute Präsentationen zu den Themen:
- Building Scalable PHP Applications: http://www.omniti.com/~george/talks/ZendPerf.pdf (7 MB)
- Managing PHP Performance: http://ilia.ws/files/phpworks_performance.pdf (2.7 MB)

Weitere gute Infos zu den Themen findest Du hier:
http://www.oracle.com/technology/pub/ar ... oyphp.html
http://www.oreillynet.com/pub/wlg/5155
http://talks.php.net/index.php/Performance
http://www.omniti.com/~george/talks/

Und zwei gute Bücher zum Thema:
http://www.samspublishing.com/bookstore ... 25616&rl=1
http://safari.samspublishing.com/?XmlId ... 7&a=102682 (noch nicht veröffentlicht)

Noch zwei größere Praxis-Beispiele:
Flickr: http://www.niallkennedy.com/blog/uploads/flickr_php.pdf
Yahoo: http://public.yahoo.com/~radwin/talks/y ... on2005.htm


Und die bereits genannten Benchmarks:
(Vergleiche verschiedener PHP-Versionen, mit/ohne Opcode Caches)

Ausgangsbasis 5.1.3 Optimierung: http://lerdorf.com/php/bm_files/chartimage_1.png
Ein paar Tage später: http://www.php.net/~rasmus/numbers.png

Benchmark Opcode Caches (veraltet, aber Zahlen übertragbar): http://turck-mmcache.sourceforge.net/in ... html#bench

PHP 5.1 Performance:
http://www.sebastian-bergmann.de/blog/a ... mance.html

Lighttpd/FastCGI Benchmarks: http://trac.lighttpd.net/trac/#Benchmarks


Grüße
Andreas

Edit: Posting überarbeitet, etwas neuer Text, neue Links, am besten nochmal lesen ;-)

[thorsten]

[jede Menge doller Sachen!

Wow, super Posting!
Das ist direkt ein copy´n paste in die lokale Wissensdb wert - danke dir :)

Das gilt übrigens auch generell für deine Posts Isotopp! 8)

[andreask2]

hab das Posting nochmal etwas überarbeitet/erweitert (wollte das nicht unbedingt über mehrere Postings verteilen).