[Web] website statistieken programmeren

[Kawoutertje]

Ik zou graag zelf wat website-statistieken programmeren. Het gaat om enkele simpele dingen hoor: Aantal bezoekers, welke browser, welke schermresolutie, ... Dat soort dingen.

Nu weet ik alleen niet goed hoe ik die data van de bezoekers moet opslaan.
Sla je de data van bezoekers gewoon per bezoeker op een de database, en haal je de data eruit als je statistiekenpagina wordt opgevraagd. Berekenen van alles gebeurt dan bij het opvragen van de statistiekenpagina.
Of bereken je telkens er een bezoeker langskomt opnieuw alle totalen en sla je die op in de database? Dan moeten ze enkel worden uitgelezen bij het opvragen van de statistiekenpagina.
Of sla je zulke dingen helemaal niet op in een database, maar weet ik veel waar ergens anders ?

Hoe zou jij daaraan beginnen?

thx

Ps1. Ik vraag geen code of zo hoor, gewoon een werkwijze.
Ps2. Voor de criticasters onder ons, ik weet dat er honderd en één verschillende webstats-sites zijn, die zelfs gratis zijn, maar ik zou het gewoon graag een keertje zelf programmeren.

Database met daarin de browsers en die hoog je steeds met 1 op.

[Fade of Light]

Kawoutertje schreef op 16-11-2004 @ 14:15 :
Sla je de data van bezoekers gewoon per bezoeker op een de database, en haal je de data eruit als je statistiekenpagina wordt opgevraagd. Berekenen van alles gebeurt dan bij het opvragen van de statistiekenpagina.

Even logisch nadenken wat de mogelijkheden zijn. JE kan per bezoeker een record maken en daar alle details van opslaan. Je krijgt dan een table zoals:
Table user
Fields:
ip
resolution
color-depth
browser
..
..
etc

Stel je krijgt een miljoen bezoekers, dan heb je wel een redelijk aantal records

Stel je gebruikt meerdere tables, denkt na over de verwachte waarden en verhoogt die:

table: users_resolution
fields:
800x600
1024x768
16..x1200
etc

En daarvan verhoog je steeds de waarde met 1. Elk tabel heeft 1 record en blijft er maar 1 houden, omdat elk veld geupdate wordt.

Andere mogelijkheden? Denk er zelf maar over na ;]

Een statistieken pagina wordt minder vaak opgevraagd, dus kun je de berekeningen het beste op dat moment doen.

Verder begin je met het opschrijven van alle gegevens waar je statistieken van wilt (resolutie, browser, etc). Dit gaan normaliseren. Vervolgens heb je een mooie database. Dan de code schrijven.

Het aantal records in een tabel maakt op zich weinig uit; een beetje DBMS kan hiermee probleemloos overweg.

[Fade of Light]

eddie schreef op 16-11-2004 @ 16:06 :
Het aantal records in een tabel maakt op zich weinig uit; een beetje DBMS kan hiermee probleemloos overweg.

Dan nog is het kansloos om bij veel bezoekers zo'n oplossing te gebruiken. Je slaat gewoon veel te veel redundante info op die je in 1 mooi getalletje kan samen pakken.

[Kawoutertje]

De site waarvoor ik nu die statistieken aan het maken ben, zal wel geen tienduizenden bezoekers trekken

Maar omdat dit later zal dienen als basis voor statistieken op grotere sites, zou ik het toch wel op een goede manier willen proberen.

Het voordeel van alle info per gebruiker (dus in één tabel) op te slagen, is dat je slechts één tabel moet updaten telkens er een nieuwe bezoeker komt je site komt.
Wanneer je alles in verschillende tabels (tabel resolutie, tabel browser, ...) opslaagt, moet je per nieuwe gebruiken wel enkele tabellen updaten. Maar dit is dan weer sneller bij het genereren van de statistiekenpagina.

Welke van de twee zou nu de beste oplossing zijn en waarom?

Fade of Light schreef op 16-11-2004 @ 16:41 :
Dan nog is het kansloos om bij veel bezoekers zo'n oplossing te gebruiken. Je slaat gewoon veel te veel redundante info op die je in 1 mooi getalletje kan samen pakken.

