[PHP] Webcounter, wat is ideaal?

[Verwijderd]

Ik ben bezig om een simpele webcounter te maken in PHP. Deze moet zowel het aantal hits als het aantal unieke bezoekers per dag gaan bijhouden. Belangrijk is dat de counter op veel pagina's komt die staan die erg veel bezoekers/pageviews krijgen. Efficient programmeren is dus vereist. Nu vraag ik me eigenlijk 2 zaken af:

1. Wat is de beste methode om unieke bezoekers te tellen?
Ik wil zo min mogelijk data opslaan in database/textfiles, dus zou daarom kiezen voor cookies. Bij bezoek een simpele cookie plaatsen met 24-uur geldigheid. Bij elk nieuw bezoek checken of cookie aanwezig is. Zo ja, dan alleen een hit, geen nieuwe bezoeker. Zo nee, dan zowel hit als nieuwe bezoeker. Maar hoe ga je om met mensen die geen cookies accepteren (met name de mensen die dat bewust doen om de counter op te krikken)? Moet je dan van deze mensen de IP's gaan opslaan in database/textfile?

2. Wat is de beste methode om data op te slaan?
Om te voorkomen dat bij elke pageview minimaal 1 querie moet worden uitgevoerd (update views), kan je kiezen voor weg te schrijven in een bestandje. Maar zoals hier ([PHP] Webcounter met reload beveiliging) al beschreven, kan dat problemen geven als meerdere gebruikers naar dat bestandje schrijven. Dat is dus geen optie. Kortom, een database de meest ideale manier?

Voor de duidelijkheid: ik wil dus zo weinig mogelijk data opslaan in database/textfiles, aangezien het aantal views/users nogal groot kan zijn. Eigenlijk ook de vraag: hoe doen grote partijen als Nedstat/Onestat dat?

Hoop dat jullie wat ideeen met me willen wisselen.

[Osiris]

Verwijderd schreef op vrijdag 12 oktober 2007 @ 00:57:
2. Wat is de beste methode om data op te slaan?
Om te voorkomen dat bij elke pageview minimaal 1 querie moet worden uitgevoerd (update views), kan je kiezen voor weg te schrijven in een bestandje. Maar zoals hier ([PHP] Webcounter met reload beveiliging) al beschreven, kan dat problemen geven als meerdere gebruikers naar dat bestandje schrijven. Dat is dus geen optie. Kortom, een database de meest ideale manier?

Ik heb verder geen idee hoe je dingen nou wel 't beste kunt regelen, maar hoezo heb je het idee dat het zelf 'handmatig' wegschrijven in een file een grotere performance geeft dan het te fixen via een programma wat er voor gebouwd is? (Een database dus.) Je wilt een query vermijden; ik vraag me af waarom, want zelf aan je filesystem gaan kloten lijkt me een hogere performance-hit te geven.

[xtra]

Misschien geen tips maar een paar suggesties.

100% betrouwbaar krijg je het nooit dus het is misschien niet nodig voor ieder probleem de ultieme oplossing te vinden. Volgens mij zijn er relatief weinig mensen die geen cookies accepteren dus valt dat wel weg in de grote getallen. Het IP adres gebruiken is dan schijnbetrouwbaarheid want met NAT, publieke computers etc. krijg je weer andere misrekeningen.

Mijn ervaring was dat een hele serie inserts heel traag wordt door indexen. Ik heb dat opgelost door de 'live' tabel regelmatig te verplaatsen naar een werktabel. Daar kun je dan weer indexen op loslaten. Ik had nog eens bedacht de resultaten tussentijds op te slaan in een (ASP) applicatievariabele maar nooit uitgevoerd.

Als je je logica toevoegt aan je PHP pagina's kan het zijn dat je hele site traag wordt. Een image zoals NedStat etc. dat doen vertraagt niet je hele site. En op je pagina's kun je gewoon nette cache-instellingen blijven gebruiken.

[disjfa]

xtra schreef op vrijdag 12 oktober 2007 @ 01:41:
Mijn ervaring was dat een hele serie inserts heel traag wordt door indexen. Ik heb dat opgelost door de 'live' tabel regelmatig te verplaatsen naar een werktabel. Daar kun je dan weer indexen op loslaten. Ik had nog eens bedacht de resultaten tussentijds op te slaan in een (ASP) applicatievariabele maar nooit uitgevoerd.

Dat heet database optimalisatie. Een paar indexen kan wonderen doen. En een insert doen niet moeilijk

Verder is een unieke teller op een 24h counter gewoon vreemd Kijk gewoon wat je wilt opslaan en hoe. Dan kan je alles.

[xtra]

disjfa schreef op vrijdag 12 oktober 2007 @ 01:44:
[...]

Dat heet database optimalisatie. Een paar indexen kan wonderen doen. En een insert doen niet moeilijk

