The impact of live stats on websites
Increasingly, websites want to bring you up-to-the-minute details of what is happening on the site, or in related fields depending on what industry you’re in. Whilst this is a nice feature, it’s important to take a step back during development and understand how ‘live’ data can impact on the productivity and profitability of you site.
A lot of ‘off-the-shelf’ packages will take care of this for you, and your friend is scheduling tasks. This takes processing power away from having to do a task on-the-fly when you request something (and there might be a great deal of people requesting it!) – and means that the server is only under load at specific times, manageable by you – or your developer at least!
The problem of using live stats…
We came across this problem recently whilst re-writing our Twitition site, and there were a couple of places where we wanted to use stats which were right up-to-the-minute. For example, we wanted the “most popular Twtition” to be as up-to-date as possible, but the server was just too under load when this was a live calculation.
In theory, every time a page was being loaded, the server would have to go and count all the signatures for all Twititions and find the most popular. That’s before it could even sort any rendering out to show you some progress. This issue can be tackled in many ways; stored procedures, view stats on the database, or, for us, quite simply the realisation that that data didn’t need to be up-to-the-minute.
How to solve it…
Simply put, we set up a scheduled task (cron job) that figured all this out, and wrote it out to the database. This means that on every page load, all the site has to do is ask the database for the current top Twitition. It doesn’t have to sort anything or add anything up; all it has to do is return one piece of information, and then continue processing the page.
Using live stats on e-commerce sites…
We’ve also recently seen live stats become an issue in an e-commerce setting. A site we were working on for a client had become increasingly slow on product pages. We figured out that the previous development company had coded the system so that the “customers who bought this, also bought this” system actually went and calculated this each and every time the page was loaded.
So when a customer landed on a product page, the code would search through all the previous orders for that product and compile a list of all products that had been bought at the same time as that product. It would then order the list and present you with the top 3. When the system was originally developed, it was obviously quick, and meant that the data was automated, and based on fact.
However, as the website gained more and more orders, the system became slower and slower. The site’s own success was leading to its downfall. The answer here was to take off the system in the short term, and then recode it into a scheduled task that runs every day to provide a more usable and reactive website.
Deciding on live stats for your site…
Deciding on this all comes down to the planning phase. What might seem like a good idea now, might not be a good idea if the website takes off and becomes the success you hope it does. ‘Live’ can be relative on the web; you can have a script that updates items once a minute and it will lead to a more responsive website than if it was on-the-fly if you have a popular site. Remembering that you might have 10,000 visits in that 1 minute.
Whilst the need for ‘instant’ information on the web is growing, it’s essential not to forget about usability, and how real time features can affect your user’s experience.
Latest from B3Labs
- Another milestone reached for Branded3 as it’s acquired by the
St Ives Group
- The latest media consumer findings & what they mean for digital marketers
- Talk to Branded3 at @BuyYorkshire in Leeds next week!
Latest from Blogstorm
- Early thoughts on Penguin 2.0
- 5 myths about manual penalty recovery
- Google gets more aggressive with link devaluation