Tja, dat het databasetechnisch niet de mooiste oplossing is ben ik met je eens. Maar zoals ik al zei: een beetje database moet er geen problemen mee hebben.

Kawoutertje schreef op 16-11-2004 @ 18:45 :
De site waarvoor ik nu die statistieken aan het maken ben, zal wel geen tienduizenden bezoekers trekken

Dan zou ik voor de makkelijke manier gaan: alles in een of twee tabellen zetten; 'quik-n-dirty'

Kawoutertje schreef op 16-11-2004 @ 18:45 :

Maar omdat dit later zal dienen als basis voor statistieken op grotere sites, zou ik het toch wel op een goede manier willen proberen.

Als je de database later ergens anders voor gaat gebruiken, raad ik je aan om het wel goed te normaliseren - dus meerdere tabellen

Kawoutertje schreef op 16-11-2004 @ 18:45 :

Het voordeel van alle info per gebruiker (dus in één tabel) op te slagen, is dat je slechts één tabel moet updaten telkens er een nieuwe bezoeker komt je site komt.
Wanneer je alles in verschillende tabels (tabel resolutie, tabel browser, ...) opslaagt, moet je per nieuwe gebruiken wel enkele tabellen updaten. Maar dit is dan weer sneller bij het genereren van de statistiekenpagina.

Welke van de twee zou nu de beste oplossing zijn en waarom?

Ligt eraan hoe intensief de DB gebruikt gaat worden. Wordt het heel intensief, dus duizenden gebruikers, dan zou ik gebruik maken van meerdere tabellen.

Verder zou ik op de tabellen enkele indexen zetten om het genereren van de statistieken te versnellen. Houdt er rekening mee dat het bijwerken van een index ook tijd kost. Tijd die je, wanneer je alles in één tabel zou zetten, niet hebt; het bijwerken neemt dan teveel tijd in beslag.

Ook een optie is om het bijwerken van de tabel(len) in een apart proces/aparte thread te doen; zo hoeft de gebruiker niet te wachten totdat de database klaar is met updaten en kan de pagina gewoon doorgaan met laden.

[Kawoutertje]

'k ga niet voor de quick'n dirty methode gaan

Ik ga alles propertjes genormaliseerd proberen te doen. Het bijwerken van de tabellen in een apart proces is nu zeker nog niet nodig, maar ik heb er geen idee van hoe je zoiets kan fixen.

Hoe doe je zoiets ? Of naar welke info moet ik zoeken om zoiets te fixen ?

Thx anyway !!!

[Energie]

tabel 1 :
gebruiker IP | eerste keer | per dag | totaal aantal keer |

script
als eerste keer nee is haal data en stop in database tabel 2
zo niet tel 1 op bij totaal aantal keer.

tabel 2:
| reso | OS | afkomst? |

iets in deze richting moet je gewoon denken, je moet alleen ff uitkijken dat je niet telkens bij iedere nieuwe gebruiker dat elke script weer doorlopen word

[Fade of Light]

eddie schreef op 16-11-2004 @ 19:43 :
Houdt er rekening mee dat het bijwerken van een index ook tijd kost. Tijd die je, wanneer je alles in één tabel zou zetten, niet hebt; het bijwerken neemt dan teveel tijd in beslag.

Het bijwerken van de index?! Waarom zou je de index bijwerken?

Kawoutertje schreef op 16-11-2004 @ 19:48 :
'k ga niet voor de quick'n dirty methode gaan

Ik ga alles propertjes genormaliseerd proberen te doen. Het bijwerken van de tabellen in een apart proces is nu zeker nog niet nodig, maar ik heb er geen idee van hoe je zoiets kan fixen.

Hoe doe je zoiets ? Of naar welke info moet ik zoeken om zoiets te fixen ?

Thx anyway !!!

Zoals ik eerder postte:
Schrijf alle attributen op die je wilt bewaren voor de statistieken (browser, resolutie, ip, etc). Zorg ervoor dat je dit zoveel mogelijk uitkleed; 'browser' is niet specifiek genoeg. Denk o.a. aan:
- Naam : 'Opera'
- Versie (Major) : 7
- Versie (Minor) : 54