Ach, wat is optimaal. Bij alleen een primary key werd het na een paar dagen en soms 200 pageviews/inserts per seconde wel wat traag. 2 seconden extra laadtijd per pagina vond ik niet optimaal.
Volgens mij had ik een aardige oplossing gevonden.

[CodeCaster]

Wanneer je, zoals xtra ongeveer aangeeft, je éigen tellerscript in een op elke pagina zichtbare afbeelding (voor mijn part een 1x1 pixel grote doorzichtige .gif) verwerkt, zal deze geladen worden terwijl de rest van de pagina al zichtbaar wordt.

Dit zal geenszins de load op je server verlagen, de laadtijd van je pagina's zal echter wel verbeteren.

[ Voor 3% gewijzigd door CodeCaster op 12-10-2007 03:00 ]

[RobIII]

xtra schreef op vrijdag 12 oktober 2007 @ 02:24:
[...]

Ach, wat is optimaal. Bij alleen een primary key werd het na een paar dagen en soms 200 pageviews/inserts per seconde wel wat traag.

Dat heeft echt niet aan een simpele insert gelegen. Waarschijnlijk heeft het te maken gehad met het geheel dat te zwaar werd voor je Web/DB server. Maar zelfs het meest knullige DBMS op de markt moet easy 200 inserts p/s afkunnen hoor. Indexen erop of niet.

xtra schreef op vrijdag 12 oktober 2007 @ 02:24:
2 seconden extra laadtijd per pagina vond ik niet optimaal. Volgens mij had ik een aardige oplossing gevonden.

En een insert op zo'n simpele tabel mag al helemaal geen 2 seconden duren. Vraag me dan toch af of je wel goed 'gemeten' hebt en of die 'teller' dan wel de oorzaak was.

Osiris schreef op vrijdag 12 oktober 2007 @ 01:33:
[...]

Ik heb verder geen idee hoe je dingen nou wel 't beste kunt regelen, maar hoezo heb je het idee dat het zelf 'handmatig' wegschrijven in een file een grotere performance geeft dan het te fixen via een programma wat er voor gebouwd is? (Een database dus.) Je wilt een query vermijden; ik vraag me af waarom, want zelf aan je filesystem gaan kloten lijkt me een hogere performance-hit te geven.

