Goede manier views bijhouden (Laravel)

[Verwijderd]

Beste tweakers, momenteel ben ik met een hobby project bezig met het PHP framework Laravel dat ik uiteindelijk wel serieus wil gaan gebruiken. Dit project wordt een website waarop o.a. artikelen geplaatst worden middels het beheersysteem/CMS wat ik erachter aan het bouwen ben. Voor analytische doeleinden zou ik in dat systeem ook graag een duidelijk overzicht hebben met hoe vaak een artikel bekeken wordt. Ik heb met het bijhouden van views nog nooit echt wat gedaan, dus nu vroeg ik mij af wat hier een goede, of zelfs de beste manier voor zou zijn.

Een makkelijke manier lijkt mij om iedere keer wanneer iemand op een artikel komt, simpelweg een increment uit te voeren op de views kolom van het betreffende artikel. Zoals gezegd simpel, maar het nadeel hiervan lijkt me dat wanneer de site druk bezocht wordt dit voor onnodige belasting zorgt op de server. Ook kun je op deze manier constant de pagina refreshen waardoor de increment iedere keer wordt uitgevoerd. Zorgt dit daadwerkelijk voor noemenswaardige extra belasting? Naast de belasting op de server lijkt mij dit overigens niet eens zo'n probleem, want wanneer iemand naar een artikel gaat, en vervolgens naar een ander artikel, maar daarna toch weer terug wil naar het eerste artikel, vind ik dat persoonlijk wel een increment waard. Het throttlen van views via de session wordt ook wat lastiger op deze manier. Is views throttlen via de sessie überhaupt een goede manier, rekening houdens met het voorbeeld hierboven?

Via stackoverflow kwam ik ook nog deze tegen:

PHP:

$sample_rate = 100;
if(mt_rand(1,$sample_rate) == 1) {
    $query = mysql_query(" UPDATE posts SET views = views + {$sample_rate} WHERE id = '{$id}' ");
    // execute query, etc
}

Edit: Bron: https://stackoverflow.com...t-page-views-in-php-mysql

Waarmee de kans 1 op de 100 is dat er 100 views bijkomen. Dit lijkt mij niet heel geschikt, maar het idee is wel leuk en bij vele aantallen views misschien nog best bruikbaar. Maar met een beetje pech kan het verre van nauwkeurig zijn wanneer artikelen niet vaak worden bekeken.

Ik lees ook dingen over Memcache, maar ik ben het liefste zo min mogelijk afhankelijk van of een server dergelijke extensies beschikbaar stelt, dus als er andere oplossingen zijn heeft dat de voorkeur.

Ik hoor graag wat jullie hierover te zeggen hebben .

[NMe]

Waarom ben je met dergelijke micro-optimalisaties bezig nog voor je weet of ze een probleem vormen of niet?

Los daarvan: dat soort tellertjes stop ik vaak in Redis als de database niet te veel belast mag worden.

[Verwijderd]

Graag zou ik het vanaf het begin op een goede manier aanpakken. Nu ik mijn startpost zo terug lees komt het niet heel duidelijk naar voren, maar het doel is voornamelijk dat de views redelijk betrouwbaar zijn. Eventuele optimalisaties zijn mooi meegenomen, maar is (nog) niet het belangrijkste.

Zal eens naar Redis kijken.

[Cartman!]

Redis klinkt wel erg als overkill voor een beginnend hobby-projectje alleen ondanks dat ik er groot fan van ben. Maak anders gewoon een abstractielaagje en gebruik nu gewoon je huidige database ervoor zodat je t bij eventuele problemen makkelijk kunt vervangen.

Mocht je wel voor Redis gaan, wat overigens veel meer functies heeft dan Memcached, kun je ook een key bijhouden met een vervalmoment (TTL) en pas daarna weer een view opnemen voor deze user. Of de volgende stap: dit in een lua-scriptje verwerken in Redis zelf.

