Fast = $$$ How do you make sure to have a fast application?

Speed = $$$
Many articles on the web, books and statistics tell us that “faster = better” and even more important: faster = more revenue.

For Google an increase in page load time from 0.4 second to 0.9 seconds decreased traffic and ad revenues by 20%.
For Amazon every 100 ms increase in load times decreased sales with 1%.


Also Google uses site speed in their web search ranking. So make sure to optimize your website for speed as per my other blog post.

Is Web Performance Optimization (WPO) something for you?

For one of my clients performance is critical. They need instant feedback (“real time!?”) in their application in order to run a smooth system. Otherwise their end users wouldn’t trust the system and not use it…

The system is a nifty application where people (with Silverlight) connect to a server (a WCF service) and we push out updates a couple of times per second. Yep, that’s in the 100ms range..

To reach a high level of performance we did a lot of performance tuning, including all my tips from optimize your website for speed as per my other blog post. More in general we try to reduce the numbers of database access and we keep everything in memory as much as possible. Did I mention caching?


Developers like to change things

We are continuously working on that project. We implement new features, we fix bugs we improve certain bits, or at least we think we improve them Smile


How can we make sure that code changes don’t introduce a performance problem?

We need a “performance test”, or a “stresstest” or a “load test”.
Something that tests the performance our application.

My view of the difference between “Loadtest” and “Stresstest” can be found in my interview with loadstorm.

The problem with this “performance tests” is, that they usually take a bit of time to run. So running them on every check-in might not make sense.
So we decided to run them once a day, preferably during the night where we are not bothered with high server temperature because of CPU overload or a slow network because of network overload.


What is the final goal?

Get a thumbs up from our stresstest environment before releasing the latest to the wild!

The goal is to get a confirmation that we didn’t introduce a performance problem with our changes that we made during the day.
Every morning we get a report via email from SQL Server Reporting Services. This report shows us all important performance statistics about our system.

These are 2 reports from different days:

Good This is a good normal run (Click to enlarge)

Figure: Stresstest overview
Figure: System wide Statistics
Figure: Top 10 Process Statistics


Bad This is a  bad one

Figure: Drop of all connected users at 3:07AM with the consequence of CPU spiking


We have seen how important performance is and what the final goal is.
Next up:
How to setup this stresstest environment and this stresstest report.  Topic of my next blog post.
Stay tuned!

BTW: Little info before hand
This report is done with:

  • VMWare
    • 1 virtual machine for the stresstest server
    • More virtual machines that act as clients
  • TFS & msdeploy
    • Deploy latest version to stresstest environment
  • Perfmon
    • Scheduled Perfmon from 3AM-5AM on the server
    • Logs everything to a database
  • SQL Server Reporting Services
    • Collects data
    • Generate a report on top of those numbers

Do you have automated performance tests? Send me a tweet!

No comments:

Post a Comment

Latest Posts

Popular Posts