Zo is 'resolutie' ook niet specifiek genoeg; een resolutie bestaat namelijk uit twee gegevens: x-resolutie en y-resolutie (800 x 600, 1280 x 1024, 1600 x 1200). Op deze manier hoef je de resoluties niet voor te definieren (en kun je nog mooiere stats maken).

Je bent nu nog in de ontwerp fase: Je gaat bedenken wat en hoe je iets gaat maken. Nadat je het helemaal mooi hebt uitgewerkt, kun je gaan bepalen waarin/waarmee je iets gaat maken. Denk hierbij aan database keuze (Oracle, MS SQL Server, MySQL, plain text) zo ook aan de scripttaal (ASP .NET, Perl, PHP, ColdFusion). Nadat je dit hebt gedaan, ga je beginnen met bouwen en mnoet je je concentreren op de specifieke problemen van de door jou gekozen database + taal.

Fade of Light schreef op 16-11-2004 @ 20:02 :
Het bijwerken van de index?! Waarom zou je de index bijwerken?

Een beetje database doet dit zelf zodra je een mutatie (update, delete, insert) uitvoert op een tabel met indexen.

Voornamelijk de 'clustered indexes' zijn niet zo fijn voor de database. Bij zo'n index staan de records fysiek op de volgorde aangegeven in de clustered index.

Voorbeeldje:
Tabel resolutie
id - int
x - int
y - int

Er staat een clustered index op x. De records staan dan (fysiek) in de volgende volgorde

id         x        y
08        640     300
03        640     200
15        640     480
01        800     600
06        800     400
02        1024    786
07        1024    900
09        1024    1000

(resoluties zijn fictief)

Wanneer je nu een nieuwe resolutie gaat toevoegen, zeg 640 x 150, komt het er zo uit te zien

id         x        y
08        640     300
03        640     200
15        640     480
16        640     150
01        800     600
06        800     400
02        1024    786
07        1024    900
09        1024    1000

Alle records met x > 640 zijn fysiek opgeschoven; dit veroorzaakt weer schijfbewerkingen op de schijf wat weer tijd met zich meebrengt. Daarna werkt de database de index bij zodat alles weer lekker snel gevonden kan worden.

[Fade of Light]

clustered index betekent dat er geordend wordt op de waarden van x? Waarom zou je niet gewoon een ordening op de index aanhouden? (Dan heb je dat probleem wat je voorschreef toch niet?)

(waarschijnlijk zal dit de reden zijn waarom ik resoluties er gewoon zelf 'hard coded' in zou zetten, wat iets ten koste gaan van de genericiteit, maarja...)

Fade of Light schreef op 16-11-2004 @ 20:17 :
clustered index betekent dat er geordend wordt op de waarden van x? Waarom zou je niet gewoon een ordening op de index aanhouden? (Dan heb je dat probleem wat je voorschreef toch niet?)

Dat klopt. Echter, wanneer er heeeeeel veel data in de database staat, kan het voor de snelheid van het ophalen van de data uitmaken in welke volgorde deze fysiek staat.

Een clustered index is alleen goed te zetten na uitgebreide tests om te kijken welke queries het vaakst voorkomen en/of de meeste tijd in beslag nemen om deze daarna proberen te optimaliseren.

Wanner je bijvoorbeeld alle resoluties met x = 640 wilt hebben, hoeft in het geval van een clustered index de leeskop van de harde schijf een stuk minder te bewegen om de data te lezen, omdat de data achter elkaar staat. Dit scheelt (uiteindelijk) weer tijd. Maar hoogst waarschijnlijk helpt dit alleen goed bij alleen lezen applicaties.

Bij applicaties die veel bewerkingen veroorzaken op de database kan een clustered index dus voor veel vertraging zorgen (omdat de records steeds fysiek moeten worden verplaatst).

Fade of Light schreef op 16-11-2004 @ 20:17 :

