nicht angemeldet
HI!
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.
Wolltst du auch http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.html benutzen?
Vielleicht könnte man auf diese Weise direkt in mySQL loggen, und wen man eine persistente Verbindung offen hält ist das vermutlich noch nichtmal so langsam!
Aber trotzdem würde ich es probieren direkt vom Apachen machen zu lasen, denn der apache bekommt schließlich alle Informationen, und gibt die seinerseits an ein PERL-Script weiter, man muß halt nur wissen wie man dran kommt.
Habe aber noch 2 Ideen:
1. Man könnte als Log-Format direkt INSTERT-Statements kreieren, so bräuchtest Du nur noch den kompletten Insert am Ende des Tages(um 4 Uhr morgens per Cronjob)
per batch-Mode in mySQL schreiben lassen, also das log Format muß dann in etwa so aussehen(habe sowas noch nie gemacht, also vermutlich mächtig falsch ;-)):
LogFormat "(%h,%l,%u,%t,"%r",%>s,%b,"%{Referer}i","%{User-agent}i")," combined
CustomLog log/acces_log combined
Das sollte dann eine Logfle genereiren mit etwa folgendem Inhat:
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
(bla,bla,bla,...blub),
...
Was Du dann noch machst ist diese Datei in einen String zu lesen, nenne den jetzt mal $log, dann brauchst Du für den Cron nur noch:
$complete_sql_statement = "INSERT INTO log_table (spalte_bla,spalte_bla,spalte_bla,...spalte_blub) VALUES $log";
Und dieses übergibts Du noch eben an die Standardeingabe von mysql und hast so massenhaft Daten in kürzester Zeit in der DB. "Filtern"... muß man möglichst schon bem Apache.
2. Möglichkeit wäre, evtl direkt die Datendatei von MYSQL als logfile - Format zu schreiben, ud die eben nur umkopieren, aber da weiß ich nicht ob das geht.
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...
wie gesagt würde ich so viel wie möglich im Apache machen, und we die Tagesdaten in der DB sind denke ich, da sind gerade große Datenmengen besser zu analysieren, oder?
Was meinst Du mit "sync-Datenstruktur"?
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.
Ach so!
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.
Das kann ich mir gar nicht vorstellen(k.A., nur so vom Gefühl). Ich dachte gerade bei großen Datenmengen und vernünftiger Indezierung ist eine RDBMS erheblich schneller?! Siehe Self-Suche! Oder meinst Du nur die Schreibzugriffe?
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...
Seid Ihr noch nicht? Schwach... ;-)
...und analysieren, ja. Jetzt müsste ich nur noch wissen, wie ich Sockets und Daemonen mit C++ programmiere :-)
Wenn Du das weißt sag Bescheid ;-)
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 :-((
Na dann mal viel Spaß ;-)
Grüße
Andreas