Skalierung eines Webportals

Hi,

momentan habe ich an einem Problem zu knacken,
welches ich nicht vollständig lösen kann.

Kernpunkt ist die Skalierung eines relativ
umfangreichen Webprojektes auf mehrere Server
und zwar in der Form, dass auch bei - sagen
wir rund 100.000 täglichen Abrufen (Unique Visitors) -
das Webprojekt erreichbar ist und die Ladezeiten sich
im normalen Bereich befinden.

Meine ersten Überlegungen waren diesbezüglich, zunächst
Grafiken und andere "statische" Inhalte auf einen
oder mehrere Server auszulagern, um so die Belastung
zu verteilen.

Da das Projekt unter anderem auch den Upload von
Grafiken und insbesondere Dateien erlaubt, die wiederum von
Benutzer heruntergeladen werden können, werden hierfür
ebenfalls separate Server mit entsprechend großen Festplatten
eingerichtet.

Der nächste Schritt wäre, die Datenbank (MySQL) ebenfalls
auf einen separaraten Server einzurichten. Wie sieht es hier
mit der Performance von MySQL aus, sprich genügt ein Server,
der ausschließlich für die Datenbank zuständig ist, um
anfänglich geschätzt rund 20-30 Millionen Datenbankabfragen pro Tag
durchzuführen? Oder ist es sinnvoller, je nach Häufigkeit
der Art der Abfragen die Datenbank in einzelne Datenbanken
auf mehrere Server aufzuteilen? Das System ist so programmiert,
dass es nicht an einen bestimmten Datenbanktyp gebunden ist,
so dass auch z.B. Oracle eingesetzt werden könnte, falls es
wesentliche Unterschiede in der Performance oder andere
Vorteile gibt.

Der allerdings kritischste Punkt ist der Hauptserver, sprich
der Server, der alle PHP-Scripte verarbeitet und alle Ausgaben
durchführt. Ich sehe da ein großes Problem, da sowohl der Apache
als auch der PHP-Interpreter Ressourcen verbrauchen und bei zu
vielen gleichzeitigen Aufrufen keine Rechenpower mehr zur
Verfügung steht.

Hierfür konnte ich trotz Recherchen keine wirklich brauchbaren Lösungen
bzw. Informationen finden, die Last sinnvoll zu verteilen. Gibt es Systeme,
die beispielsweise anhand der Ping-Zeit eines Servers automatisch
eine anderen Server ansteuern (über IP), so dass der Besucher, wenn
ein Server überlastet sein sollte, einfach auf einen anderen Server, wobei
die Domain gleich bleiben sollte, geleitet wird?


LG,
Mike

Re: Skalierung eines Webportals

Mike schrieb:

> Informationen finden, die Last sinnvoll zu verteilen.
> Gibt es Systeme, die beispielsweise anhand der Ping-Zeit eines
> Servers automatisch
> eine anderen Server ansteuern (über IP), so dass der Besucher, wenn
> ein Server überlastet sein sollte, einfach auf einen anderen Server,
> wobei die Domain gleich bleiben sollte, geleitet wird?

Wenn du eh mehrere Server zur Verfügung hast reicht ja schon eine
zufallsbasierte Verteilung um einen relativ gleichbleibenden
Belastungsgrad zu erreichen. Dann musst du nicht nach Ping-Zeiten
aufteilen, die Ermittlung der ping-zeiten würde eh auch wieder zeit
fressen.

So sind dann alle Server im Erwartungswert gleichbelastet.

Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: Skalierung eines Webportals

Am Wed, 21 Jun 2006 09:17:26 +0200 schrieb Johannes Mueller:

> Wenn du eh mehrere Server zur Verfügung hast reicht ja schon eine
> zufallsbasierte Verteilung um einen relativ gleichbleibenden
> Belastungsgrad zu erreichen. Dann musst du nicht nach Ping-Zeiten
> aufteilen, die Ermittlung der ping-zeiten würde eh auch wieder zeit
> fressen.
>
> So sind dann alle Server im Erwartungswert gleichbelastet.
>
> Johannes


Mit der Ping-Auswertung hast du nach reichlicher Überlegung vollkommen
Recht.