Overigens zie ik dat je de mysql_* functies lijkt te gebruiken, die zijn deprecated in PHP 5 en bestaan niet meer in PHP 7. Bovendien lijkt je code nu ook vatbaar te kunnen zijn voor SQL Injection. In Laravel zit Eloquent en daarmee kun je wel veilig queryen in PHP 5 en 7.

[Verwijderd]

@Cartman! Bedankt voor je reactie. Dat stukje code was een voorbeeld van stackoverflow. Heb in de startpost even de bron erbij gezet voor de duidelijkheid. Ging om het idee erachter. Ik maak uiteraard gebruik van Eloquent .

[NMe]

Verwijderd schreef op zondag 1 oktober 2017 @ 19:00:
Graag zou ik het vanaf het begin op een goede manier aanpakken. Nu ik mijn startpost zo terug lees komt het niet heel duidelijk naar voren, maar het doel is voornamelijk dat de views redelijk betrouwbaar zijn. Eventuele optimalisaties zijn mooi meegenomen, maar is (nog) niet het belangrijkste.

Veel betrouwbaarder dan UPDATE article SET views = views + 1 WHERE id = <jouw_artikel> bovenaan in je controller wordt het niet? Maar jij wil helemaal geen views tracken, je lijkt vooral dingen te willen doen waar spul als Google Analytics veel beter in is.

[Verwijderd]

Ja ik zou graag zien welk soort artikelen de doelgroep het meeste aanspreekt. Google Analytics gaat uiteraard ook gebruikt worden en ik denk inderdaad wel dat het zal voldoen. Het zou alleen wel handig zijn om dit ook te kunnen zien in het overzicht van alle artikelen in het CMS. Ik bedenk me nu ook dat het wel leuk kan zijn om bijvoorbeeld een rijtje van de populairste artikelen te tonen aan de voorkant. Ik denk dat ik dan maar gewoon begin met die simpele increment .

[Morax]

Wat je ook zou kunnen doen is een temp file aanmaken en het daar tijdelijk in bijhouden. 1 keer in de zoveel tijd kan je dan de file uitlezen en het aantal wegschrijven in de database. Zorgt er wel voor dat je aantal dus niet altijd volledig actueel is. Plus je moet wel een beetje nadenken over meerdere processen die tegelijkertijd naar de file willen schrijven, dus de vraag is dan uiteindelijk wat je winst is

[NMe]

Verwijderd schreef op zondag 1 oktober 2017 @ 19:51:
Ja ik zou graag zien welk soort artikelen de doelgroep het meeste aanspreekt. Google Analytics gaat uiteraard ook gebruikt worden en ik denk inderdaad wel dat het zal voldoen. Het zou alleen wel handig zijn om dit ook te kunnen zien in het overzicht van alle artikelen in het CMS. Ik bedenk me nu ook dat het wel leuk kan zijn om bijvoorbeeld een rijtje van de populairste artikelen te tonen aan de voorkant. Ik denk dat ik dan maar gewoon begin met die simpele increment .

Zou ik inderdaad gewoon doen. Da's gewoon voor de leuk en een aardige indicatie, verdere statistieken kun je veel beter in Analytics opzoeken, heb je meteen allerlei filtermogelijkheden e.d.

[kwaakvaak_v2]

NMe schreef op maandag 2 oktober 2017 @ 13:38:
[...]

Zou ik inderdaad gewoon doen. Da's gewoon voor de leuk en een aardige indicatie, verdere statistieken kun je veel beter in Analytics opzoeken, heb je meteen allerlei filtermogelijkheden e.d.

Stuur dan wel GA met PHP aan, want met steeds meer cookie blockers wordt het tracken via JS steeds minder betrouwbaar.

[Cartman!]

