nicht angemeldet
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."