nicht angemeldet
Halihallo Andreas
Jedenfalls war da ein Vergleichstest zw. einem Apple xServe (mit G4(7450), 1Ghz prozessor) gegen Dell (x86, Pentium III 1,4 Ghz, SCSI) beide mit 256 MB DDRRAM, lagen beide um 5000 EUR.
Apache konnte bei beiden ca. 1300 Seiten pro Sekunde ausliefern(html),
Ja, wobei wir ja insbesondere mod_perl testen wollten.
Ist doch wie CGI, oder?
Das eine hat mit dem anderen weniger zu tun (bzw. ersetzt es nicht). auch in mod_perl gibt's die CGI-Schnittstelle. Das einzige, was mod_perl macht, ist, dass das CGI-Script nicht als neuen Prozess gestartet wird, sondern dass alle Scripts über denselben mod_perl Prozess abgearbeitet werden. mod_perl ist die Schnittstelle zwischen Apache-Webserver und Script. Authentification, Sessionmanagement, gemeinsamer Speicher, schnellerer start-up der Scripts, da der Interpreter bereits im Speicher ist... etc. etc. etc.
Bei CGI Scripten lag der Dell noch bei 200/s, bei PHP/MySQL 80/s, bei SSL 65/s(wobei sie das irgendwie mit "keepalive" auf ca. 400 steigern konnten, aber das habe ich nicht richtig verstanden - schade eigentlich, könnte ich gut gebrauchen ;-)).
Worauf ich aber hinaus will, das sind keine geteilten/gehosteten Server, sondern eigene relativ aktuelle und hochwertige Modelle. bei den Servern wie wir das versucht hatten, die waren zum einen garantiert erheblich biliger und langsamer,
Die Technik musste den Server, wo ich gehost werde, wohl wegen mir mit RAM auf 1GB aufrüsten, 512MB Std, 733MHz AMD (ich glaube Dual?). Naja, die schnellsten sind's bestimmt nicht...
Das glaube ich auch ;-) aber wie ist das eigentlich, braucht men hierfür überhaupt so viel Ram? Ich meine, es handelt sich ja um GET-Requests, und ausgeliefert wird ein 1x1.gif, oder?
Nun, man kann nie genug haben :-)
Der Tag alleine bräuchte nicht soviel Speicher. Jedoch läuft die Synchronisation auf dem selben Rechner und dieses Programm braucht dann schon etwas mehr Speicher, da sozusagen eine Main-Memory-Database betrieben wird, um die Daten zu analysieren (Voranalyse) und die Sync-Datenstruktur aufzubauen, die dann auf den Hauptserver übertragen wird. Die Server für den Statistik-Tag benutzt keine mysql-Datenbank, diese liegt auf dem Hauptserver...
Das sollte doch in beide Richtungen höchtens 0,5 KB Übertragungsvolumen ausmachen, oder? Wird da großartig was in den Arbeitsspeicher geladen?
Jeweils die Statistik mehrerer Websites/Pages über eine Stunde; jeder Request. Diese geben schon eine nette Main-Memory-Tabelle. Dann wird alles analysiert und auf Requests/Stunde kummuliert, diese Daten werden dann übertragen. Der Transport zum Hauptserver besteht dann nur noch aus 8-10 Statistikeinträgen pro Page und Stunde. Durch die Voranalyse wird der Hauptserver nicht so sehr belastet.
Naja, ich weiß jetzt nicht wie rechenintensiv das schreiben in eine Log-Datei ist, vermutlich lächerlich. Und das auslesen und umwandeln der HTTP-HEADER Daten dürfte auch nicht so wild sein.
Ja, der Tag alleine ist relativ simpel, obwohl bereits der ca. 20A4 Seiten Code hat. Die Sync braucht aber schon etwas mehr Performance. Aber da die Statistik-Server keine RDBMS verwenden und auf Flat-File-Basis arbeiten, ist die Performance doch ziemlich gut.
außerdem teiltn wir die Performance mit alen anderen Kunden auf dem Server, also waren die Ergebnisse realistisch.
Stimmt. Wobei ich Samstag Nacht nicht grad relevant für Stat. Tests halte :-)
Was ein schlechtes Licht auf die Hardware, Anbindung oder was weiß ich Deines Providers wirft!
Ja, da muss ich dir recht geben :-)
Ich verstehe zwar nicht, warum Server mit so schwachen Prozessoren so teuer sein können, ich denke man bekommt das schon erheblich schneller hin, z.B. mit 2 Xeon oder Athlon MP, oder noch besser man wartet auf den 64Bit von AMD.
Wenn man das hat ist man schon recht flott denke ich, sonst hilft nur noch Load-balancing oder Clustering,
Ja, Load-Balancing wird dann interessant, wenn man 2000/s aushalten muss... Dann stellt man 10 redundant ausgelegte Rechner hinter ein load-balancer, der eine virtuelle IP hat und die Requests gleichmässig auf die 10 Rechner verteilt und fertig...
Wenn einer der oben beschriebenen Rechner über 1300 Seiten pro Sekunde ausliefern soll, würde ich mal behaupten, mit etwas schnellerer Hardware, wie beshreiben schafft man locker über 2000! Und wenn man sich dan noch den "Logging-Server" in C++ schreibt kann man das nochmal erheblich steigern denke ich mal.
Ja, an Load-Balancing muss ich auch noch nicht denken. Es ist ja auch eine Kostenfrage... Ich denke, dass wir gut mit den "konventionellen" Methoden auskommen. Ich meine, stell dir mal diese Zahlen vor: 2000/s => 5.2 Milliarden Requests pro Monat... Darauf muss man schon mal kommen...
Wobei Google mit dem Cluster von Billigrechnern(Celeron!) anscheinend auch ziemlich gut fährt, interessantes Thema!
die 80%-Philosophie... Für die letzten 20% Zahlt man soviel, wie für die ersten 80%. Da kauft man sich lieber zweimal die 80% und kommt auf 160%, als wenn man einen 100%-er kauft...
Die 2. Sache ist die mit CGI gegen Apache, wie Du siehst kannst Du Deine Performance durch eine reine Apache-Lösung nochmal fast ver-sieben-fachen! Und wenn das nicht reicht, ich denke auch das performanteste wird sein sich einen eigenen schlanken "HTTP-Server" in C++ zu programmieren, das dürfte nochmal erheblich schneller sein, denn Du brauchst den Apache ja eigentlich gar nicht, es geht ja nur ums Loggen.
...und analysieren, ja. Jetzt müsste ich nur noch wissen, wie ich Sockets und Daemonen mit C++ programmiere :-)
Aber mit Zeit kommt Rat :-)
Bisher habe ich grad mal gelernt, wie ich txt-Dateien mit C++ bearbeiten kann und schon da scheiterts. Getestet unter cygwin/gcc beim einlesen einer txt-Datei: "STATUS_ACCESS_VIOLATION" - handle_exeption... Naja, wenn ich die Zeit habe, widme ich mich diesem Problem. Jetzt stehen noch einige pendentere Sachen auf meiner 4-A4 Seiten todo-Liste :-((
Viele Grüsse
Philipp