De afgelopen dagen heb ik mij bezig gehouden met statistieken. Jurriaan had gevraagd om eens te kijken hoeveel moeite Engagor moet doen om de data van vimeo binnen te halen, wat de resultaten daar van zijn, hoe lang de verwerking duurt etc. Het heeft een aantal dagen geduurd om alle informatie te verzamelen en om te zetten naar bruikbare gegevens maar hier is het resultaat.
Logs
De bovenstaande tabel
toont een aantal statistieken uit de logs gedurende één dag voor
een druk account.
Een aantal punten vallen hier in op:
Een aantal punten vallen hier in op:
- Als er een paar extra calls zijn naar vimeo dan verhoogt de processtijd direct met enkele seconden. Het aantal extra seconden verschilt wel per keer. Hier wordt in de benchmark verder op in gegaan.
- Het aantal nieuwe resultaten staat ook op het eerste zicht niet in verband met het aantal requests. Hier is echter wel een reden voor. Bij het opvragen worden er minimum twee calls gedaan. Één voor de activiteit van het Vimeo account zelf en één voor de interactie van anderen met dat Vimeo account. Indien de laatste activiteit van de call recenter is als de laatste run zullen er calls worden gedaan tot alle activiteit is binnen gehaald sinds de laatste keer. Meestal zal het echter bij twee calls in totaal blijven. Deze activiteit word samen gestoken in één gemeenschappelijke feed.
Hierna zullen er extra calls worden gedaan als er uploads of likes in de feed zitten omdat de megeleverde informatie over de videos niet voldoende is om een mention weer te geven. Tijdens het verwerken van deze feed zullen er indien nodig ook weer extra calls gebeuren om de ontbrekende likes en comments binnen te halen. Hierdoor zal het totaal aantal calls verschillen naar gelang welke activiteit er op het Vimeo account is geweest. - De intervallen tussen de runs worden niet gerespecteerd tijdens de werkuren. Dit is echter geen toeval. In de classe Fetcher, die hier verantwoordelijk voor is, kunnen deze intervals worden verkort indien er bepaalde triggers zijn. Als een gebruiker inlogt op Engagor of er wordt een desktop notification weergegeven dan zal de tijd tussen deze runs anders worden berekend om te zorgen dat zo lang de gebruiker engagor heeft open staan deze steeds actuele informatie heeft.
De bovenstaande tabel
toont een aantal statistieken uit de logs gedurende één dag voor
een rustig account. De volgende punten vallen op in deze tabel:
- Ondanks dat er zo goed als geen nieuwe activiteit binnen komt wordt er toch regelmatig gecontroleerd. Dit om dezelfde reden als beschreven bij het drukke account.
- Er is een error geweest. De feed die werd terug gegeven was geen array. Dit is echter iets dat in andere logs ook sporadisch terug te vinden is. Na verder onderzoek blijkt dit om interne errors te gaan in de Vimeo API zelf waardoor er niets aan gedaan kan worden.
- Het aantal requests blijft bij dit account gedurende de hele dag gelijk. Dit is het gevolg van de weinige activiteit waardoor er maar een zeer beperkt aantal extra gegevens nodig zijn.
Detectie tijd
Voor een druk account
bedraagt de gemiddelde tijd van een volledige dat tussen het posten
op Vimeo en het verschijnen hiervan in Engagor 40 minuten. Splitsen
we dit op naar tijdens de kantooruren (9 – 17 op de server is dit 7
– 15 door tijdzone) en daarbuiten dan bekomen we de volgende
resultaten:
Tijdens de kantooruren: 19
min
Buiten de kantooruren: 52
min
Voor een rustig account
bedraagt de gemiddelde tijd van een volledige dat tussen het posten
op Vimeo en het verschijnen hiervan in Engagor 37 minuten. Splitsen
we dit op naar tijdens de kantooruren (9 – 17 op de server is dit 7
– 15 door tijdzone) en daarbuiten dan bekomen we de volgende
resultaten:
Tijdens de kantooruren: 16
min
Buiten de kantooruren: 48
min
Api tijd
De gemiddelde tijd per API call is 844.712 ms. Met als max 1166.667 ms en als min 666.667 ms.Benchmarks
Bij de benchmarks is er een verschil gemaakt tussen een full run en een normal run. Het verschil hier tussen is dat bij een normal run er rekening wordt gehouden met wat er de vorige keer is binnen gekomen en hierdoor een aantal calls niet gemaakt zullen worden omdat die data al bekend is.Bij beide worden dezelfde accounts gebruik.
- Pulsefilmsltd is gekozen omdat deze een
groot aantal recente videos in hun activiteit hebben staan.
- Roberteddmovie is gekozen omdat een video
van dit account overlaatst vermeld is geweest bij de “Staff Picks”
op vimeo en hierdoor in de recente activiteit veel likes voorkomen.
- Jelmertest is gekozen omdat dit account in
de recente activiteit veel comments heeft ontvangen.
Full run
De bovenstaande tabel bevat de resultaten voor de full run benchmark.
De feed time blijft gedurende de verschillende runs rond dezelfde tijd schommelen in tegenstelling tot de ProcessWaitForApi. Dit is de tijd die nodig is om de calls te doen waarin de benodigde comments, likes en videos worden opgevraagd. Bij de 5de run is deze tijd opmerkelijk langer bij Jelmertest. Dit wordt veroorzaakt doordat op dat moment op 3 populaire videos is gereageerd door dat account en daardoor ook de benodigde data voor die videos opgevraagt moet worden. De hogere tijd is rechtstreeks het gevolg van de extra calls die nodig zijn om deze data binnen te halen..
Normal run
Het eerste verschil dat opvalt met een full run is dat er bijna nooit een processWaitForApi tijd is. Ook is er bij een normal run maar één keer een piek in run vijf. In run zes komt deze niet meer voor omdat hier rekening wordt gehouden met wat er al eerder is binnen gekomen. Dit is ook de reden achter het zo goed als ontbreken van processWaitForApi tijd. Het aantal requests is daardoor ook weer minder in de zesde run.
Verder kan je ook uit de grafiek opmaken dat hoe meer videos er in de feed zitten hoe langer de feedTime is. Dit komt doordat bij videos die in de activiteits feed zitten altijd extra info, en dus een extra call nodig hebben. Het zelfde geld voor likes die in deze feed zitten. Dit is echter minder makkelijk te onderscheiden omdat likes ook kunnen binnenkomen bij het verwerken van de feed in de feedprocessor.
