nicht angemeldet
MySQL Geschwindigkeit
Hallo,
bei Datenbankservern wie z.B. MySQL (und einen/mehrere Webserver auf Apache+PHP Basis) gibt es ja typischerweise zwei verschiedene Ansätze.
Enweder man hält die Daten lokal auf jedem Rechner und kann die Datenbank über localhost ansprechen. Oder man hat einen Datenbankserver, welcher über LAN angesprochen wird.
Meine Frage ist nun: Das Netzwerk hat ja eine gewisse Latenzzeit. Nehmen wir an, das wären ca. 10 Millisekunden, die ein typisches Packet vom Webserver zum Switch, dann zum DB-Server und wieder zurück braucht. Schlimmer noch: der Apache-Prozess steht für diese Zeit ebenfalls lahm und wartet auf die Antwort des db Servers; also wäre das Netzwerk ein Flaschenhals und nicht der db server.
Wäre man da nicht auf 100 Datenbankabfragen pro Sekunde beschränkt? Wäre es dann nicht logischer alle Daten auf die Webserver zu replizieren und dort über localhost den MySQL server zu kontaktieren? bzw. wie kann man das anders lösen (wäre ja ein riesenaufwand das ständig synchron zu halten [Replikation]).
Mich nimmt einfach wunder, wie Sites wie z.B. wikipedia o.ä. mehrere tausend zugriffe pro sekunde mit db access realisieren. das geht für mein Verständnis nicht über das netzwerk, es sei denn man hat duzende von Rechnern.
Was meint ihr dazu?
Grüsse
Max
-
Hi,
wenn du dem Webserver genügend Hardware-Resourcen spendieren kannst um Apache/IIS und eine DB gleichzeitig zu befriedigen (64bit, 32G+ Ram),
dann kann es schon schneller sein.Jedoch in einem ausreichend ausgebauten Netzwerk sind die Verluste für die InterComm Webserver - DBServer recht gering.
Zur Not kannst du auch einen Cluster aufsetzen, wenn es sein muss.
Das Bottleneck (ich sehe es tagtäglich) ist nicht, dass der DBServer nur über eine Gigabit Lan dranhängt sondern das die Programmierung einfach Scheisse ist. Gottseidank verdiene ich mein Geld damit, solche Probleme zu beheben. :)
mehrere tausend zugriffe pro sekunde mit db access
Ich glaube nicht, dass sie Access als Datenbank benutzen. Und b) sie habben die Infrastruktur (e.g. Cluster).
BTW: die Replikation von DB Daten auf einen Webserver nimmt annähernd genauso viel Resourcen weg wie der Abruf der Daten selbst. Von daher ...
Was wolltest du nun eigentlich wissen?
Ciao, Frank
-
Hallo,
danke für deine Antwort.
Jedoch in einem ausreichend ausgebauten Netzwerk sind die Verluste für die InterComm Webserver - DBServer recht gering.
Das ist meiner Meinung nach nicht so - für meine Überlegung siehe unten.
Ich habe es mal lokal bei mir getestet. Die Latenzzeit für ein Packet vom Webserver zum Datenbankserver und zurück ist in meinem 100Mbit LAN ca. 1.5ms.
Wenn also zwischen Webserver und DB-Server eine stetige TCP Verbindung aufgebaut wird, dann können maximal 667 Packete hin und zurück (über eine Verbindung). Wenn der Webserver also auf die Antwort des DB-Servers warten muss (und davon kann ja ausgegangen werden), ist ein Webserver-Prozess auf 667 Requests/Sekunde beschränkt (nicht, dass das klein wäre, aber trotzdem...).
Anders wäre es, wenn der Webserver nicht warten müsste, dann geht mehr durch. Deswegen aus die Idee mit lokaler Datenbank.
Zur Not kannst du auch einen Cluster aufsetzen, wenn es sein muss.
Ist halt ein Kostenpunkt. Diese Diskussion ist aber für mich eher theoretisch. Mich interessiert es einfach, wie es mit - sagen wir 4 - Rechnern (3xWebserver und 1xDB-Server) möglich ist mehr als 5000 Requests/Sekunde zu verarbeiten.
Das Bottleneck (ich sehe es tagtäglich) ist nicht, dass der DBServer nur über eine Gigabit Lan dranhängt sondern das die Programmierung einfach Scheisse ist. Gottseidank verdiene ich mein Geld damit, solche Probleme zu beheben. :)
Das glaub ich gerne.
BTW: die Replikation von DB Daten auf einen Webserver nimmt annähernd genauso viel Resourcen weg wie der Abruf der Daten selbst. Von daher ...
Da wirst du wohl recht haben.
Grüsse,
Max
-
Moin!
Ich habe es mal lokal bei mir getestet. Die Latenzzeit für ein Packet vom Webserver zum Datenbankserver und zurück ist in meinem 100Mbit LAN ca. 1.5ms.
Wenn also zwischen Webserver und DB-Server eine stetige TCP Verbindung aufgebaut wird, dann können maximal 667 Packete hin und zurück (über eine Verbindung). Wenn der Webserver also auf die Antwort des DB-Servers warten muss (und davon kann ja ausgegangen werden), ist ein Webserver-Prozess auf 667 Requests/Sekunde beschränkt (nicht, dass das klein wäre, aber trotzdem...).
Und dann gibts mindestens 100 parallele Webserver-Prozesse, also mithin 66700 parallele Requests pro Sekunde auf der Datenbank. Das ist dann schon recht viel, würde ich meinen.
Mich interessiert es einfach, wie es mit - sagen wir 4 - Rechnern (3xWebserver und 1xDB-Server) möglich ist mehr als 5000 Requests/Sekunde zu verarbeiten.
Wie gesagt: Parallelität ist das Zauberwort. Wenn ein Prozess eine, zehn oder hundert Millisekunden auf eine Antwort warten muß, weil die Signale nicht schneller übertragbar sind, kann man trotzdem hundert, tausend oder eine Million Prozesse parallel warten lassen. Und schon kommt es nicht mehr auf die Dauer an, die man wartet, sondern nur noch auf die Datenmenge, die pro Zeit geliefert werden kann. Ob diese Daten dann vor kürzerer oder längerer Zeit angefordert wurden, wird irrelevant.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hallo,
danke für die sehr aufschlussreiche Antwort.
Und dann gibts mindestens 100 parallele Webserver-Prozesse, also mithin 66700 parallele Requests pro Sekunde auf der Datenbank. Das ist dann schon recht viel, würde ich meinen.
Dann platzen die Webserver aus den RAM-Nähten, da diese Webserver-prozesse so ziemlich den ganzen Speicher fressen... Aber dieser lässt sich ja bekanntlich soweit ausbauen.
Wie gesagt: Parallelität ist das Zauberwort. Wenn ein Prozess eine, zehn oder hundert Millisekunden auf eine Antwort warten muß, weil die Signale nicht schneller übertragbar sind, kann man trotzdem hundert, tausend oder eine Million Prozesse parallel warten lassen. Und schon kommt es nicht mehr auf die Dauer an, die man wartet, sondern nur noch auf die Datenmenge, die pro Zeit geliefert werden kann. Ob diese Daten dann vor kürzerer oder längerer Zeit angefordert wurden, wird irrelevant.
Danke für den Tipp.
Grüsse
Max
-
-
-