Wenn ich das richtig interpretiere, könnte die Skalierung so aussehen:

(bei drei Hauptservern)

Server a > Zufallsgenerator
>-> Server b
>-> Server c

Die Weiterleitung erfolgt dann per Javascript (erfordert das Portal
sowieso), so dass nur eine simple HTML-Datei nötig ist.

Da zeigt sicht wieder, dass man manchmal den Wald vor lauter Bäumen
nicht mehr sieht.

Vielen Dank. Bestens.

Mike

Re: Skalierung eines Webportals

Mike wrote:

> Meine ersten Überlegungen waren diesbezüglich, zunächst
> Grafiken und andere "statische" Inhalte auf einen
> oder mehrere Server auszulagern, um so die Belastung
> zu verteilen.

Das ist zumindestens schnell umsetzbar und ist vor allem dann wichtig,
wenn extrem viele kleine Dateien ausgeliefert werden müssen. Dann kann
man auch darüber nachdenken einen schlanken Webserver wie thttpd
einzusetzen anstatt eines überladenen Apaches.

> Da das Projekt unter anderem auch den Upload von
> Grafiken und insbesondere Dateien erlaubt, die wiederum von
> Benutzer heruntergeladen werden können, werden hierfür
> ebenfalls separate Server mit entsprechend großen Festplatten
> eingerichtet.

Wobei hier nicht nur die Kapazität, sondern auch die
Zugriffsgeschwindigkeit wichtig ist. Es wäre ärgerlich mehrere GB -
TB an Daten zu haben, der Server aber die Anfragen nicht befriedigen
kann, weil das Laden der Daten nicht schnell genug ist. Also muss so
viel I/O Performance erreicht werden wie eben möglich (ähnlich wie
bei klassischen Datenbankservern).

> Der nächste Schritt wäre, die Datenbank (MySQL) ebenfalls
> auf einen separaraten Server einzurichten. Wie sieht es hier
> mit der Performance von MySQL aus, sprich genügt ein Server,
> der ausschließlich für die Datenbank zuständig ist, um
> anfänglich geschätzt rund 20-30 Millionen Datenbankabfragen pro Tag
> durchzuführen?

Datenbankanfragen !=3D Datenbankanfragen. Ohne die Art der Anfragen zu
kennen ist es schwer zu sagen ob ein Server ausreicht oder nicht
ausreicht. Außerdem ist die Geschwindigkeit von MySQL auch abhängig
von der Datenbankengine die verwendet wird. Für MyISAM bietet MySQL
gute Performance. Bei InnoDB ist es natürlich etwas langsamer (aber
auch hier wiederrum abhängig von der Art der Anfragen, SELECTs sind
weniger wild wie UPDATEs).

Lange Rede kurzer Sinn, ohne weitere Informationen ist keine wirklich
gute Antwort möglich.

> Oder ist es sinnvoller, je nach Häufigkeit
> der Art der Abfragen die Datenbank in einzelne Datenbanken
> auf mehrere Server aufzuteilen?

Das macht keinen Sinn. Eine Datenbank soll ja genau sowas vermeiden.
Die Anwendung greift auf die Datenbank zu um Daten auszulesen oder zu
manipulieren, alles andere soll doch bitte auf der Datenbankschicht
passieren.

Reicht ein Server nicht mehr aus um die Datenbank zu verwalten und die
Anfragen zu bedienen, so bietet MySQL zwei Mechanismen an um die Daten
auf mehrere Server zu verteilen. Replikation und Clustering, wobei das
erste nur dann tatsächlich was bringt wenn die Mehrzahl der Anfragen
aus SELECTs bestehen (Datenmanipulationen werden weiterhin auf einem
Server ausgeführt).

> Das System ist so programmiert,
> dass es nicht an einen bestimmten Datenbanktyp gebunden ist,
> so dass auch z.B. Oracle eingesetzt werden könnte, falls es
> wesentliche Unterschiede in der Performance oder andere
> Vorteile gibt.

Bist du dir sicher dass die Anwendung wirklich so datenbankunabhängig
ist? Oft genug sind SELECTs, vielleicht auch unfreiwillig, so
aufgebaut, dass ein Wechsel der Datenbank durchaus Änderung an der
Software erfordert (tolles Beispiel hierfür ist, dass Oracle ab einer
bestimmten Anzahl von Elementen in einem "WHERE col IN(element1,
element2, ...)" die Abfrage nicht mehr ausführen kann).

