[PHP] Optimale db structuur voor stats systeem

[Verwijderd]

Goeden avond allemaal!

Ik ben sinds een paar dagen beetje aan het nadenken over een uitgebreid (zowel aan de server als client side) statistieken systeem.

Nu heb ik al wat simpels in elkaar gezet, waarbij elke hit wordt opgeslagen in een Mysql Db, en het IP, tijd, pagina, referer en browser info gaan dan gelijk mee.

Hierdoor zou ik een gigantische tabel krijgen, als ik 40 bezoekers per dag haal, die elk 20 pagina's per dag bekijken (40*20 = 800 rows per dag erbij), en ik wil dit wel een script maken dat snel laad en optimaal werkt (perfectionist )

Het is helemaal traag als ik dan statistieken wil gaan maken, bv grafiekjes. Het moet dan niet alleen lang rekenen voor de plaatjes, maar ook om alles uit de db te halen en te ordenen.

Wat is volgens jullie dus de meest optimale database/tabel structuur, zodat alles snel geladen kan worden?

Alvast tnx!

Roemer

[Mithrandir]

Allereerst moet je alles goed laten ordenen door de database; die zijn voor zulke klussen gemaakt.
Maar is het geen idee om de logs van je server te laten analyseren door je software? Dat geeft ook betrouwbare statistieken zonder dat je er iedere pagina een query voor hoeft te doen.

[Verwijderd]

Met ordenen bedoel ik eigenlijk het berekenen voor de grafieken welk percentage bv IE 6.0 gebruikt.
En ik wil het niet door m'n logs laten doen, omdat ik het script zo wil maken dat het op elke server werkt, en niet iedereen heeft toegang tot z'n logs, en omdat in de logs bv niet de referer adres staat.

[coubertin119]

Zo'n database wordt erg snel erg groot als je on-the-fly statistieken wil genereren. Daarom is het beter om ieder uur een cronjob te draaien die deze statistieken uitleest en ze in een mooi formaatje giet. Bespaart je heel wat serverload .

[whoami]

coubertin119 schreef op 05 februari 2004 @ 21:20:
Zo'n database wordt erg snel erg groot

Wat is groot.

Je kan trouwens oude data die je vrijwel niet meer gebruikt naar een 'archief' tabel moven.

coubertin119 schreef op 05 februari 2004 @ 21:20:
Daarom is het beter om ieder uur een cronjob te draaien die deze statistieken uitleest en ze in een mooi formaatje giet. Bespaart je heel wat serverload .

Dat hangt er van af hoe lang het duurt om die resultaten in een mooi formaatje te gieten, en om de hoeveel tijd je die cron lanceert.

[ Voor 68% gewijzigd door whoami op 05-02-2004 21:25 ]

[Verwijderd]

Hmm...is wel goed idee-tje, en heb daar zelf ook al over nagedacht, alhoewel ik de grafische statistieken alleen in het admin panel wil maken, dus die zullen niet zo vaak opgevraagd worden, maar ik geloof dat cronjobs alleen op unix systemen kunnen (of in windows met taakbeheer).
Maar de vraag is dan alsnog, hoe zou ik m'n database dan in moeten richten?

edit: onder groot versta ik dat de laadtijd merkbaar wordt beinvloed

[ Voor 10% gewijzigd door Verwijderd op 05-02-2004 21:25 ]

[We Are Borg]

Even opmerking vooraf: ben helemaal niet geweldig in php/db's, maar wie weet geeft mijn opmerking stof tot nadenken . Mijn opmerking kan dus best kant noch wal raken

Als een user op je pagina komt, kan je uiteraard IP/browser/tijd/referer in database opslaan en later eruit vissen. Je kan ook het volgende doen:

Standaard rijtje maken in database met:

IE 6.0
IE 5.0
Mozilla
Opera
Firebird
etc

Wanneer iemand je pagina bezoekt, dan de waarde + 1 doen bij de browser die hij of zij gebruikt. Dan is het oproepen van de statistieken erg eenvoudig (duurt niet lang) want je hoeft alleen de waarde uit de database te halen.

Dit dus inplaats van alles los op te slaan en bij het opvragen van de gegevens alles te gaan berekenen.

[Erkens]

