It should be reasonably performant even on a large content repository.
Rather than update the Content itself, the counters are stored in a small table in the database. When the view count is incremented, the database is hit at most 5 times and only the view counter tables are hit. at most 2 updates (1 if you turn off the View Count History using the Data Type) and the rest are simple lookups with no joins.
If you only lookup the viewcount using ViewCount.GetViewCount() without setting the Increment flag, there will only be one call to the database.
I haven't yet done any performance analysis on it though. I have been thinking of ways to cache the current view count - perhaps in memory - which will help with those pages where you list content items and want to display the view count of each one...
I used something similar on http://chickenchannel.com.au last year which does a lookup on the view count for each item in the list from the database... doesn't seem to have affected the speed of the site significantly... The Recipes page is a good example.
Hi Robert and thanks for the answer. I think that storing the db without using the umbraco API is the best solution. I'll do a little 'experiments with and without the package on, but I'm pretty sure that the solution is efficient.
Performance question
Hello and congratulations for the project.
One question: what kind of impact is on the overall performance of the site?
Which technique do you use to update the page each visit?
I have a website on which I should implement your project, but one of requirement is speed.
thanks
Alessio
Hi Alessio,
It should be reasonably performant even on a large content repository.
Rather than update the Content itself, the counters are stored in a small table in the database. When the view count is incremented, the database is hit at most 5 times and only the view counter tables are hit. at most 2 updates (1 if you turn off the View Count History using the Data Type) and the rest are simple lookups with no joins.
If you only lookup the viewcount using ViewCount.GetViewCount() without setting the Increment flag, there will only be one call to the database.
I haven't yet done any performance analysis on it though. I have been thinking of ways to cache the current view count - perhaps in memory - which will help with those pages where you list content items and want to display the view count of each one...
I used something similar on http://chickenchannel.com.au last year which does a lookup on the view count for each item in the list from the database... doesn't seem to have affected the speed of the site significantly... The Recipes page is a good example.
Hi Robert and thanks for the answer.
I think that storing the db without using the umbraco API is the best solution.
I'll do a little 'experiments with and without the package on, but I'm pretty sure that the solution is efficient.
thanks
Alessio
is working on a reply...