Nichtsdestotrotz denk ich dass man sowohl mit MySQL als auch Oracle,
PostgreSQL oder DB2 eine gute Performance erreichen kann, wenn
entsprechend optimiert wird.

> Der allerdings kritischste Punkt ist der Hauptserver, sprich
> der Server, der alle PHP-Scripte verarbeitet und alle Ausgaben
> durchführt. Ich sehe da ein großes Problem, da sowohl der Apache
> als auch der PHP-Interpreter Ressourcen verbrauchen und bei zu
> vielen gleichzeitigen Aufrufen keine Rechenpower mehr zur
> Verfügung steht.

Und hier liegt ja eine der Vorteile von PHP (wohl nicht gewollt aber in
dem Fall schon). Durch die Zustandslosigkeit ist es sehr einfach die
Anwendung zu skalieren, in dem man beliebig viele Webserver aufstellt
und davor einen Load-Balancer platziert. Der kümmert sich dann um die
Verteilung auf die einzelnen Server (was einer sehr einfachen
Architektur entspricht, nicht zu vergleichen mit der Java-Welt und der
Skalierung von Applicationservern).

> Hierfür konnte ich trotz Recherchen keine wirklich brauchbaren Lösung=
en
> bzw. Informationen finden, die Last sinnvoll zu verteilen. Gibt es System=
e,
> die beispielsweise anhand der Ping-Zeit eines Servers automatisch
> eine anderen Server ansteuern (über IP), so dass der Besucher, wenn
> ein Server überlastet sein sollte, einfach auf einen anderen Server, wo=
bei
> die Domain gleich bleiben sollte, geleitet wird?

Ja, Load-Balancer gibt es jede Menge in verschiedenen Preisklassen. Was
dabei in den meisten Fällen und bei den meisten webbasierten
PHP-Anwendungen anders implementiert werden muss ist das
Session-Handling. Ein Besucher kann bei jedem Request auf einem anderen
Webserver rauskommen, dementsprechend müssen die Sessions
serverunabhängig (z. B. in der Datenbank) verwaltet werden.
Standardmäßig sind Sessions serverabhängig weil diese einfach in
/tmp (oder einem anders eingestellten Session-Verzeichnis) gespeichert
werden.

Falls du nähere Informationen zu der Architektur der Software und den
Datenbankabfragen bieten kannst, kann man dir bestimmt auch besser
helfen. Gerne kannst du dich auch per E-Mail melden.

Viele Grüße,
Glenn

Re: Skalierung eines Webportals

Mike wrote:

> Wenn ich das richtig interpretiere, könnte die Skalierung so aussehen:
> (bei drei Hauptservern)
> Server a > Zufallsgenerator
> >-> Server b
> >-> Server c

Wenn der Zufallsgenerator die Requests wirklich so verteilt, dass nicht
auf einmal 10 Requests, eben zufällig, auf dem gleichen Server
landen... :-).

> Die Weiterleitung erfolgt dann per Javascript (erfordert das Portal
> sowieso), so dass nur eine simple HTML-Datei nötig ist.

Was extrem unschön ist, weil dazu schon relativ viele Daten verschickt
werden müssen und der Besucher länger warten muss bis tatsächlich
was zu sehen ist (schließlich müssen zwei vollständige Requests
ausgeführt werden bis was zu sehen ist).

Besser ist dann schon ein . Aber im
Vergleich zu einer sauberen Lösung wirklich unelegant.

Viele Grüße,
Glenn

Re: Skalierung eines Webportals

Mike wrote:

> Die Weiterleitung erfolgt dann per Javascript (erfordert das Portal
> sowieso), so dass nur eine simple HTML-Datei nötig ist.

Wenn Du es wirklich richtig und gut machen willst frag mal google resp.
wikipedia nach "Loadbalancing". Da wirst Du schnell erfahren wie der
korrekte Weg auszusehen hat. Voraussetzung fuer Loadbalancing sind aber
recht umfangreiche Rechte auf den zu nutzenden Servern.

