For this weeks newsletter we tackle a topic pretty close to our hearts here at Awecomm. Application Stress Testing. We have been performing this service for a while now and feel it is an important component of any application deployment. For more reasons why businesses should seriously consider this check out Brent’s post here.

This week I’ll highlight ten very important stress testing components, and describe why they are important.  If you are serious about determining the scalability and performance of your online application check out my list below.

Basically our stress tests are a combination of tests used to gauge the performance of the server and to determine how much load it can sustain before degradation takes place. For example, in one test, our developers built a automated user script that duplicated the login process, application usage, and logout process of a web application. We then ran 2000 simultaneous connections to it for 1 hour and collected as much information as we could. With that, we can determine what type of load the infrastructure
can sustaine.

1. CPU Usage.  A cpu that is continually running at a very high percentage during the test may indicate an application issue whether it’s poorly tuned or designed. This could be lowered once the application has been optimized. If cpu usage has scored high it could also mean that a hardware upgrade is imminent. You can use the Processor:% Processor Time counter in System Monitor to determine this.  Below is a sample screenshot.

2. Disk Usage.  If your physicaldisk: % disk time counter is very high we can then check the current disk queue length counter.  With this we can determine whether what step to take next.  Do we need to upgrade to faster drives?  We can also check #3 below.

3.  Memory.  One thing we can check is the Memory Page Faults/sec counter.  We can then determine whether the disk activity is caused by paging which could mean that the memory usage could be high due to processes using too much memory.
There’s another counter that can determine memory usage that will also reflect the usage that correlates with the possible disk time counters being high.  View a sample screenshot below.

Monitoring SQL

4. SQL Memory.  You need to check how your database server is performing.  We can use the same counters above with some of these sql counters to determine this.  The sqlserver memory manager counter will show the total memory in use by SQL.

5. SQL Connections. We can find out the number of users connected to the sql server using the sqlserver:general statistics\user connections counter.

6. SQL Latches.  SQL uses these to protect actions that don’t need to be locked for the life of a transaction.  When the engine is scanning a page it latches it, reads it and gives it back to the relational engine and then unlatches the page so that it can be used again.  You can monitor the average latch wait time by using the sql server:latches\average latch wait time counter.  If the number of these is high, there could be a resource limitation.

Monitoring IIS

7.  Current Web Connections.  Finding the current IIS web connections is important to understand how this might be related to cpu, and memory usage.  View a sample screenshot below.

8. Not found Errors.  This show’s the number of requests that were reported as HTTP error 404. 

9. ASP Pages Performance. During the testing we can find if there are Errors and how many there are.  ASP Requests whether we find how many have failed or how many requests are timed out could shed light on application or resource issues.

10. ASP.NET Performance. When looking at worker processes and how many are running or how many restarts it’s getting could throw a red flag in which could lead to some investigation.  We can also look at either a single instance or a total for all applications running on the server.

Valuable information can be found after running a load test.  Although this can get quite technical, the data that is gathered is critical to determine where your application, database, or web server stands.   

Resources

Microsoft Performance Baseline
http://technet2.microsoft.com/windowsserver/en/library/9277f422-eb8c-4c14-89b5-9fe09f80fd191033.mspx?mfr=true

SQL Latching
http://msdn2.microsoft.com/en-us/library/Aa224727(SQL.80).aspx 

System Monitor IIS6
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3ffd9ede-2bc8-4bdc-871e-9d937f25d6c9.mspx?mfr=true

Filed under: Technical Articles on August 17th, 2007 | No Comments »

For a while now we have been performing application stress testing for our customers. We basically setup our drone machines and network to throw a bunch of traffic towards an online application, use our customized scripts to simulate users, and tediously measure the results. From there we can produce reports projecting application performance over varying loads and situations. So why is this an important thing for businesses to evaluate… Read on!

Why you need it.

Stress testing can provide invaluable insight into the scalability and performance of your application. It gives you the ability to anticipate load times witnessed by your users, gives you the ability to forecast problems, helps identify application and hardware limitations, allows you to properly plan and deploy infrastructure, and in most cases can locate areas in which your applications can be optimized for better performance. What does this mean.. well simply put, a proper stress test can help you avoid downtime when your web site or application is needed the absolute most, during heavy usage. I have experienced far to many sites going down or slowing to a crawl when they get too much traffic, not only is the web site losing my interest, but they are probably loosing my business too. This is unacceptable today given the fact that most time it can be easily avoided.

What is stress testing?

Basically stress testing an application is generating a pre-defined amount of traffic to accomplish a pre-defined set of tasks on an application, then collecting data and interpreting the results. The amount of traffic and which actions are performed depend on what you are testing but usually simulates normal user activity factoring for anticipated growth. Anything from visiting multiple web pages within a site, to engaging in actual application usage like logging in, purchasing items, taking tests, running reports, filling out forms, etc.. During the testing process very specific measurements are recorded and this data is used to produce specific reports on the performance and limitations of your web application.

What should the reports show?

Another common question is what information should your test reveal. Well of course like everything else that depends. At a minimum I would suggest at least getting a good idea of how many simultaneous users your application can handle with the current infrastructure. That will give you a loose idea of when to anticipate issues based on too many users and potentially avoid them. I would also check for hardware bottlenecks, or potential software issues. Our own Jesse Woodruff does a good job describing them technically in his post here. Ultimately you’re looking for enough information to build a roadmap for growing your application based on actual usage. You should know how many users your web application can handle, what is the longest acceptable load time you can deliver to those users, when you need to scale your infrastructure, what components of the infrastructure you will need to scale first, and potentially what modifications can be made to your application to utilize less resources and therefore extend the life of your current infrastructure. Having this information readily available will not only help you save money by planning correctly for your application, but can also help you avoid unacceptable downtime that would loose business.

Filed under: Business Articles on August 17th, 2007 | No Comments »

I found this great little tool called BlogDesk the other day. It helps to create content and publish to a blog site with a much friendlier and easier to use interface than most blog publishing components I have used. The best part is you can have a number of blogs setup within the software and publish to whichever one you want whenever you want.

The annoying part… Well of course because of a Microsoft patch the components needed on your machine to run this little Gem are no longer available.. Well I did some digging and found the link on the Microsoft site to fix this little mix up and get you blogging again!

If you run the BlogDesk install and get an error anytime you run it mentioning it can’t find the dhtmled.ocx file you most likely need to download and run the component install below. Good Luck !

http://www.microsoft.com/downloads/details.aspx?familyid=b769a4b8-48ed-41a1-8095-5a086d1937cb&displaylang=en

Filed under: Uncategorized on August 9th, 2007 | No Comments »