Morax schreef op maandag 2 oktober 2017 @ 11:10:
Wat je ook zou kunnen doen is een temp file aanmaken en het daar tijdelijk in bijhouden. 1 keer in de zoveel tijd kan je dan de file uitlezen en het aantal wegschrijven in de database. Zorgt er wel voor dat je aantal dus niet altijd volledig actueel is. Plus je moet wel een beetje nadenken over meerdere processen die tegelijkertijd naar de file willen schrijven, dus de vraag is dan uiteindelijk wat je winst is

Waarom zou je dit verkiezen boven een DB?

[Stoelpoot]

Analytics is inderdaad gewoon hetgeen wat je wilt. Eventueel kan je in het beheerpaneel de Analytics API aanspreken? Anders ga je echt het wiel opnieuw uitvinden.

[Gomez12]

Morax schreef op maandag 2 oktober 2017 @ 11:10:
Wat je ook zou kunnen doen is een temp file aanmaken en het daar tijdelijk in bijhouden. 1 keer in de zoveel tijd kan je dan de file uitlezen en het aantal wegschrijven in de database. Zorgt er wel voor dat je aantal dus niet altijd volledig actueel is. Plus je moet wel een beetje nadenken over meerdere processen die tegelijkertijd naar de file willen schrijven, dus de vraag is dan uiteindelijk wat je winst is

Je winst is niets, feitelijk heb je alleen maar verlies.

Je database kan gewoon omgaan met concurrent connections, je filesystem niet.

Oftewel je gaat allerlei locks creeeren en handmatig mogen opvangen op files terwijl dit gewoon ingebakken zit in je dbase.

De vraag is eerder waarom je dit in hemelsnaam zou willen bedenken?

[Richh]

Waarom het wiel opnieuw uitvinden? Google Analytics doet wat je wil. Mocht je daar een afkeer tegen hebben, dan bestaat er bijvoorbeeld Piwik, of talloze andere tracking systemen.

Veel trackers hebben een API beschikbaar waardoor je het aantal pageviews ook in je CMS kan tonen.

[Verwijderd]

Bedankt voor de reacties iedereen. Google Analytics zal inderdaad ook gewoon gebruikt worden, maar zoals hierboven genoemd zou ik ook graag de mogelijkheid hebben om bijvoorbeeld makkelijk de populairste artikelen te tonen op de website, of om te filteren van populair naar minder populair of andersom, dat soort dingen. Daarvoor lijkt het me het makkelijkste om zelf ook de views bij te houden. Met alleen een simpele increment valt het wiel opnieuw uitvinden wel mee denk .

[Swedish Clown]

Verwijderd schreef op dinsdag 3 oktober 2017 @ 12:40:
Bedankt voor de reacties iedereen. Google Analytics zal inderdaad ook gewoon gebruikt worden, maar zoals hierboven genoemd zou ik ook graag de mogelijkheid hebben om bijvoorbeeld makkelijk de populairste artikelen te tonen op de website, of om te filteren van populair naar minder populair of andersom, dat soort dingen. Daarvoor lijkt het me het makkelijkste om zelf ook de views bij te houden. Met alleen een simpele increment valt het wiel opnieuw uitvinden wel mee denk .

Ik heb nul ervaring met GA maar het lijkt me dat die een API hebben waar je eens in de X uur de data kan binnen hengelen of niet? Is realtime echt nodig?

[Verwijderd]

@Brakkie41 Dat is inderdaad een goed idee, real time is niet nodig. Als de views 1 keer per zoveel tijd updaten is ook prima. Thanks voor de suggestie.

[Xalephsis]

je kunt ook gewoon een cron job instellen die om de zoveel minuten je access logs scant, enige wat je dan hoeft op te slaan is de laatste regel waar je gebleven bent en de nieuwe regels uitlezen, kun je voor al je page views bijhouden hoe vaak iets voorbij gekomen is.

[kwaakvaak_v2]

Klinkt allemaal wel heel ingewikkeld voor iets wat in essentie gewoon een += value dingetje is. Net of het een een doodzonde is om data in een database op te slaan.