Aber das ist hier wirklich maechtig OT!

MfG, Ulf

Re: Skalierung eines Webportals

Mike schrieb:

> Der nächste Schritt wäre, die Datenbank (MySQL) ebenfalls
> auf einen separaraten Server einzurichten. Wie sieht es hier
> mit der Performance von MySQL aus, sprich genügt ein Server,
> der ausschließlich für die Datenbank zuständig ist, um
> anfänglich geschätzt rund 20-30 Millionen Datenbankabfragen pro Tag
> durchzuführen? Oder ist es sinnvoller, je nach Häufigkeit
> der Art der Abfragen die Datenbank in einzelne Datenbanken
> auf mehrere Server aufzuteilen? Das System ist so programmiert,
> dass es nicht an einen bestimmten Datenbanktyp gebunden ist,
> so dass auch z.B. Oracle eingesetzt werden könnte, falls es
> wesentliche Unterschiede in der Performance oder andere
> Vorteile gibt.

Das kann man so ad hoc nicht sagen, ohne die Anforderungen genau zu
kennen. So pauschal könnte man genauso empfehlen, deine Queries zu
optimieren.
Du kannst das DB-System auch Clustern um die Rechenleistung zu erhöhen.
Ich denke bei vernüftiger Hardware und Konfiguration sollte das alles
kein Problem sein. Sollte deine Applikation modularisierbar sein,
verteile die Daten auf mehrere DBs. Das mache z.b. sehr gerne.

> Hierfür konnte ich trotz Recherchen keine wirklich brauchbaren Lösungen
> bzw. Informationen finden, die Last sinnvoll zu verteilen. Gibt es Systeme,
> die beispielsweise anhand der Ping-Zeit eines Servers automatisch
> eine anderen Server ansteuern (über IP), so dass der Besucher, wenn
> ein Server überlastet sein sollte, einfach auf einen anderen Server, wobei
> die Domain gleich bleiben sollte, geleitet wird?

Mir würde auf Schlag einfallen:
- LoadBalancer
- verteiltes Rechnen

Gruß,
Torsten

Re: Skalierung eines Webportals

Am Wed, 21 Jun 2006 08:24:41 +0200 schrieb
Mike:
^- bitte vollständigen namen.

Hallo,

Glenn hat dir bereits in
Message-ID:
<1150876711.505913.157960@y41g2000cwy.googlegroups.com>
ja einige Vorschläge und Fragen zur Verfügung gestellt.

> Der allerdings kritischste Punkt ist der Hauptserver, sprich
> der Server, der alle PHP-Scripte verarbeitet und alle Ausgaben
> durchführt. Ich sehe da ein großes Problem, da sowohl der Apache
> als auch der PHP-Interpreter Ressourcen verbrauchen und bei zu
> vielen gleichzeitigen Aufrufen keine Rechenpower mehr zur
> Verfügung steht.
>
> Hierfür konnte ich trotz Recherchen keine wirklich brauchbaren Lösungen
> bzw. Informationen finden, die Last sinnvoll zu verteilen. Gibt es Systeme,
> die beispielsweise anhand der Ping-Zeit eines Servers automatisch
> eine anderen Server ansteuern (über IP), so dass der Besucher, wenn
> ein Server überlastet sein sollte, einfach auf einen anderen Server, wobei
> die Domain gleich bleiben sollte, geleitet wird?

Ich persönlich bevorzuge als Loadbalancer Pen
http://siag.nu/pen/

Pen folgt keinem Round-Robin-Verfahren: Vielmehr merkt
er sich, welchen Client er zu welchem Server vermittelt hat, und behält
diese Zuteilung bei. Das ist für Web-Angebote, die mit Sessions arbeiten,
wichtig.

Die Konfiguration ist einfach
pen -l /var/log/pen.log loadb:80 web1:80 web2:80

Der Rechner lauscht ab sofort auf Port 80 und verteilt die dort eingehenden
Pakete auf die Server »web1« und »web2«.

hth

r23

--
http://www.myoos.de/fraktal/zoom.php

Re: Skalierung eines Webportals

Am 21 Jun 2006 00:58:31 -0700 schrieb Glenn Kusardi:

> Mike wrote:
>

> Das ist zumindestens schnell umsetzbar und ist vor allem dann wichtig,
> wenn extrem viele kleine Dateien ausgeliefert werden müssen. Dann kann
> man auch darüber nachdenken einen schlanken Webserver wie thttpd
> einzusetzen anstatt eines überladenen Apaches.

> Wobei hier nicht nur die Kapazität, sondern auch die
> Zugriffsgeschwindigkeit wichtig ist. Es wäre ärgerlich mehrere GB -
> TB an Daten zu haben, der Server aber die Anfragen nicht befriedigen
> kann, weil das Laden der Daten nicht schnell genug ist. Also muss so
> viel I/O Performance erreicht werden wie eben möglich (ähnlich wie
> bei klassischen Datenbankservern).

Die Upload/Download Thematik habe ich etwas grob formuliert. Es ist
kein durchgehender Wechsel zwischen Up-und Download, sondern überwiegend
der Download, vergleichbar z.B. mit einem Downloadshop, wo das Produkt
einmalig hochgeladen und dann vom Kunden nach dem Kauf heruntergeladen
werden kann. Ich denke Prozentual wird es bei 10% Upload, 90% Downlaod
liegen.


> Datenbankanfragen != Datenbankanfragen. Ohne die Art der Anfragen zu
> kennen ist es schwer zu sagen ob ein Server ausreicht oder nicht
> ausreicht. Außerdem ist die Geschwindigkeit von MySQL auch abhängig
> von der Datenbankengine die verwendet wird. Für MyISAM bietet MySQL
> gute Performance. Bei InnoDB ist es natürlich etwas langsamer (aber
> auch hier wiederrum abhängig von der Art der Anfragen, SELECTs sind
> weniger wild wie UPDATEs).
>
> Lange Rede kurzer Sinn, ohne weitere Informationen ist keine wirklich
> gute Antwort möglich.

Engine ist MyISAM. Es werden zum größten Teil reine SELECTs durchgeführt,
die per Schlüsselid abgefragt werden, d.h. keine LIKEs usw. Komplexe
Abfragen kommen nur bei der Suche und der Accountverwaltung vor.
Die restlichen Daten werden in einer kodierten Variable gehalten, die
bei bedarf entschlüsslelt wird.

> Reicht ein Server nicht mehr aus um die Datenbank zu verwalten und die
> Anfragen zu bedienen, so bietet MySQL zwei Mechanismen an um die Daten
> auf mehrere Server zu verteilen. Replikation und Clustering, wobei das
> erste nur dann tatsächlich was bringt wenn die Mehrzahl der Anfragen
> aus SELECTs bestehen (Datenmanipulationen werden weiterhin auf einem
> Server ausgeführt).

Meine ursprüngliche Idee war, die einzelnen Tabellen der Datenbank
auf unterschiedliche Server aufzuteilen. Wenn ich weiss, dass
zum größten Teil z.B. Tabelle A abgefragt wird und die restlichen
Tabellen nur rudimentär (Anschrift ändern, Passwort ändern, usw...),

Replication verfolgt ja das Master/Sklave-Prinzip, die Sicherheit
der Daten, beispielsweise wenn Daten nicht vollständig übertraggen werden,
ist nicht gegeben, auf jeden Fall nicht bei MyISAM. InnoDB löst
zwar dieses Problem, aber das wieder auf Kosten der Performance.



> Bist du dir sicher dass die Anwendung wirklich so datenbankunabhängig
> ist? Oft genug sind SELECTs, vielleicht auch unfreiwillig, so
> aufgebaut, dass ein Wechsel der Datenbank durchaus Änderung an der
> Software erfordert (tolles Beispiel hierfür ist, dass Oracle ab einer
> bestimmten Anzahl von Elementen in einem "WHERE col IN(element1,
> element2, ...)" die Abfrage nicht mehr ausführen kann).
>
> Nichtsdestotrotz denk ich dass man sowohl mit MySQL als auch Oracle,
> PostgreSQL oder DB2 eine gute Performance erreichen kann, wenn
> entsprechend optimiert wird.

