nicht angemeldet
Halihallo Andreas
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?
Gedacht habe ich daran, ja. Aber es ist nach wie vor die "Abneigung" gegen das Apache-Logging... Wenn ich einen Stat-Tag über C programmieren kann und dies sogar performanter ist, dann werde ich diesen Weg gehen.
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!
Das stimmt. Über mod_perl wäre dies kein Problem, aber ohne ein wesentliches... Bei jedem Pageview eine neue Datenbank-Verbindung??? - Au waya...
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.
Yo. Das Problem ist: Der Apache speichert nur, er verarbeitet nicht. Bei meiner Stat müssen Daten verarbeitet werden und die Ausgabe sieht je nach Besucher anders aus... Aus dem log kann ich nur Daten kriegen, nicht jedoch zum Kunden senden...
Habe aber noch 2 Ideen:
- 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
[...]
Die Lösung finde ich eigentlich schon OK. Aber wie gesagt: Das Log ist das eine, die Verarbeitung (diese muss aus internen Zwecken zwingend bei jedem Pageview [Realtime] geschehen, um dann die Konsequenz(en) direkt wieder an den Client zu senden (eg. Cookie)).
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?
Keine Tagesdaten; wir haben uns auf stündliche Statistik geeinigt. Die Analyse (die finale-) findet natürlich über die MySQL Datenbank statt. Die Voranalyse in der Synchronisation ist lediglich ein kummulieren der Daten der Requests auf eine Stunde (bzw. Konsequenzen auf andere Stundeneinträge); dazu braucht man keine DB.
Was meinst Du mit "sync-Datenstruktur"?
Die Daten werden ja in einer gewissen Syntax auf den Hauptrechner übertragen. Diese Syntax unterscheidet sich von der eigentlichen Speicherung der Requests. Letzteres Format bezeichnete ich als sync-Datenstruktur. Die Requests werden auf ca. 10'000 Textdateien verteilt gespeichert; diese werden dann im Sync-Vorgang analysiert und die Informationen zusammengetragen (Voranalyse), dann wird die Synchronisations-Datenstruktur aufgebaut und die Daten an den Hauptrechner übertragen. Dieser zerpflückt die Daten wieder uns fügt sie in die mysql-Datenbank ein. Ach, auf einem Server werden natürlich Statistik von mehreren Websites/Pages gemessen...
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.
Ich dachte gerade bei großen Datenmengen und vernünftiger Indezierung ist eine RDBMS erheblich schneller?!
Das muss man stark relativieren! - Beim Selektieren von Records werden die Indizies stark und sind gigantische Performancebringer. Jedoch beim Einfügen von neuen Records ist es genau umgekehrt. Die Indizies müssen nach dem Einfügen von neuen Records überarbeitet werden u. U. muss die Baumstruktur ziemlich stark geändert werden (Rotation und Doppelrotation von Unterbäumen, dass der ganze Index-Baum wieder ausgeglichen ist). Dies wäre bei meiner Anwendung der Statistik ein grosser Nachteil, da ich gar keine Daten selektieren muss, sondern diese nur eintrage und linear abarbeiten muss. Ein Index bringt mir gar nix.
Siehe Self-Suche!
kenne ich :-)
Oder meinst Du nur die Schreibzugriffe?
es sind eigentlich nur Schreibzugriffe. Deshalb o. genanntes. Klar, ich müsste auch vieles Einlesen, aber bei diesem Einlesen habe ich keine Kriterien und somit würden auch die Indizies nix bringen (im Gegenteil). Das Einlesen kann linear erfolgen (also jeder Record einzeln), das kann man mit flat-file sehr effizient (OK, wenn ich die Daten noch in einem binary-Format abspeichern tät, wärs noch performanter). Ich kann jedoch nicht sagen, ob eine DB performanter als die flat-file Variante von mir wäre; aber der Aufwand einen neuen Stat-Server in das "Netzwerk" einzupflügen wäre etwas grösser (müsste eine mysql-DB einrichten) :-)
Allgemein (also vorausgesetzt, die mysql wäre langsamer oder mindestens gleich schnell) würde ich dennoch zu Flat-File basieren, da dort die Verarbeitung wirklich sau-einfach ist.
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... ;-)
Wenn wir's hätten, würde ich bereits auf den Bahamas hausen :-)
...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 ;-)
Das mit den Sockets hab ich bereits herausgefunden. Durch einen Zufall... Musste mir swissflirt.ch antun (nicht aus eigenen Interessen! *g*), Admanager ist a) Falk und b) AdCycle; bei AdCycle wurde ich aufmerksam (den kannte ich noch nicht) => Website von AdCycle.com ansehen => aha, Shareware-AdManagementSystem, interessant und den Source kann man sich erst noch herunterladen, was ich mir nur für eine einmalige Einsicht antat. Was sehe ich da? - Ein C-Programm mit Sockets :-)
=> man braucht nicht einmal zu googlen :-)
Aber mit Zeit kommt Rat :-)
ein Tag später war er da ;)
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ß ;-)
ARGHHH! ;)
Viele Grüsse
Philipp