nicht angemeldet
Counter! Wie speichert man am besten die Logs?
Hi,
ich will mir für den Anfang einen Counter mit IP-Sperre basteln und jede Menge anderer Infos (Browser, Auflösung,Datum,....)
und einen einfachen Counter auf jeder Seite.
Später baue ich mir dann eine Auswertungsseite.
Wo und wie speichere ich am besten und einfachsten die Daten?
Wenn ich sie in einer txt Datei speichere ist die nach ner Zeit doch ewig lang und bremst vielleicht alles?
Im Monat habe ich ca. 12.000 User tendenz steigend
danke
mfg chris
-
Halihallo Christoph
ich will mir für den Anfang einen Counter mit IP-Sperre basteln und jede Menge anderer Infos (Browser, Auflösung,Datum,....)
Wozu eine IP-Sperre?
Wo und wie speichere ich am besten und einfachsten die Daten?
Flatfile => Textdatei/CSV/binäre Form.
Wenn ich sie in einer txt Datei speichere ist die nach ner Zeit doch ewig lang und bremst vielleicht alles?
Im Gegenteil. Der Counter fügt nur neue Daten an, das geht bei FlatFiles am schnellsten.
Alles andere (z. B. Datenbanken) sind meistens langsamer, haben dann jedoch _wesentliche_
Vorteile beim Auswerten der Daten.
Aber das Auswerten kann einmal täglich geschehen, Weiterverarbeitung über die Datenbank.
Und selbst wenn stündlich, kommen auch von 12.000 Usern, was immer das auch heissen und
bedeuten mag, nicht so viele Requests zusammen, als dass es einer anderen Technik
als Flagfile bedarf.Im Monat habe ich ca. 12.000 User tendenz steigend
User sind nicht relevant, Pageimpressions das bessere Mass um die Anforderungen an die
Performance zu beschreiben.Viele Grüsse
Philipp
-
Hi,
ich will mir für den Anfang einen Counter mit IP-Sperre basteln und jede Menge anderer Infos (Browser, Auflösung,Datum,....)
Wozu eine IP-Sperre?
wohl um Doppelklick rauszuhalten?!
Aber das sollte man lieber im Nachhinein "verfälschen", auch aus Geschwindigkeitsgründen.Wo und wie speichere ich am besten und einfachsten die Daten?
Flatfile => Textdatei/CSV/binäre Form.
Wenn ich sie in einer txt Datei speichere ist die nach ner Zeit doch ewig lang und bremst vielleicht alles?
Im Gegenteil. Der Counter fügt nur neue Daten an, das geht bei FlatFiles am schnellsten.
Es geht auch anders bzw. man kann beide Ideen kombinieren!
Wir nutzen sehr schnelle Sammeltabellen, die nichts anderes tun, als Daten in sich aufzusaugen. Es werden keine Fallunterscheidungen/Berechnungen durchgeführt (mit Ausnahme von Segmentsplitting). D.h. im Endeffekt ist das wie Deine Datei. Der Vorteil ist aber, daß man die Daten schon etwas vorsortiert in einer DB-Tabelle hat.Alles andere (z. B. Datenbanken) sind meistens langsamer, haben dann jedoch _wesentliche_
Vorteile beim Auswerten der Daten.
Aber das Auswerten kann einmal täglich geschehen, Weiterverarbeitung über die Datenbank.
Und selbst wenn stündlich, kommen auch von 12.000 Usern, was immer das auch heissen und
bedeuten mag, nicht so viele Requests zusammen, als dass es einer anderen Technik
als Flagfile bedarf.Im Monat habe ich ca. 12.000 User tendenz steigend
User sind nicht relevant, Pageimpressions das bessere Mass um die Anforderungen an die
Performance zu beschreiben.Und: Die Art wie oder vielmehr was man mißt. Wenn Du nur den Treffer und vielleicht Browserverion und IP verbuchst, hast Du kaum Daten. Wenn Du mehr techn. Details (Plugins bzw. ActiveX, Farbtiefe, OS, Login, wenn greifbar, usw.) mitschreibst, ist das deutlich mehr an Daten.
Gruß
Reiner-
Halihallo Reiner
ich will mir für den Anfang einen Counter mit IP-Sperre basteln und jede Menge anderer Infos (Browser, Auflösung,Datum,....)
Wozu eine IP-Sperre?
wohl um Doppelklick rauszuhalten?!
Hm... Möglich... ;)
Aber das sollte man lieber im Nachhinein "verfälschen", auch aus Geschwindigkeitsgründen.
Ja.
Im Gegenteil. Der Counter fügt nur neue Daten an, das geht bei FlatFiles am schnellsten.
Es geht auch anders bzw. man kann beide Ideen kombinieren!
So geschieht es auch bei uns.
Wir nutzen sehr schnelle Sammeltabellen, die nichts anderes tun, als Daten in sich aufzusaugen. Es werden keine Fallunterscheidungen/Berechnungen durchgeführt (mit Ausnahme von Segmentsplitting). D.h. im Endeffekt ist das wie Deine Datei. Der Vorteil ist aber, daß man die Daten schon etwas vorsortiert in einer DB-Tabelle hat.
Hm. Sammeltabelle finde ich eine gute Idee, braucht etwas weniger Speicher. Nur, wann
gehen die Daten in die Sammeltabelle? - Bei jedem Request? - Baust du bei jedem Request
auf der zu messenden Seite eine neue Verbindung zur DB auf? - Da dies sehr, sehr
aperformant wäre, würde ich empfehlen zuerst über Flatfile zu gehen und die Daten dann
präanalysiert in die DB einzupflegen.Viele Grüsse
Philipp
-
Hi, hallo
- Baust du bei jedem Request auf der zu messenden Seite eine neue Verbindung zur DB auf? - Da dies sehr, sehr aperformant wäre, würde ich empfehlen zuerst über Flatfile zu gehen und die Daten dann präanalysiert in die DB einzupflegen.
Philipp, nicht doch, wer tut denn noch sowas? Recht hast du natürlich. Man bedenke dazu noch die Verwendung einer MS Access Datenbank. Zu Hülf! ;-)
Dazu gibt es einen Intermediate Tier, welcher ein Connection Pooling für die DB betreibt.
Tschau, tschüß,
Frank-
Halihallo Frank
- Baust du bei jedem Request auf der zu messenden Seite eine neue Verbindung zur DB auf? - Da dies sehr, sehr aperformant wäre, würde ich empfehlen zuerst über Flatfile zu gehen und die Daten dann präanalysiert in die DB einzupflegen.
Philipp, nicht doch, wer tut denn noch sowas?
Du wirst staunen! - Immer noch zuviele... phpMyAds z. B., wenn ich mich nicht sehr
täusche...Recht hast du natürlich. Man bedenke dazu noch die Verwendung einer MS Access Datenbank. Zu Hülf! ;-)
Nanu, du argumentierst mal gegen Access?? *freu* ;)
Dazu gibt es einen Intermediate Tier, welcher ein Connection Pooling für die DB betreibt.
... oder, in der "Sprache" von Unix: Preforked DB-Socket-Halter und ein ServerDaemon,
der die Requests auf die Arbeiterprozesse verteilt... Ja, mit Pooling wird's schon
wesentlich besser und am Schluss muss jeder eingestehen... dass Flatfiles eben doch noch
ein klitze kleines bissle schneller sind... ;-)
Aber ja, ob's sich dann noch den Mehraufwand lohnt, um eine eigene Lösung zu schreiben
möchte ich auch bezweifeln...Viele Grüsse
Philipp
-
Hi, hallo
Nanu, du argumentierst mal gegen Access?? *freu* ;)
MS Access hat durchaus seine Daseinsberechtigung, ich habe viele Sites darauf laufen und die schnurren problemlos. Liegt aber halt u.a. an entsprechender Programmierung :-)
Ich argumentierte aber eigentlich gegen die JET Engine, die bewußt von Microsoft niedrige gleichzeitige Benutzerzahlen limitiert ist, damit der SQL Server (auch) eine Daseinsberechtigung hat. Und gegen die anfängliche Dummheit des Einsteigers, genau der Literatur zu folgen, die da vorschlägt, man möge das DB öffnen und schließen als Includes auf jede Seite einbinden.
Lieber wettere ich gegen MySQL :-)
Tschau, tschüß,
Frank
-
-
-