Ich habe hierfür einen Wrapper geschrieben, der die entsprechenden
Anweisungen an die Datenbank steuert, so dass ich bei der
Eingabe von SSF bei MySQL beispielsweise ein SELECT * FROM erhalte.
Ist von der Einarbeitung über die Kurzbefehle etwas aufwendiger,
lässt sich aber komfortabel managen.

> Und hier liegt ja eine der Vorteile von PHP (wohl nicht gewollt aber in
> dem Fall schon). Durch die Zustandslosigkeit ist es sehr einfach die
> Anwendung zu skalieren, in dem man beliebig viele Webserver aufstellt
> und davor einen Load-Balancer platziert. Der kümmert sich dann um die
> Verteilung auf die einzelnen Server (was einer sehr einfachen
> Architektur entspricht, nicht zu vergleichen mit der Java-Welt und der
> Skalierung von Applicationservern).

> Ja, Load-Balancer gibt es jede Menge in verschiedenen Preisklassen. Was
> dabei in den meisten Fällen und bei den meisten webbasierten
> PHP-Anwendungen anders implementiert werden muss ist das
> Session-Handling. Ein Besucher kann bei jedem Request auf einem anderen
> Webserver rauskommen, dementsprechend müssen die Sessions
> serverunabhängig (z. B. in der Datenbank) verwaltet werden.
> Standardmäßig sind Sessions serverabhängig weil diese einfach in
> /tmp (oder einem anders eingestellten Session-Verzeichnis) gespeichert
> werden.

Genau nach so etwas habe ich gesucht. Momentan sind die Sessions allerdings
serverseitig, da die Portalentwicklung ursprünglich nicht auf diese Größe
wachsen sollte und wir davon ausgegangen sind, dass ein hoch
dimensionierter Server ausreichen würde.

Wie steht es mit der von Johannes angesprochenen Möglichkeit, über einen
Zufallsgenerator die Auslastung zu verteilen? Wenn ein perfomanter
Server als Schnittstelle fungiert und per Zufallsgenerator
oder per Counting (lässt z.B. nur eine bestimme Anzahl User auf einen
Server und verteilt gleichmäßig auf die Server), wäre die Auslastung
der Server relativ konstant und könnte jederzeit erweitert werden.

Vom Prinzip her das gleiche wie ein Load-Balancer, nur in Eigenregie
und ohne die erwähnte Session-Problematik.

Re: Skalierung eines Webportals

Mike schrieb:
>
> Kernpunkt ist die Skalierung eines relativ
> umfangreichen Webprojektes auf mehrere Server
> und zwar in der Form, dass auch bei - sagen
> wir rund 100.000 täglichen Abrufen (Unique Visitors) -
> das Webprojekt erreichbar ist und die Ladezeiten sich
> im normalen Bereich befinden.

100.000 PIs oder 100.000 Besucher? Das ist schon ein
Unterschied. Rund 100.000 PIs pro Tag steckt unser
nicht unbedingt moderner Server (Dual P3 1000 MHz, 2 GB RAM)
jedenfalls noch spielend weg, bei nicht zu wenig PHP Code
und MySQL Datenbankabfragen.
Das sagt natürlich wenig aus. Jedes Projekt ist anders
und verbraucht die Ressourcen anders. Will sagen, man
kann schlecht allgemein gültige Aussagen treffen.

> Meine ersten Überlegungen waren diesbezüglich, zunächst
> Grafiken und andere "statische" Inhalte auf einen
> oder mehrere Server auszulagern, um so die Belastung
> zu verteilen.

Wobei das natürlich am wenigsten Ressourcen verbraucht.
Schlecht ist die Idee trotzdem nicht, da so eine Menge
Speicher verbrauchende Prozesse eingespart werden könnten.
Und dieser light httpd ist sicher eine gute Wahl dafür.

> Der nächste Schritt wäre, die Datenbank (MySQL) ebenfalls
> auf einen separaraten Server einzurichten. Wie sieht es hier
> mit der Performance von MySQL aus, sprich genügt ein Server,
> der ausschließlich für die Datenbank zuständig ist, um
> anfänglich geschätzt rund 20-30 Millionen Datenbankabfragen pro Tag

