views:

351

answers:

4

I am developing a page view counter to track the amount of views a page is having on our site and displaying it to the user. (I asked an intro question before: http://stackoverflow.com/questions/246919/page-view-counter-like-on-stackoverflow).

Using the recommendations, I developed a httpHandler which will handle the request whenever this gets fired off:

<link rel="stylesheet" href="cn.axd?t=1&id=232" type="text/css" />
  1. Just wondering if the end-user would need to wait for the request to be finish processing before they can view/interact with the page.

  2. Would a better choice be implementing an asynchronous queue where information gets logged to an MS Queue and eventually logged in the database via (Exception Policy)

  3. Would it be slower to check if a certain record exist (PageID) and increment a counter or insert the record into the database and aggregate later when needed. We would just need to run an aggregation at the end of the week to see the total amount of pageviews a particular page got over the week.

Thanks all.

A: 

I would go with the logging method referenced in the other page, unless you need to track specific time/date of views. My reasoning is simply due to the sheer number of items that you might get as you application starts to scale up in size.

Linking to the handler as a CSS style, should not really stop load time very much, but it could have some effect.

With a simple insert/update script, I can't imagine that the performance overhead of doing the statement would be worth trying to do a queue style system...

Mitchel Sellers
A: 

Hi Tim, interesting questions! Like a lot of other performance-tuning questions, there are some tradeoffs.

  1. Possibly. It may be a better idea to load this handler inside an IMG href="", setting the sizes to 0 so it is invisible to the user.

  2. With heavy load this would be preferable, that way your handler can return immediately after queuing the operation. For most loads, however, it is probably just as quick to run a simple T-SQL query to increment a counter.

  3. Adding +1 to the value directly within your T-SQL query would probably be the best, "count = count + 1" etc. That would be quick to run and would result in subsequent retrieval of your data without aggregation.

Hope this helps!

Adam

Adam Alexander
Thanks Adam. Just wondering, for 1, why would SO use link (ie CSS) tag to handle their page counter?
TimLeung
There may very well be a good reason for it. Based on my experience using an IMG tag near the bottom of the page would ensure it does not hold up the page display, but it is certainly possible that someone who knows something I don't would have a better reason.
Adam Alexander
I would be interested in that explanation if you come across it.
Adam Alexander
A: 

Developing a MQ just for tracking pageviews/hits sounds a little over complicated.

If you are concerned about any perceived latency by the user, why not just fire off a XmlHttpRequest in JavaScript to your URL? That will be processed asynchronously.

matt b
Excellent point, probably something we will delegate later on when we scale up to fire the request via AJAX
TimLeung
+2  A: 

At my old company we also maintained a Page View counter and as the number of hits increased so did the database table which brought down the website to it's knees.

Whatever method you implement I recommend the following:

  1. Do inserts all the time (they are faster than updates).
  2. Do them asynchronous so it doesn't block the main thread and won't block future requests.
  3. Have a nightly process that sumarizes the data and clears the table in point 1.
  4. Do your selects against the summed up data.

We've found this was the most efficient and scalable solution, although you will not have real time data.

Jonas Stawski
If you can maintain the counter DB seperate from your main DB that would also help on scalability
Jonas Stawski