In principe is een FileSystem ook een DB. En of je dan een file opent (als je enkel een 'aantal' bijhoudt in die file is 'ie nog geen paar bytes groot) en het aantal update of dat je via een DB gaat; het zal weinig schelen. Daar komen nog disk caches en dat soort zaken bij en dan heb je net zo goed een flitsend-snelle oplossing. Het probleem waar je eerder tegen aan gaat lopen is dat je de file nog aan 't beschrijven bent terwijl de volgende 'hit' alweer zal veroorzaken dat je de file wéér wil openen; en dat gaat niet lukken maar boem doen

[ Voor 37% gewijzigd door RobIII op 12-10-2007 09:28 ]

[DaCoTa]

RobIII schreef op vrijdag 12 oktober 2007 @ 09:22:
[...]
Dat heeft echt niet aan een simpele insert gelegen. Waarschijnlijk heeft het te maken gehad met het geheel dat te zwaar werd voor je Web/DB server. Maar zelfs het meest knullige DBMS op de markt moet easy 200 inserts p/s afkunnen hoor. Indexen erop of niet.

Tot je buffersize te klein is om de update in memory uit te voeren. Die 200 is een schijntje, idd zelfs met indexen, maar dat getal gaat rap omlaag als je over miljoenen records heen gaat.

[sarcast]

Waarom niet gewoon de webserver access_log's uitlezen Of denk ik nu te simpel..

[gvanh]

Dat geeft inderdaad wel info over de bezoekersaantallen, maar geeft je niet de meer browser-afhankelijke informatie over bezoekers, zoals de resolutie/kleurdiepte die ze gebruiken. Of referers worden bijgehouden in de access_log weet ik eigenlijk niet. Indien niet, dan is dat ook nog een reden om via PHP zelf de info in een database weg te schrijven.

[MrMarcie]

Google analytics ?

Of gebruik TRACEWATCH.

[ Voor 34% gewijzigd door MrMarcie op 12-10-2007 10:29 ]

[Compusmurf]

Ik zou me hier als ik jou was ook niet teveel aan verbranden. Er zijn genoeg betrouwbare tellers op de markt die gratis zijn, denk aan Google Analytics.

Dit is een prima teller met veel functies, ik kan mij dus niet voorstellen dat je hier niet voldoende aan hebt.

Het heruitvinden van het wiel is dus niet nodig in dit geval tenzij je een reden hebt dat dit wel nodig is.

[gvanh]

Externe oplossingen zijn niet altijd zaligmakend. Het is natuurlijk prettig dat je zelf niet opnieuw het wiel hoeft uit te vinden. Aan de andere kant heb je vanuit je eigen systeem toegang tot alle gegevens die beschikbaar zijn. Denk bijvoorbeeld aan gegevens over welke gebruiker is ingelogd. Wanneer je een eigen autorisatie-systeem hebt, kun je daarmee allerlei info verzamelen over het percentage van bezoekers dat ingelogd rondloopt over je website en over bezoekers die niet zijn ingelogd.

Kán heel interessante info zijn.

Maar gut ... je moet wel tijd en zin hebben om zoiets te ontwikkelen natuurlijk.

[sarcast]

Hm, zou gewoon standaard scriptje als webalizer installeren.
Vist alle info die je nodig hebt uit de access logs.. inclusief referers, hits en visitors.
Mooie grafiekjes erbij en cirkel diagrammen waar ze vandaan komen.

Zoals eerder vermeld zou ik niet het wiel opnieuw gaan uitvinden als je niet echt custom made dingen nodig hebt.

[Grijze Vos]

sarcast schreef op vrijdag 12 oktober 2007 @ 10:45:
Hm, zou gewoon standaard scriptje als webalizer installeren.
Vist alle info die je nodig hebt uit de access logs.. inclusief referers, hits en visitors.
Mooie grafiekjes erbij en cirkel diagrammen waar ze vandaan komen.

Zoals eerder vermeld zou ik niet het wiel opnieuw gaan uitvinden als je niet echt custom made dingen nodig hebt.

Webalizer geeft geen 'live' statistieken, als ik het me goed herinner. (Is weer een tijd geleden dat ik dat gebruikt heb.) Misschien wil TS juist wel statistieken? OF misschien vind hij het stiekem gewoon leerzaam.

[Cartman!]

Naast Google Analytics gebruik ik tegenwoordig ook Clicky In tegenstelling tot Analytics wel realtime en voor een snel overzicht vind ik t duidelijk beter

[sarcast]

Grijze Vos schreef op vrijdag 12 oktober 2007 @ 10:53:
[...]

Webalizer geeft geen 'live' statistieken, als ik het me goed herinner. (Is weer een tijd geleden dat ik dat gebruikt heb.) Misschien wil TS juist wel statistieken? OF misschien vind hij het stiekem gewoon leerzaam.

Hm, nee dat is waar, webalizer werkt dmv een cronjob.
Maar de TS heeft het wel over een druk bezochtte website waarbij hij geen vertragingen wilt in de opbouw van een script.

In hoeverre dit te combineren is met realtime stats.. denk dat je altijd wel iets van een vertraging hebt.

[Grijze Vos]

sarcast schreef op vrijdag 12 oktober 2007 @ 11:46:
[...]


Hm, nee dat is waar, webalizer werkt dmv een cronjob.
Maar de TS heeft het wel over een druk bezochtte website waarbij hij geen vertragingen wilt in de opbouw van een script.

In hoeverre dit te combineren is met realtime stats.. denk dat je altijd wel iets van een vertraging hebt.

mwoah, dat valt an sich wel mee denk ik. Wat hij bijv. zou kunnen doen is in de database IP's bijhouden, en dit elke nacht om 00:00 flushen. Dan heeft ie voor de huidige dag een simpel hit en visitor countertje. Zou je daarnaast natuurlijk gewoon elke nacht je logs van de dag ervoor kunnen webalizen, en daarnaar doorlinken vanuit je stats overview.

Is dan wel een dubbele oplossing, maar wel betrekkelijk weinig eigen werk.

[YopY]

Grijze Vos schreef op vrijdag 12 oktober 2007 @ 11:57:
[...]

mwoah, dat valt an sich wel mee denk ik. Wat hij bijv. zou kunnen doen is in de database IP's bijhouden, en dit elke nacht om 00:00 flushen. Dan heeft ie voor de huidige dag een simpel hit en visitor countertje. Zou je daarnaast natuurlijk gewoon elke nacht je logs van de dag ervoor kunnen webalizen, en daarnaar doorlinken vanuit je stats overview.

Is dan wel een dubbele oplossing, maar wel betrekkelijk weinig eigen werk.

Zou ik ook doen; gewoon voor elke pageview een kleine insert doen op een 'smalle' database (indexen eigenlijk niet nodig) waar gegevens die jij hebben wilt opslaat, en elke dag / week / wat dan ook een script draaien die die gegevens verwerkt en in een propere database tabel zet (bv stats per uur, per dag, week, maand, etc)

[_Gekkie_]

Een goeie tip van YopY: kleine database (via MySQL als HEAP table?) en die om de paar minuten flushen naar een échte table. Die kan je dan weer via SP / Triggers automatisch laten aggregeren(?) naar een net overzicht zodat je daar boven op dus al gelijk een hele sjeike overzichten kunt leggen...