OK, also durchaus mehr als 300 Abfragen pro Sekunde.
Das ist nicht wenig. Aber es kommt sehr stark auf die Art
der Abfragen an. Man kann hier IMO am allermeisten optimieren.
Bei der großen Anzahl würde sich z.B. sehr viel RAM lohnen.
So viel, daß man den MySQL key_buffer ausreichend groß machen
kann, damit dort alle Indexe reinpassen. Das ist natürlich
nur eine Sache. Mehr dazu, wenn Du alles zusammen hast, und
Fragen zur Optimierung hast, nebenan [1].

Ein extra Server, nur für die Datenbank, ist aber sicher sinnvoll.

> durchzuführen? Oder ist es sinnvoller, je nach Häufigkeit
> der Art der Abfragen die Datenbank in einzelne Datenbanken
> auf mehrere Server aufzuteilen?

Da kenne ich mich nicht so aus. Aber nebenan bzw. im MySQL
Manual findest Du sicher viel dazu.

> Der allerdings kritischste Punkt ist der Hauptserver, sprich
> der Server, der alle PHP-Scripte verarbeitet und alle Ausgaben
> durchführt. Ich sehe da ein großes Problem, da sowohl der Apache
> als auch der PHP-Interpreter Ressourcen verbrauchen und bei zu
> vielen gleichzeitigen Aufrufen keine Rechenpower mehr zur
> Verfügung steht.

Die Datenbank ist schonmal weg. So hat der Server wesentlich weniger
zu kämpfen. Viel CPU wirst Du nicht mehr verbrauchen, vorrausgesetzt
Du machst dahingehend nicht aufwändiges in PHP (Bilder verkleinern z.B.).
Der Apache läßt sich auch noch weitgehend tunen. Dazu siehe z.B.
http://kris.koehntopp.de/artikel/webtune/

Ansonsten halt viel RAM einbauen.

[Loadbalancing]

Da kenen ich mich leider auch nicht aus.


Gruß
JPM

[1] de.comp.datenbanken.mysql

Re: Skalierung eines Webportals

Mike wrote:
> Kernpunkt ist die Skalierung eines relativ
> umfangreichen Webprojektes auf mehrere Server
> und zwar in der Form, dass auch bei - sagen
> wir rund 100.000 täglichen Abrufen (Unique Visitors) -
> das Webprojekt erreichbar ist und die Ladezeiten sich
> im normalen Bereich befinden.

So pauschal lässt sich das alles nicht sagen, dazu muss man ein paar
Eckdaten kennen. Auch die PI sagen nicht viel aus wenn sich diese zu
bestimmten Zeiten häufen (Peakzeiten je nach Branche / Zielgruppe mgl.
12-14 Uhr und 17-19 Uhr oder auch nach 20 Uhr). Wie zwingend ist die
Erreichbarkeit (man kann die max. clients / max connections
runterdrehen, dann kommen zwar ein paar nicht beim ersten Mal drauf aber
dafür stirbt der Server nicht)

1. Loadbalancing wurde schon genannt - siehe auch LVS
2. Datenbank entsprechend der Applikation wählen (fast nur Lesen ->
Postgres, viel schreiben -> MySQL) - Datenbankhost entsprechend wählen
(Dual Opteron, viiiieeel Ram) und entsprechend konfigurieren.
3. Optimierung von Apache, PHP (man glaubt nicht, wieviel Potential bei
Standardinstallationen verschenkt wird)

Naja, finally kommts dann noch aufs Budget an. :-)

gruß, Frank

Re: Skalierung eines Webportals

Mike schrieb:

....
> Die Upload/Download Thematik habe ich etwas grob formuliert. Es ist
> kein durchgehender Wechsel zwischen Up-und Download, sondern überwiegend
> der Download, vergleichbar z.B. mit einem Downloadshop, wo das Produkt
> einmalig hochgeladen und dann vom Kunden nach dem Kauf heruntergeladen
> werden kann. Ich denke Prozentual wird es bei 10% Upload, 90% Downlaod
> liegen.
>

Bei den Systemen, mit denen ich gearbeitet hatte funktionierten so.

Proxy -> Webserver -> CMS
Proxy -> Webserver -> DB
-> Webserver -> DB

Die Proxies konnten jeden Webserver auswählen und die Webserver
konnten jede DB auswählen.