coubertin119 schreef op 05 februari 2004 @ 21:20:
Zo'n database wordt erg snel erg groot als je on-the-fly statistieken wil genereren. Daarom is het beter om ieder uur een cronjob te draaien die deze statistieken uitleest en ze in een mooi formaatje giet. Bespaart je heel wat serverload .

waarom met een cronjob, beetje nutteloos als niemand die grafieken opvraagt, en tevens heb je niet op elke server rechten om bijvoorbeeld cronjobs te maken.
Zelf zou ik de grafieken maken zodra ze voor het eerst aangevraagt worden, dan de plaatjes (en andere relevante data) opslaan samen met een timestamp, om zo te zien of het geupdate dient te worden

o en percentages zou ik dan laten doen door de database server, die kan dat veel sneller en efficienter dan dat je eerst grote hoeveelheden data naar php moet pompen

[ Voor 12% gewijzigd door Erkens op 05-02-2004 21:40 ]

[Verwijderd]

@We Are Borg: Is opzich hele mooie oplossing, behalve dan dat je de hele db en script aan moet passen als er een nieuwe browser uitkomt
@Erkens: Dat lijkt mij idd ook een betere oplossing!

Maar het ging dus eigenlijk om de tabel structuur en niet zozeer over wel/niet cronjobs

@whoami: kan jij misschien iets meer uitleggen hoe dat 'archiveren' dan in z'n werk zal gaan?

[Verwijderd]

hey,

Ik ben ook met zoiets bezig, alleen dan voor multi-domain/multi-section.

En je krijgt dan snel (als je site bijvoorbeeld net als bij mij 200 gb trekt per maand) dat je logs gigantische snel vollopen (denk aan om de 2 maanden 1 gb). Waar ik nu dus mee bezig ben is een tussen fase (een gedeeltelijke verwerking).

ipv dat je bijhoud

TIME - IP - CLIENT - SERVER - PAGE - PARAM

doe je

CLIENTTABLE
-----------------
TYPE (CLIENT)
COUNT (AANTALLEN)
PERIODSTART
PERIODEND

