Door
Ariën
op 05-02-2019 15:37
gewijzigd op 05-02-2019 16:09
2.737 views
Voor mijn site zit ik met het idee om het aantal bezoekers van een artikel, review, video(pagina) etc.. (lees verder: 'item') te tellen. Uiteraard moet dit wel een beetje F5-proof zijn, zodat mensen die zich vervelen niet de boel omhoog kunnen proberen te kicken door op F5 te rammen. Aan de hand van het aantal hits wil ik uiteindelijk een simpel algoritme maken die bepaald hoe belangrijk een item is.
Ik heb al een idee bedacht om dit te kunnen realiseren:
Ikzelf zat te denken om op session-basis te werken, en aan de hand van een SessionID de gebruiker te herkennen. Elke hit die hij doet in een item wordt dan in een tabel hitcounter opgeslagen. Een hit op dezelfde pagina geldt pas als er drie minuten tussenzit vergeleken met de vorige. Dat voorkomt dat iemand per ongeluk even op 'back' drukt of iets dergelijks en dat dat ook als een hit wordt geteld.
Uiteindelijk moet een cronjob die elk uur draait ervoor zorgen dat het totaal van de hits netjes overgeplaatst wordt naar de hits-veld van het artikel, zodat ik dit kan gebruiken als in de algoritme.
Natuurlijk zal ik ook zorgen dat searchspiders met een eenvoudige user-agent en/of IP-range herkenning niet geteld zullen worden. Echter was ik benieuwd wat jullie van deze opzet vinden? Ook vroeg ik me af wat nu als er door [php]session_regenerate[/php] een nieuw SessionID wordt uitgegeven. Dan zal dit idee niet mer werken.
Wat vinden jullie van deze opzet? Opmerkingen hoor ik graag.
Een groot gedeelte is warm water uitvinden :)
kijk eens op https://www.phpjunkyard.com/. Vandaar vertrekkende voor je cronjob kan niet moeilijk zijn voor jou :)
"It uses flat-text database so no SQL databases are necessary"
Dat zoek ik dus niet. Juist databases zijn hiervoor bedoeld.
"Requirements: PHP 4.4 or newer"
Als daar nog rekening mee wordt gehouden, is het script mogelijk behoorlijk gedateerd....
Ik zoek geen kant en klaar (bloated) script, maar ik wil weten of mijn opzet een mooie basis is. Of iets wat er op lijkt, als het bestaat.
Een eerste ingeving zou zijn: sla een unieke hash op in de sessie. Maar ook dat gaat niet werken als de sessie verloopt. Sessies zou je ook niet kunstmatig in leven moeten houden, je moet gewoon voorzieningen treffen zodat deze naadloos kunnen doorstarten.
Sessies leven niet oneindig, maar zolang je binnen 28 minuten een teken van laat zien met een refresh, blijft de sessie toch leven? Het is niet zo dat je vanzelf na 28 minuten opeens merkt dat je sessie niet meer werkt? Dat heb ik nooit gemerkt.
Ik kan eventueel ook een cookie plaatsen met een randomID en de huidige begindatum erin, die ik kan gebruiken voor de hitcounter-table.
De finger print van user agent + IP-adres is redelijk uniek. Als je daar nog een cookie met een unieke ID aan toevoegt, kun je veel clients ook nog herkennen vanaf een ander IP-adres.
Nee, ik wil bijhouden of iemand al eerder het item bekeken heeft. Dan lijkt een hitcounter-table mij de beste oplossing, waarna je dan per item alle hits met regelmaat extraheert naar een aantal unieke bezoeken voor in de tabel van de items. Of weet jij wat beters?
Kun je iedere pagina niet een ID geven en dan als de pagina wordt bezocht het bezoekersaantal van die pagina met 1 ophogen in de database en in de sessie bijhouden welke ID reeds door de bezoeker is bekeken? (eventueel met timestamp)
Je verschuift de tijdelijke opslag van het aantal hits dus dan naar de sessie-kant in plaats van de database.
An sich zou het kunnen, en ook met een timestamp. Want na 3 minuten zou een item die her-bezocht wordt weer een nieuwe hit mogen zijn. Maar misschien ga ik deze tijd nog aanpassen. Ik weet nog niet echt wat een mooie waarde hiervoor is.
Maar het aantal unieke hits per item moet ook weer bekend worden bij het item. Dus of dit een idee is, betwijfel ik. Ik wil immers toch wat leuke 'Meest bekeken' algoritmes bouwen, waar een vaste waarde handig voor is...
Als je dit apart uit de hitcounter-tabel moet halen bij elk algoritme wordt het wel erg zwaar. Plus dat het niet heel accuraat hoeft te zijn.
Sessies leven niet oneindig, maar zolang je binnen 28 minuten een teken van laat zien met een refresh, blijft de sessie toch leven? Het is niet zo dat je vanzelf na 28 minuten opeens merkt dat je sessie niet meer werkt? Dat heb ik nooit gemerkt.
Hangt van garbage collection en platform af? Misschien is deze data achterhaald, maar vroegah detecteerde Windows platforms bijvoorbeeld niet de access time van een sessie-bestand (omdat deze simpelweg niet in het filesysteem wordt bijgehouden?), enkel de modification time. Dus als een actieve sessie niet inhoudelijk werd bijgewerkt werd deze op den duur toch geflagged als garbage.
- Ariën - op 05/02/2019 21:41:45
Je verschuift de tijdelijke opslag van het aantal hits dus dan naar de sessie-kant in plaats van de database.
Een sessie is geen rijdend archief. Als dit bestanden betreft zou ik dit niet doen.