(waarschijnlijk zal dit de reden zijn waarom ik resoluties er gewoon zelf 'hard coded' in zou zetten, wat iets ten koste gaan van de genericiteit, maarja...)

Tja, keuzes he? Je hebt dan een probleem wanneer er iemand langs komt met een afwijkende resolutie (1600 x 900 bijvoorbeeld).

[edit]
Verder worden gewone indexen ook vanzelf bijgewerkt; anders heb je er niks aan he? (staat er een record in de tabel die niet is opgenomen in de index --> vind je hem nooit )

[Fade of Light]

eddie schreef op 16-11-2004 @ 20:27 :
*verhaal*

Dank u voor de uitleg

Tja, keuzes he? Je hebt dan een probleem wanneer er iemand langs komt met een afwijkende resolutie (1600 x 900 bijvoorbeeld).

1 optie "ander"

Fade of Light schreef op 16-11-2004 @ 20:30 :
1 optie "ander"

Gheghe... de hoer van de database

(excuse my French)

[Kawoutertje]

eddie schreef op 16-11-2004 @ 20:05 :
Zoals ik eerder postte:
knip...

Thanks voor de uitleg. Heel interessant en leerrijk !!!

Maareuh, ik bedoelde eigenlijk hoe je zoiets kan uitvoeren in een tweede bestand, zodat het laden van de pagina's niet wordt vertraagd door het updaten van al die data. Is dat in elke ServerSide programmeertaal mogelijk, of moet je daar een wat grotere programmeertaal bijhalen ?


Wat die database betreft, ik dacht aan het volgende:

tbl1: ID | IP | aantal visits

tbl2: ID | tbl1 ID | browsernaam | versie
tbl3: ID | tbl1 ID | resolutieX | resolutieY
tbl4: ID | tbl1 ID | hostname | land van herkomst
tbl5: ID | dag | maand | jaar | dag vd week | week (enige tabel samen met tbl1 die bij elk bezoek moet worden geupdate)

Is dit teveel opgesplitst of in teveel tabellen verdeeld ? Of zit dit toch in de goede richting ?

[Fade of Light]

eddie schreef op 16-11-2004 @ 20:32 :
Gheghe... de hoer van de database

(excuse my French)

Ach ja, ze wordt graag gebruikt

Wat overigens het beste en snelste is:

Stat image:
Schrijft diverse/gewenste data naar 1 file of verschillende files

Stat script:
Leest 1x per dag (voorkeur: nacht) de bestanden uit en schrijft ze in html formaat direct weg als files.

