I'm creating a page view counter to trace the quantity of sights a webpage is getting on our website and exhibiting it towards the user. (I requested an intro question before: http://stackoverflow.com/questions/246919/page-view-counter-like-on-stackoverflow).
While using recommendations, I created a httpHandler that will handle the request whenever this will get fired off:
<link rel="stylesheet" href="cn.axd?t=1&id=232" type="text/css" />
Just wondering when the finish-user would have to wait for a request to become finish processing before they are able to view/communicate with the page.
Would a better option be applying an asynchronous queue where information will get drenched for an MS Queue and finally drenched within the database via (Exception Policy)
Will it be reduced to see if a particular record exist (PageID) and increment a counter or place the record in to the database and aggregate later if needed. We'd simply need to run an aggregation in the finish each week to determine the quantity of pageviews a specific page got within the week.
Inside my old company we maintained a webpage View counter and because the quantity of hits elevated so did the database table which introduced lower the web site to it's knees.
Whatever method you implement I suggest the next:
- Do card inserts constantly (they're faster than updates).
- Do them asynchronous therefore it does not block the primary thread and will not block future demands.
- Possess a nightly procedure that sumarizes the information and clears the table in point 1.
- Do your chooses from the summed up data.
We have found it was the best and scalable solution, although you won't have real-time data.
I'd opt for the logging method recommended within the other page, unless of course you have to track specific time/date of sights. My reasoning is just because of the amount of products which you may get while you application begins to scale up in dimensions.
Connecting towards the handler like a CSS style, shouldn't really stop load time greatly, however it might have some effect.
Having a simple place/update script, I can not think the performance overhead to do the statement could be really worth trying to perform a queue style system...
interesting questions! Like lots of other performance-tuning questions, you will find some tradeoffs.
Possibly. It might be a much better idea to load this handler in a IMG href="", setting the dimensions to so it's invisible towards the user.
With heavy load this is more suitable, this way your handler can return soon after queuing the operation. For many loads, however, it's most likely just like quick to operate an easy T-SQL query to increment a counter.
Adding +1 towards the value directly in your T-SQL query would most likely be the greatest, "count = count + 1" etc. That might be quick to operate and would lead to subsequent retrieval of the data without aggregation.
Hope this can help!
Creating a MQ only for monitoring pageviews/hits sounds just a little over complicated.