TIME -> IP (PAGE/PARAM) (om bijvoorbeeld bezoek duur of hoe de gebruiker door de site heen beweegt te analyseren.

en dit kun je met meerdere dingen doen, en 1 gb word dan misschien maar 300/400 mb en daar kun je weer per periode (MAAND) xml uit genereren (en blijft er maar 2/3 mb over).

[whoami]

Verwijderd schreef op 05 februari 2004 @ 21:42:
@whoami: kan jij misschien iets meer uitleggen hoe dat 'archiveren' dan in z'n werk zal gaan?

Heel simpel.
1x in de zoveel maand ga je de records die ouder zijn dan n maand verplaatsen naar een archive-tabel ofzo.
Je kan hiervoor een stored procedure (of script maken, als je MySQL gebruikt, want die ondersteunt geen sp's), dat je om de zoveel maanden laat lopen.
Maar of dit echt van toepassing kan zijn in jouw geval, is nu moeilijk te zeggen.

[Verwijderd]

@Rahman Advany: euhm...ik vat je uitleg niet helemaal...wat bedoel je met die dingen onder clienttable?

@whoami: ok, daar zit wel een goed puntje in!

[ Voor 29% gewijzigd door Verwijderd op 05-02-2004 22:01 ]

[Verwijderd]

Verwijderd schreef op 05 februari 2004 @ 21:58:
@Rahman Advany: euhm...ik vat je uitleg niet helemaal...wat bedoel je met die dingen onder clienttable?

@whoami: ok, daar zit wel een goed puntje in!

client table was voorbeeld, bijvoorbeeld je wilt aantal gebruikte browser's bijhouden? ipv alle records te bewaren van elke HIT. kun je om de zoveel tijd ( uur/dag/week ) die records samenvatten.

Bijvoorbeeld je gaat de gegevens per HIT veranderen in gegevens per PERIODE.

dus x AANTAL browsers van TYPE x is tussen BEGINPERIODE 00:00 1 jan 04 en EINDPERIODE 23:59 1 jan 04 op de site gekomen.

resulteerd in tabel =>

Browser
----------
TYPE
AANTAL
BEGINPERIODE
EINDPERIODE

op het eind kun je hier xml van maken, gewoon een eindrapport. Waarbij je de gegevens ipv per uur/per dag samenvat in per maand.

en dus het volgende hebt =>

LOG TABEL => VERWERKTE GEGEVENS TABEL => XML RAPPORT

[ Voor 4% gewijzigd door Verwijderd op 05-02-2004 22:07 ]

[Verwijderd]

ohhh zo ok! dat werkt misschien (misschien?? misschien?? zeker weten!) wel beter ja!

[Bosmonster]

whoami schreef op 05 februari 2004 @ 21:57:
[...]


Heel simpel.
1x in de zoveel maand ga je de records die ouder zijn dan n maand verplaatsen naar een archive-tabel ofzo.
Je kan hiervoor een stored procedure (of script maken, als je MySQL gebruikt, want die ondersteunt geen sp's), dat je om de zoveel maanden laat lopen.
Maar of dit echt van toepassing kan zijn in jouw geval, is nu moeilijk te zeggen.

Dit maakt bewerkingen op de data er niet sneller op..

Zelf maakten we ook gebruik van een dergelijk systeem en bij kleinere klanten was dat prima, maar bij grotere klanten genereerde dit zo'n hoeveelheid aan data dat een overzichtje uitlezen al een paar minuten duurde.

Als je het generiek wilt maken dat het ook werkt onder zwaardere loads zou ik de data middels een cronjob iedere maand bijvoorbeeld output laten genereren en de tabel leeggooien. Zet de resultaten in een XML-file bijvoorbeeld en je kunt er nog alles mee.

Blijft alles retesnel en loopt je database niet vol met honderden MB's aan onnodige data (handig aangezien de meeste hostingpakketten gaan over 50-100 MB ofzo en daar moet het toch ook op werken ). Iedere week is een nog beter idee.

[Verwijderd]

Ik denk dat die manier van Bosmonster dan het handigst is, en dan combineren met de manier van Rahman Advany. Alleen heb ik daar nog wel een vraagje over, want hoe kan ik dan bijhouden welk ip welke pagina heeft bezocht, en hoelaat en met welke referer? Want dat kan niet met zo'n tabel die wel met browsers kan (denk ik).

[JaQ]

Bosmonster schreef op 05 februari 2004 @ 22:47:
[...]


Dit maakt bewerkingen op de data er niet sneller op..

Zelf maakten we ook gebruik van een dergelijk systeem en bij kleinere klanten was dat prima, maar bij grotere klanten genereerde dit zo'n hoeveelheid aan data dat een overzichtje uitlezen al een paar minuten duurde.

Als je het generiek wilt maken dat het ook werkt onder zwaardere loads zou ik de data middels een cronjob iedere maand bijvoorbeeld output laten genereren en de tabel leeggooien. Zet de resultaten in een XML-file bijvoorbeeld en je kunt er nog alles mee.

Blijft alles retesnel en loopt je database niet vol met honderden MB's aan onnodige data (handig aangezien de meeste hostingpakketten gaan over 50-100 MB ofzo en daar moet het toch ook op werken ). Iedere week is een nog beter idee.

Grappig, zelf zou ik ten aller tijde er voor kiezen om de orignele waarden in een archive tabel te gieten, bij voorkeur een partitioned table, gegevens ouder dan 13 maanden trashen. Partitioneren op maand dus.

Vervolgens een tweede tabel bijhouden met aggregated data, oftewel: je gegevens berekenen via een SP of script en de resultaten opslaan. Voor de recente maand kan je dat doen voor alle data ouder dan 1 dag, waardoor je nooit meer dan de data van 1 dag on the fly hoeft te berekenen. Op die wijze hou je de load relatief laag bij grote hoeveelheden data.

Of dit performed (en of je dus bijvoorbeeld data in een XML buiten de DB op gaat slaan) hangt af van je DB ontwerp en je (pl) sql kunsten. (nofi). Zelf heb ik een dergelijk systeem gemaakt voor httpd, radius en interconnect (VoIP) logs voor een van de grootste ISP's in België en ik kan je vertellen dat het daar uitmuntend performed *klopt op eigen schouder *

[Bosmonster]

Hangt erg van je load af denk ik. Met een beetje hoeveelheid bezoekers is je stats database zo een paar honderd MB na die 13 maanden... en meestal zit je toch met een limiet aan schijfruimte (op onze eigen server zou ik het al helemaal niet zoveel ruimte in willen laten nemen).

Ten tweede zit je met zware loads als je zo'n hoeveelheid stats voor iedere klant wilt gaan verplaatsen naar een andere tabel iedere maand (je verplaatst het probleem, maar lost het imho niet op).

Of je de resultaatgegevens nu in een DB-tabel opslaat of in XML dat boeit niet zo en hangt meer van je voorkeur en de rest van je systeem af.

[darkrain]

Verwijderd schreef op 05 februari 2004 @ 21:42:
@We Are Borg: Is opzich hele mooie oplossing, behalve dan dat je de hele db en script aan moet passen als er een nieuwe browser uitkomt

Je hoeft bij deze oplossing helemaal niet je db en script aan te passen.

Je moet er gewoon voor zorgen dat je script kijkt of een browser al bestaat dan plus 1, anders eerst browser toevoegen en dan plus 1.

[JaQ]

Bosmonster schreef op 06 februari 2004 @ 10:27:
Hangt erg van je load af denk ik. Met een beetje hoeveelheid bezoekers is je stats database zo een paar honderd MB na die 13 maanden... en meestal zit je toch met een limiet aan schijfruimte (op onze eigen server zou ik het al helemaal niet zoveel ruimte in willen laten nemen).

Ten tweede zit je met zware loads als je zo'n hoeveelheid stats voor iedere klant wilt gaan verplaatsen naar een andere tabel iedere maand (je verplaatst het probleem, maar lost het imho niet op).

Of je de resultaatgegevens nu in een DB-tabel opslaat of in XML dat boeit niet zo en hangt meer van je voorkeur en de rest van je systeem af.

Load is een geldiger argument dan diskspace, aangezien diskspace vergroten relatief goedkoop is (zeker in vergelijking tot snellere proc + meer geheugen).

Soms zit je wel met wetterlijke/contractuele zaken. In het door mij eerder genoemde geval moesten de gegevens wetterlijk 1 jaar bewaard blijven, dus 12 maanden + de lopende maand = max 13 maanden gegevens. Je verplaatst uiteraard nooit meer dan 1 maand gegevens tegelijkertijd, dus voordat je dat merkt qua load moet het zo ongeveer het log van google zijn (bovendien kan je dat proces prima nicen, of juist parallel laten lopen, afhankelijk of je het proces sneller, danwel lichter wil laten lopen).

Je aggregatieproces is hetgene wat wel veel load kan veroorzaken. Door de frequentie van agregatie te verhogen kan je deze weer naar beneden trekken en zal je uiteindelijke rapport altijd sneller werken (want je hoeft niet on-the-fly je gegevens te aggregeren). Door de geagregeerde gegevens op te slaan, kan je wel de resultaten (met een simpele straight forward select zonder rekenprocessen) blijven tonen. Of je dat uit een xml of db doet is inderdaad niet zo relevant.

Je zou inderdaad de geagregeerde gegevens ook prima in een xml file op kunnen slaan en die dus gebruiken ipv een tabel voor het tonen van je totalen. (maar waarom zou je een extra dimensie in je app willen bouwen als je redelijk straight forward vanuit een DB kan blijven werken, ipv zowel met xml voor de geagregeerde en een db voor de meest recente gegevens)

Dit alles ter zijde, terug naar de vraag van de TS. Is er op freshmeat oid geen programma te vinden wat dit alles voor je doet? Een systeem dat iets vergelijkbaars doet i.c.m. een database (waardoor je dus het gevraagde datamodel kan afleiden, ik heb tenminste het idee dat de TS nog een beetje zoekent is naar wat er precies aan de klant getoont moet worden) zal toch echt wel bestaan? Verder verwacht ik dat je misschien ook een koppeling hebt naar een userdatabase oid? Je wil toch nadenken over welke klant bij welke gegevens mag en die klantgegevens staan ongetwijfeld in een DB (in mijn geval staan mijn klanten voor hosting in een ldap db, apache logs worden getoont door webalizer). Degene die voor iedere klant een eigen database creeert is volgens mij niet echt schaalbaar bezig, dat is een worldonline oplossing.

Verder als je deze logs/stats beschikbaar stelt, wil je dan ook logs/stats van andere services er in kwijt? (bijvoorbeeld mail/ftp?)

[X-Lars]

Ik heb het laatst ook gedaan en het is nog een beetje in testfase, maar het loopt heel prima voor websites met weinig traffic. Het is IMHO een behoorlijk efficiënt script, dus misschien zou het voor 'grotere' websites ook voldoen. Maar ik post het hier, misschien hebben anderen er wat aan en misschien kan iemand melden waarom dit idee juist helemaal niet goed is.

DB opzet:
- LOG_HITS [id | user_id | page_id | referrer | ts]
- LOG_USERS [user_id | ip | host | br_id | pf_id | res_id | col_id | count]
- LOG_PAGES [id | page | since | count]
- LOG_REFERRERS [id | name | host | count]
- LOG_KEYWORDS [id | keywords | count]
- LOG_BROWSERS [id | browser | version | count]
- LOG_PLATFORMS [id | platform | count]
- LOG_RESOLUTIONS [id | resolution | count]
- LOG_COLORDEPTHS [id | colordepth | count]

In elke pagina die geteld moet worden hoeft alleen maar een
<script language="JavaScript" src="log.js" type="text/javascript"></script>
te komen, vaak zal dat met PHP slechts 1 keer nodig zijn. Ligt natuurlijk aan de opzet van de website. In log.js worden referrer (complete url), resolutie en kleurtjes bepaalt, dit komt middels een
document.write("[img]\"log.php?data...\"[/img]");
in log.php terecht en dan

1. check ip+host > insert/update LOG_USERS > return array(user_id, br_id, pf_id, res_id, col_id) (bij een nieuwe user is dit (user_id, 0,0,0,0))
2. insert/update LOG_BROWSERS, LOG_PLATFORMS, LOG_RESOLUTIONS, LOG_COLORDEPTHS
3. update LOG_USERS als 2. waarden oplevert die niet in array staan (altijd met nieuwe users, maar bestaande user kan bijv. een nieuwe browser hebben)
4. extract referrer en gebruikte keywords uit (js-)referrer > insert/update LOG_REFERRERS, LOG_KEYWORDS, LOG_PAGES
5. insert LOG_HITS

ad 4. Voor de referrer (indien search engine) wordt engines-list.ini gebruikt. Aan de hand hiervan kun je de naam van de search engine en de gebruikte zoektermen bepalen.

ad 4. LOG_PAGES is de tabel met de pagina waar de user zich op dat moment bevindt op de site

ad 5. de complete url voor referrer wordt in LOG_HITS gezet, omdat deze niet uit de referrer+keywords te herleiden valt. maar misschien moet hier wel weer een aparte tabel voor gemaakt worden, zodat LOG_HITS minimaal blijft.

todo:

• een goed opgezette pagina om de stats te bekijken
• check of het geen refresh betreft, nu wordt elke hit geregistreerd. er zou aan het begin een query bij moeten die ip+host+'lastvisitedpage' checkt
• nog 1 normalisatie op LOG_HITS voor referrer-url
• maandelijkse cronjob die xml genereert (lijkt me handigste oplossing)

het voordeel van deze opzet (tot aan die cronjob) is dat het heel makkelijk te installeren valt. ik heb er een .sql bij waarmee je in 1x alle tabelletjes aanmaakt en een soort log.ini waarin je het domein van de site aangeeft, emailadres waar foutmeldingen naartoe kunnen en database gegevens. met een kleine readme kan een kind de was doen.

PS Het idee is afgeleid van PowerPhlogger. Ik wilde kijken of ook zelf zoiets kon bouwen en wat meer naar mijn smaak. Uiteraard is pphlogger wat uitgebreider en waarschijnlijk ook bug-vrijer. Alhoewel ik er momenteel geen meer tegenkom

edit: [ADDITION] lees even door voor je mijn idee kopieert

[ Voor 4% gewijzigd door X-Lars op 08-02-2004 17:45 ]

[Verwijderd]

tnx@ X-lars!
Ik denk dat jouw opzet ook redelijk goed is! Ik zal er vanavond/morgen mee beginnen, jullie horen het nog wel als het niet lukt

btw, voor de mensen die het dachten, het wordt een script voor 1 website, dus niet een nedstat achtig iets!

[edit]
nog wel ff een vraagje: Elk IP is bij jouw een aparte user? en daaruit link je naar de browser/referer/resolutie die ze hebben (via een hit)?

[ Voor 24% gewijzigd door Verwijderd op 06-02-2004 15:55 ]

[X-Lars]

Verwijderd schreef op 06 februari 2004 @ 15:48:
[edit]
nog wel ff een vraagje: Elk IP is bij jouw een aparte user? en daaruit link je naar de browser/referer/resolutie die ze hebben (via een hit)?

elke "unique hit" is een user, d.w.z. een unieke ip+host combinatie, een voorbeeldrij uit de LOG_USERS tabel:

[user_id | ip | host | br_id | pf_id | res_id | col_id | count]
23 123.12.12.131 user.wanadoo.nl 3 2 1 4 12

die 3 2 1 4 is de combinatie browser/platform/resolution/colordepth, die terug te vinden is in de respectievelijke tabellen

met insert/update bedoel ik overigens het hier al eerder genoemde principe: kijk of (bijv.) Windows 98 al voorkomt in de platformtabel, zo nee: insert & count=1, zo ja: update set count=count+1

[ Voor 3% gewijzigd door X-Lars op 06-02-2004 16:57 ]

[Verwijderd]

ok, totally clear nu!

Tnx a lot voor de duw in goede richting! Ik ga nu deze structuur gebruiken (en zelf vast nog wel wat veranderen) en dan zal ik daarna wel gaan denken over wel niet/xml wegschrijven en dat soort dingen

Alle anderen: ook tnx!

[Bosmonster]

Das wel een hele berg queries voor een enkele stats-update vind je ook niet?

Ik lees 9 updates/inserts + 9 checks = 18 queries per pagina

Of mis ik iets? Hoe krijg je bovendien de referrer in de externe javascript?

[ Voor 22% gewijzigd door Bosmonster op 06-02-2004 17:48 ]

[X-Lars]

@Bosmonster: het kleinste aantal queries is 15 8. maar als het een nieuwe user betreft, en platform etc. komt nog niet voor: 27. allemaal hele eenvoudige queries, afaik kun je niet meerdere tabellen in 1x updaten.

ach, ik zet het wel ff online:

files offline

[ Voor 51% gewijzigd door X-Lars op 08-02-2004 21:25 . Reden: Foute berekening minimum aantal queries ]

[Suepahfly]

Mag ik TS even wijzen op PHP OpenTracker
Dat kan alles wat jij wil en moet nog effcient draaien ook (zelf nooit geprobeerd)
'T is wel niet zo leuk als helemaal zelf maken, misschien kan je wat ideen op doen voor je eigen tracker

[ Voor 8% gewijzigd door Suepahfly op 06-02-2004 19:28 . Reden: verkeerde url ]

[Bosmonster]

X-Lars schreef op 06 februari 2004 @ 18:37:
@Bosmonster: het kleinste aantal queries is 15 8. maar als het een nieuwe user betreft, en platform etc. komt nog niet voor: 27. allemaal hele eenvoudige queries, afaik kun je niet meerdere tabellen in 1x updaten.

Persoonlijk zou ik dit onacceptabel vinden. Simpele queries of niet, een stats-systeem mag in mijn opinie maximaal 1-3 simpele queries per pagina in beslag nemen (geen 9-27!!). Bij een grote hoeveelheid bezoekers/hits hangt jouw hele systeem op duizenden inserts/updates die per minuut er doorheen geragd worden.. en dat is nog maar per site (laat staan als je meerdere sites op 1 server draait).

Het is een kwestie van uitbalanceren. Je doet of heel veel per hit en minder bij het parsen van stats, of je doet weinig per hit en het parsen van stats kost meer tijd. Bij een stats-systeem lijkt het me dat het zwaartepunt bij het parsen moet liggen en niet zoals in jouw geval bij iedere hit. Liever dat er een keer in de week een script een paar minuten bezig is met het parsen van stats dan dat iedere hit 9-27 queries nodig heeft...

@Suepahfly
phpOpenTracker is een leuk stukje software, maar het heeft dezelfde problemen als veel andere stats systemen. Het is relatief traag. In de laatste PHP Architect stond er een hele review over dit systeem en bij een database met 600.000 records was die al een half uur bezig ofzo. En 600K records voor een statsdatabase is nou niet heel erg veel.

[ Voor 16% gewijzigd door Bosmonster op 07-02-2004 16:00 ]

[X-Lars]

Bosmonster schreef op 07 februari 2004 @ 15:57:
[...] Persoonlijk zou ik dit onacceptabel vinden. [...] Het is een kwestie van uitbalanceren. [...]

You're totally right, simple as that.

Ik ga er nog maar eens goed over nadenken, dit is ook maar m'n eerste stats-systeempje.

Toch houd ik deze "versie" qua principe wel vast, omdat het ook zo z'n voordelen heeft, vnl. door de eenvoudige installatie. En met weinig bezoekers bedoel ik ook echt weinig: no way dat dat boven de 500 per dag komt ofzo. Dat zou met bijvoorbeeld 100% nieuwe visitors en 5 kliks door de website (ik zeg zomaar wat) uitkomen op 33.500 queries/dag = gemiddeld 1 query per 2,6 seconden. Pieken niet meegenomen natuurlijk. Lijkt me meevallen, dit soort orde van groottes.

Alleen moet ik nog uitzoeken hoe het zit met dat parsen van de stats. En als ik weet hoe dat moet kan ik net zo goed direct werken aan een nieuwe versie

[Bosmonster]

Gewoon de informatie die je nodig hebt in een record gooien. Heb je maar 1 insert per gebruiker. Later kun je wel scripts schrijven die die berg data uitlezen en conclusies trekken. Als je niet alle originele data wilt bewaren (zoals ik eerder al zei kan zo'n tabel dan flink uit de kluiten groeien) kun je de originele data ook weggooien en alleen de resultaten in een losse resultaten tabel of bestand opslaan.

Voordeel is dat je minimale load hebt per gebruiker. Zelf doe ik het overigens in 2 tabellen. Eentje met hit-informatie en eentje met referrer informatie. Referrer stats zijn vaak vrij lange urls en alleen interessant als ze extern zijn. Dat scheelt dus weer wat dubbele informatie. Tenzij je ook complete click-paths wilt gaan bijhouden natuurlijk

[X-Lars]

True. Dat had ik ook wel bedacht, ik heb alleen nog niet eerder gewerkt met cronjobs/bijbehorende scripts. Vraag ik me alleen nog af hoe jij referrer stats bepaalt?

Bosmonster schreef op 06 februari 2004 @ 17:47:[...] Hoe krijg je bovendien de referrer in de externe javascript?

Gezien het feit dat je voor resoluties/kleuren waarschijnlijk wel van javascript gebruikt zult maken, die stuur je door naar een PHP-script. In dat script is de referrer dan de 'current page' (waar het js in staat), dus zul je de referrer toch al in de js moeten bepalen?

[Verwijderd]

Hmm...die manier van X-Lars lijkt mij idd bij nader inzien niet zo efficient...

@bosmonster: Dus eigenlijk lijkt jouw het beste om gewoon elke keer alles in een row te gooien, en dan maar optijd uitlezen enzo? (waarbij alles word geleegd uit de hit tabel, en er archief tabellen gevuld worden?)

[Verwijderd]

Nog steeds een discussie aan de gang

jah kijk die 7 tot 27 query's kunnen wel als je op een piep kleine site zit, dan kan alles

maar zodra je weet dat je elke seconden meedere hits / query's moet verwerken dan moet je toch gaan kijken.

want je hebt buiten je stats ook andere systemen die query's vereisen.

session's, authentication, site listing, forum listing, menu generation (veel select maar goed) en weet ik veel niet wat nog meer... en dan kun je niet ff nog 7 query's er bij hebben...

beste is gewoon verwerken met 1 / max 2 query's en dan wanneer de site weinig load heeft analyseren (of met een andere server). Dan zou je best gewoon volledige stats per dag kunnen uitdraaien (of half stat's zoals ik dat doe, boven uitgelegd).

elke site heeft zijn eigen gebeuren, bij de een is het savonds rustig en bij de ander smiddags..

[Verwijderd]

Bosmonster schreef op 07 februari 2004 @ 23:30:
Gewoon de informatie die je nodig hebt in een record gooien. Heb je maar 1 insert per gebruiker. Later kun je wel scripts schrijven die die berg data uitlezen en conclusies trekken.

Mag ik dan vragen hoe jij die informatie in de database zet (want het moet toch enigzins geordend zijn wil je er iets mee kunnen doen)? Gebruik je bijvoorbeeld array's en prop je het via serialize in de database?

Alvast bedankt.

[Bosmonster]

Verwijderd schreef op 08 februari 2004 @ 16:17:
[...]


Mag ik dan vragen hoe jij die informatie in de database zet (want het moet toch enigzins geordend zijn wil je er iets mee kunnen doen)? Gebruik je bijvoorbeeld array's en prop je het via serialize in de database?

Alvast bedankt.

Neuh gewoon een grote tabel met bijvoorbeeld:

IP, sessie-var (voor unieke bezoekers/hits bepaling), useragent-string, datum/tijd uiteraard, pagina, referrer, etc

Als je via javascript werkt kun je daar nog dingen aan toevoegen als resolutie, kleurdiepte, flashversie, noem maar op.

Als je alleen al de records ophaalt van een bepaalde IP/sessie combinatie geordend op tijd heb je een click-path voor een specifieke gebruiker om maar iets te noemen. Simpele kan niet

Verwijderd schreef op 08 februari 2004 @ 11:07:
Hmm...die manier van X-Lars lijkt mij idd bij nader inzien niet zo efficient...

@bosmonster: Dus eigenlijk lijkt jouw het beste om gewoon elke keer alles in een row te gooien, en dan maar optijd uitlezen enzo? (waarbij alles word geleegd uit de hit tabel, en er archief tabellen gevuld worden?)

Mwah als je iets schrijft voor bijvoorbeeld je eigen site en je weet dat je niet superveel bezoekers trekt dan scheelt dit je werk achteraf. Maar wil je iets gestandaardiseerds maken dat voor meerdere sites gaat werken (ook zwaardere) en je wilt je server niet teveel belasten (wij draaien een eigen servers bijvoorbeeld en hoe meer sites we daarop kunnen draaien hoe meer $$ we verdienen ). Dan probeer je de load zoveel mogelijk te verdelen en is een zwaardere query om 4:00 snachts fijner dan een berg inserts per hit

[ Voor 37% gewijzigd door Bosmonster op 08-02-2004 16:28 ]

[X-Lars]

Wat mijn voorbeeld betreft hierboven ergens: ik heb een soort van denkfout gemaakt door alle data (platform, useragent (=browser), resolution) aan iedere (unieke) user te willen koppelen. Da's leuk om te zien in je stats, maar helemaal niet noodzakelijk. Mocht dit om welke redenen dan ook wel van belang zijn, dan is mijn oplossing toch zo gek nog niet. Ik zou me er iets bij voor kunnen stellen. (Dat het dus van belang is dat je van iedere bezoeker van de site de specs weet en dit ook bewaard zal blijven, wat met de andere oplossing IMO niet het geval is.)

Bosmonster geeft al aan dat je bijvoorbeeld unieke hits en clickpaths met sessions kunt bepalen. (Iedere dag ff een kruistabelletje parsen je hebt een schitterend leesbaar clickpath-plaatje (onderaan) ) Nog maar ff bedenken hoe je clickpaths leuk in beeld kunt brengen

X-Lars is vastbesloten een X-Tracker te bouwen

[X-Lars]

edit != quote

[ Voor 96% gewijzigd door X-Lars op 08-02-2004 21:24 ]

[Bosmonster]

Over het in beeld brengen van clickpaths trouwens.. Als je per pagina al een top 3 kunt genereren van meest gebruikte volgende pagina's heb je al zeer interessante informatie (weet je waar de mensen het liefst naar toe gaan vanaf die pagina). Dit zou je nog kunnen combineren met een top3 waar mensen het meest vandaan komen.

Is al een stuk overzichtelijker dan dat geval van phpOpenTracker