Das CMS "lief" nur auf einem Server.

Natürlich waren die Daten so nicht sofort aktuell sondern mussten
synchronisiert werden - gerade Uploads (Filme, Zip) dauerten eine Weile
bis sie auf allen Servern waren - was oft ziemlich mühsam war, dem
Benutzer bei zu bringen...

Aber ich finde, man braucht schon wirklich sehr viel Traffic, damit
sich ein Loadbalancing lohnt... Das Internet wird ja nicht schneller
so. :-)

>
> > Datenbankanfragen !=3D Datenbankanfragen. Ohne die Art der Anfragen zu
> > kennen ist es schwer zu sagen ob ein Server ausreicht oder nicht
> > ausreicht. Außerdem ist die Geschwindigkeit von MySQL auch abhängig
> > von der Datenbankengine die verwendet wird. Für MyISAM bietet MySQL
> > gute Performance. Bei InnoDB ist es natürlich etwas langsamer (aber
> > auch hier wiederrum abhängig von der Art der Anfragen, SELECTs sind
> > weniger wild wie UPDATEs).
> >
> > Lange Rede kurzer Sinn, ohne weitere Informationen ist keine wirklich
> > gute Antwort möglich.
>
...

> >
> > Nichtsdestotrotz denk ich dass man sowohl mit MySQL als auch Oracle,
> > PostgreSQL oder DB2 eine gute Performance erreichen kann, wenn
> > entsprechend optimiert wird.

Ich mag Oracle nicht so sehr bei Webanwendungen. MySQL und Postgres
sind sicherlich auch angebracht.
Schliesslich braucht z.b google IMHO MySQL Datenbanken. Und da sind
doch sehr sehr viel Informationen drinne, die eigentlich sehr schnell
geliefert werden.

...
>
> > Ja, Load-Balancer gibt es jede Menge in verschiedenen Preisklassen. Was
> > dabei in den meisten Fällen und bei den meisten webbasierten
> > PHP-Anwendungen anders implementiert werden muss ist das
> > Session-Handling. Ein Besucher kann bei jedem Request auf einem anderen
> > Webserver rauskommen, dementsprechend müssen die Sessions
> > serverunabhängig (z. B. in der Datenbank) verwaltet werden.
> > Standardmäßig sind Sessions serverabhängig weil diese einfach in
> > /tmp (oder einem anders eingestellten Session-Verzeichnis) gespeichert
> > werden.

Ja, das Session-Handling ist ein ganz lustiger Kumpane :-)

..

>
> Wie steht es mit der von Johannes angesprochenen Möglichkeit, über ei=
nen
> Zufallsgenerator die Auslastung zu verteilen? Wenn ein perfomanter
> Server als Schnittstelle fungiert und per Zufallsgenerator
> oder per Counting (lässt z.B. nur eine bestimme Anzahl User auf einen
> Server und verteilt gleichmäßig auf die Server), wäre die Auslastung
> der Server relativ konstant und könnte jederzeit erweitert werden.

Ja das ist gut. Es geht ja nicht darum "zu Wechseln, wenn ein Server
voll ist", sondern die Last gleichmässig zu verteilen.
Nach welchem Schlüssel das am besten verteilt wird, getraue ich aber
nicht zu sagen - ich fürchte längere Diskussionen mit
Mathematikern...

Re: Skalierung eines Webportals

Oliver Meister wrote:
> Schliesslich braucht z.b google IMHO MySQL Datenbanken. Und da sind
> doch sehr sehr viel Informationen drinne, die eigentlich sehr schnell
> geliefert werden.

Für welche Anwendungen benutzt Google denn MySQL? Für die Suche
ist es ein eigenes System, kein MySQL.

Re: Skalierung eines Webportals

Mal quer in den Thread rein: Apache und lighttpd bieten
primitives Loadbalancing an.

Entweder via Proxys, oder indem ein FastCGI-Request auf
verschiedene Adressen verteilt wird.

http://www.lighttpd.net/documentation/fastcgi.html#load-bala ncing
http://www.lighttpd.net/documentation/proxy.html


http://httpd.apache.org/docs/2.2/misc/rewriteguide.html (Load
Balancing)


--
Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/