Over a million developers have joined DZone.

Micro Benchmarking Your ASP.Net Pages Using Apache Bench

·
In ASP.net land we are often lead to think the “Microsoft way” when it comes to a lot of things. Running performance tests and benchmarking is one of these tasks where we are often found looking into commercial tooling or products to help us find out how our applications handle load. Meanwhile a lot of web developers on other stacks are doing it with great free tooling. There is nothing stopping us from stealing the best parts from these stacks and bringing them back to the land of ASP.Net.

 

Image: Martin Heigan

Tooling tooling everywhere…

If you’re developing ASP.Net websites and web services you’ve probably turned to a few different options to performance test your pages and web services.

You may be lucky and happen to own a copy of Visual Studio Ultimate and have had a play with the Performance and Stress testing tooling that comes along with it.

In the non-microsoft tooling world I’ve used a few tools such as Load UI and Soap UI for a number of projects successfully. There are many many commercial products that do similar jobs.

But a lot of these tools sometimes actually don’t make it  really clear how to get answers to some simple questions that both we and our clients often want to know.

Simple questions like:

“How many users can my application take at once?”

Or other gems that you might like to know;

“How long does my page take to execute? How long does it take when 100 visitors are using it at the same time?”


Info for nothing, and the tests for free…

When you install Apache you get a whole heap of tools along with it. We normally think of Apache as a Linux/Unix web server, but there is a windows version that contains all the same power.

One of the included tools that comes with Apache is the performance testing tool Apache Bench.

Apache Bench is a really powerful and simple command line tool for performance testing and gathering metrics on how your application pages respond under load. It does this with very little CPU usage and a very small memory footprint, allowing you to run it on hardware that has lower spec than a lot of the commercial tools around. This makes it great if you want to use old machines on your network to run testing concurrently form different network addresses.

Apache Bench allows you to simulate a defined number of requests at a time for a set amount of total requests and view results on how your pages respond.

This allows us to do the following:

  • Test a page with 10 users at a time for 1,000 requests
  • Test a page with 50 users at a time for 10,000 requests
  • Test a page with 100 users at a time for 100,000 requests
  • etc.
  • etc.


Do the above for 1 minutes, 5 minutes…

And get response times; failure rates; requests a second; transfer rates for each level of user load.

Actually get data that can help you estimate how your application will function once it goes live.

For Free.

WARNING
This is not a “this is how you should perform tests on your website to become invincible”. There are plenty of blog posts and articles out there to get you strategies an approaches on how to do this. This post is however a guide to doing basic micro-benchmarking on individual pages during development to test performance in ways that you won’t be able to do on your dev machine without other software.

Performance testing and website load generators such as Apache Bench can be dangerous things in shared hosting environments and without your webhosts knowledge, so please take precautions before testing on other peoples sites or hardware.


Performance testing - Thinking it through

As web applications use networking bandwidth, you need to take this into account when deciding how you are going to be doing your testing.

Are you testing just your application? or are you testing your application and your server’s internet bandwidth? (and your test machine’s bandwidth…)

If you want to know how your application responds independent of the internet, you should test from a machine that is on the same internal network as your webserver to ensure that your internet pipe is not the bottleneck in testing. This will give you upper bounds on your application, but will not give you the full picture for launch day.

If you want to also test the internet link that your server is serving through (i.e. the real-world), run your tests from machines outside your server’s internal network – somewhere on the internet.

Maybe an Amazon EC2 Instance? (If so use the Linux Apache Binaries – Linux instances of EC2 are cheaper…)

I do suggest you do this with your ISP’s knowledge and only when you are running dedicated servers – otherwise you may become a willing participant in a DOS attack against your web host, and also take the other sites on your box down at the same time from the performance hit.

Making it all happen

Download the XAMPP zip file.

In the bin folder of the zip file extract the file ab.exe into a location on the machine you will be running your tests from so that you can easily get to it.

For the point of this demo I've placed mine in “C:\testing\”.

On the machine you will be testing from open a command prompt window and move into the above created directory (enter “cd C:\testing\”).

Now we will start by issuing 1,000 requests from 5 concurrent clients at the same time.

The –n is the number of requests to process (we want this to be a high enough number that the tests run for a minimum amount of time (a minute or 30 seconds should give you an idea on numbers)

The –c is the amount of concurrent requests to run. This is the equivalent of a number of people hitting your site at the same time.

Topics:

Published at DZone with permission of Douglas Rathbone, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}