Dit is het snelste en server vriendelijkst.
(Sterker nog, statistieken pagina's als Webalizer en AW Stats werken zo )

[Manuzhai]

Ja, kan je niet gewoon de Apache logs uitlezen?

Wel zo nauwkeurig, en beter qua performance van je website.

[Kawoutertje]

@ ********** en @ manuzhai: Weerom, hoe doe je zoiets.
Ik kan wel wat programmeren, maar van zulke dingen heb ik weinig kaas gegeten.

[Manuzhai]

Als je de beschikking hebt over die logfiles: kwestie van parsen met bijvoorbeeld Python of PHP of Perl. Is niet zo heel moeilijk.

[Energie]

waar draait dit nou om, php en mysQl tog? of heb ik het mis, want de dingen die ik hierboven zie

[Kawoutertje]

Mja, ik werk met ASP. Nu, ik zit wel op een apache webserver (die draait chilisoft ASP). Waar zou ik die log-files moeten terugvinden ?

[Manuzhai]

Kawoutertje schreef op 16-11-2004 @ 23:10 :
Mja, ik werk met ASP. Nu, ik zit wel op een apache webserver (die draait chilisoft ASP). Waar zou ik die log-files moeten terugvinden ?

De logfiles staan volgens mij standaard in de /log/ directory binnen de Apache directory.

[Kawoutertje]

Daar heb ik blijkbaar zo direct geen toegang toe.
Toch bedankt.

Andere ideetjes, of heb je er misschien een idee van wat Trilox juist bedoelde ?

[Manuzhai]

Trilo heeft het over een hybride script, dat eerst alle data zo simpel mogelijk wegschrijft en vervolgens eens in de zoveel tijd die ruwe data verwerkt tot iets dat nuttiger is en minder ruimte inneemt.

[Energie]

asp php

[Manuzhai]

PHP Python

[Kawoutertje]

Manuzhai schreef op 16-11-2004 @ 23:22 :
Trilo heeft het over een hybride script, dat eerst alle data zo simpel mogelijk wegschrijft en vervolgens eens in de zoveel tijd die ruwe data verwerkt tot iets dat nuttiger is en minder ruimte inneemt.

Mmmm, dat zal wsl net iets te moeilijk zijn om effe vlug zelf in mekaar te knutselen ?

[Kawoutertje]

Energie schreef op 16-11-2004 @ 23:23 :
asp php

Chilisoft ASP rocks

Manuzhai schreef op 16-11-2004 @ 23:26 :
PHP Python

PHP
Python

PHP is zeker niet per definitie slecht, Python kan alleen meer.
Maar iest wat ook met PHP kan zal in PHP makkelijker te maken zijn en sneller geparsed worden.

[Fade of Light]

Scripttalen

?

Ach, tis maar net wat je fijner vindt. Je kan genoeg met de meest gangbare scripttalen.

Manuzhai schreef op 16-11-2004 @ 23:22 :
Trilo heeft het over een hybride script, dat eerst alle data zo simpel mogelijk wegschrijft en vervolgens eens in de zoveel tijd die ruwe data verwerkt tot iets dat nuttiger is en minder ruimte inneemt.

Correct

Kawoutertje schreef op 16-11-2004 @ 23:27 :
Mmmm, dat zal wsl net iets te moeilijk zijn om effe vlug zelf in mekaar te knutselen ?

Nee, valt wel mee
Bestand browser.txt bevat:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Opera/7.54 (Windows NT 5.1; U) [en]
Etcetc

Dan lees je het bestand gewoon uit en stop je even alles mooi in een array en gaat alles even netjes tellen.
En dit doe je ook met dingen als IP's ed.

Kawoutertje schreef op 16-11-2004 @ 23:28 :
Chilisoft ASP rocks

Wat een crap, ASP emuleren
Neem dan gewoon serieus een Windows server met ASP(.NET).

Kawoutertje schreef op 16-11-2004 @ 20:44 :
Thanks voor de uitleg. Heel interessant en leerrijk !!!

Maareuh, ik bedoelde eigenlijk hoe je zoiets kan uitvoeren in een tweede bestand, zodat het laden van de pagina's niet wordt vertraagd door het updaten van al die data. Is dat in elke ServerSide programmeertaal mogelijk, of moet je daar een wat grotere programmeertaal bijhalen ?

Dat ligt denk ik aan de taal. Ik kan me voorstellen dat het in bepaalde talen mogelijk is om een aparte thread op te starten.

Kawoutertje schreef op 16-11-2004 @ 20:44 :

Wat die database betreft, ik dacht aan het volgende:

tbl1: ID | IP | aantal visits

tbl2: ID | tbl1 ID | browsernaam | versie
tbl3: ID | tbl1 ID | resolutieX | resolutieY
tbl4: ID | tbl1 ID | hostname | land van herkomst
tbl5: ID | dag | maand | jaar | dag vd week | week (enige tabel samen met tbl1 die bij elk bezoek moet worden geupdate)

Is dit teveel opgesplitst of in teveel tabellen verdeeld ? Of zit dit toch in de goede richting ?

Voor normaliseren zijn verscheidene tutorials te vinden op internet.

Over het algemeen zijn attributen die berekend kunnen worden niet nodig in de database (tenzij het extreem veel performance kost). Zoals tabel 5. het enige wat je misschien nodig hebt, is de datum. Van daar uit kun je de dag, maand, jaar, weekdag en week bepalen.

De optie die ********** doet is ook een goede. Maar het hangt er vanaf hoe actueel je de statistieken wilt hebben.

[Manuzhai]

********** schreef op 16-11-2004 @ 23:36 :
Maar iest wat ook met PHP kan zal in PHP makkelijker te maken zijn en sneller geparsed worden.

Onzin.