A few months ago on a project the subject of load testing came up. We were having some serious issues with a
Web application that would start spewing SQL lock errors under somewhat heavy load. These sort of errors can be tough
to catch, precisely because they only occur under load and not during typical development testing.
To replicate this error more reliably we needed
to put a load on the application and run it for a while before these SQL errors would flare up. It’s been a while since I’d looked at load testing tools, so I spent a bit of time looking at different tools and frankly didn’t really find anything that was a good fit. A lot of tools were either a pain
to use, didn’t have the basic features I needed, or are extravagantly expensive. In the end I got frustrated enough
to build an initially small custom load test solution that then morphed into a more generic library, then gained a console front end and eventually turned into a full blown
Web load testing tool that is now called West Wind WebSurge. I got seriously frustrated looking for tools every time I needed some quick and dirty load testing for an application. If my aim is
to just put an application under heavy enough load
to find a scalability problem
in code, or
to simply try and push an application
to its limits on the hardware it’s running I shouldn’t have
to have
to struggle
to set up tests. It should be easy enough
to get going
in a few minutes, so that the testing can be set up quickly so that it can be done on a regular basis without a lot of hassle. And that was the goal when I started
to build out my initial custom load tester into a more widely usable tool. If you’re
in a hurry and you want
to check it out, you can find more information and download links here: West Wind WebSurge Product Page Walk through Video Download link (zip) Install from Chocolatey Source on GitHub For a more detailed discussion of the why’s and how’s and some background continue reading.
How did I
get here? When I started out on this path, I wasn’t planning on building a tool like this myself – but I got frustrated enough looking at what’s out there
to think that I can do better than what’s available for the most common simple load testing scenarios. When we ran into the SQL lock problems I mentioned, I started looking around what’s available for
Web load testing solutions that would work for our whole team which consisted of a few developers and a couple of IT guys both of which needed
to be able
to run the tests. It had been a while since I looked at tools and I figured that by now there should be some good solutions out there, but as it turns out I didn’t really find anything that fit our relatively simple needs without costing an arm and a leg… I spent the better part of a day installing and trying various load testing tools and
to be frank most of them were either terrible at what they do, incredibly unfriendly
to use, used some terminology I couldn’t even parse, or were extremely expensive (and I mean
in the ‘sell your liver’ range of expensive). Pick your poison. There are also a number of online solutions for load testing and they actually looked more promising, but those wouldn’t work well for our scenario as the application is running inside of a private VPN with no outside access into the VPN. Most of those online solutions also ended up being very pricey as well – presumably because of the bandwidth required
to test over the open
Web can be enormous. When I asked around on Twitter what people were using– I got mostly… crickets. Several people mentioned Visual Studio Load Test, and most other suggestions pointed
to online solutions. I did
get a bunch of responses though with people asking
to let them know what I found – apparently I’m not alone when it comes
to finding load testing tools that are effective and easy
to use. As
to Visual Studio, the higher end skus of Visual Studio and the test edition include a
Web load testing tool, which is quite powerful, but there are a number of issues with that: First it’s tied
to Visual Studio so it’s not very portable – you need a VS install. I also find the test setup and terminology used by the VS test runner extremely confusing. Heck, it’s complicated enough that there’s even a Pluralsight course on using the Visual Studio
Web test from Steve Smith. And of course you need
to have one of the high end Visual Studio Skus, and those are mucho Dinero ($$$) – just for the load testing that’s rarely an option. Some of the tools are ultra extensive and let you run analysis tools on the target serves which is useful, but
in most cases – just plain overkill and only distracts from what I tend
to be ultimately interested in: Reproducing problems that occur at high load, and finding the upper limits and ‘what if’ scenarios as load is ramped up increasingly against a
site. Yes it’s useful
to have
Web app instrumentation, but often that’s not what you’re interested
in. I still fondly remember early days of
Web testing when Microsoft had the WAST (Web Application Stress Tool) tool, which was rather simple – and also somewhat limited – but easily allowed you
to create stress tests very quickly. It had some serious limitations (mainly that it didn’t work with SSL), but the idea behind it was excellent: Create tests quickly and easily and provide a decent engine
to run it locally with minimal setup. You could
get set up and run tests within a few minutes. Unfortunately, that tool died a quiet death as so many of Microsoft’s tools that probably were built by an intern and then abandoned, even though there was a lot of potential and it was actually fairly widely used. Eventually the tools was no longer downloadable and now it simply doesn’t work anymore on higher end hardware. West Wind
Web Surge – Making Load Testing Quick and Easy So I ended up creating West Wind WebSurge out of rebellious frustration… The goal of WebSurge is
to make it drop dead simple
to create load tests. It’s super easy
to capture sessions either using the built
in capture tool (big props
to Eric Lawrence, Telerik and FiddlerCore which made that piece a snap), using the full version of Fiddler and exporting sessions, or by manually or programmatically creating text files based on plain HTTP headers
to create requests. I’ve been using this tool for 4 months now on a regular basis on various projects as a reality check for performance and scalability and it’s worked extremely well for finding small performance issues. I also use it regularly as a simple URL tester, as it allows me
to quickly enter a URL plus headers and content and test that URL and its results along with the ability
to easily save one or more of those URLs. A few weeks back I made a walk through video that goes over most of the features of WebSurge
in some detail: Note that the UI has slightly changed since then, so there are some UI improvements. Most notably the test results screen has been updated recently
to a different layout and
to provide more information about each URL
in a session at a glance. The video and the main WebSurge
site has a lot of info of basic operations. For the rest of this post I’ll talk about a few deeper aspects that may be of interest while also giving a glance at
how WebSurge works. Session Capturing As you would expect, WebSurge works with Sessions of Urls that are played back under load. Here’s what the main Session View looks like: You can create session entries manually by individually adding URLs
to test (on the Request tab on the right) and saving them, or you can capture output from
Web Browsers, Windows Desktop applications that call services, your own applications using the built
in Capture tool. With this tool you can capture anything HTTP -SSL requests and content from
Web pages, AJAX calls, SOAP or REST services – again anything that uses Windows or .
NET HTTP APIs. Behind the scenes the capture tool uses FiddlerCore so basically anything you can capture with Fiddler you can also capture with
Web Surge Session capture tool. Alternately you can actually use Fiddler as well, and then export the captured Fiddler trace
to a file, which can then be imported into WebSurge. This is a nice way
to let somebody capture session without having
to actually install WebSurge or for your customers
to provide an exact playback scenario for a given set of URLs that cause a problem perhaps. Note that not all applications work with Fiddler’s proxy unless you configure a proxy. For example, .
NET Web applications that make HTTP calls usually don’t show up
in Fiddler by default. For those .
NET applications you can explicitly override proxy settings
to capture those requests
to service calls. The capture tool also has handy optional filters that allow you
to filter by domain,
to help block out noise that you typically don’t want
to include
in your requests. For example, if your pages include links
to CDNs, or Google Analytics or social links you typically don’t want
to include those
in your load test, so by capturing just from a specific domain you are guaranteed content from only that one domain. Additionally you can provide url filters
in the configuration file – filters allow
to provide filter strings that if contained
in a url will cause requests
to be ignored. Again this is useful if you don’t filter by domain but you want
to filter out things like static
image, css and script files etc. Often you’re not interested
in the load characteristics of these static and usually cached resources as they just add noise
to tests and often skew the overall url performance results.
In my testing I tend
to care only about my dynamic requests. SSL Captures require Fiddler Note, that
in order
to capture SSL requests you’ll have
to install the Fiddler’s SSL certificate. The easiest way
to do this is
to install Fiddler and use its SSL configuration options
to get the certificate into the local certificate store. There’s a document on the Telerik
site that provides the exact steps
to get SSL captures
to work with Fiddler and therefore with WebSurge. Session Storage A group of URLs entered or captured make up a Session. Sessions can be saved and restored easily as they use a very simple text format that simply stored on disk. The format is slightly customized HTTP header traces separated by a separator line. The headers are standard HTTP headers except that the full URL instead of just the domain relative path is stored as part of the 1st HTTP header line for easier parsing. Because it’s just text and uses the same format that Fiddler uses for exports, it’s super easy
to create Sessions by hand manually or under program control writing out
to a simple text file. You can see what this format looks like
in the Capture window figure above – the raw captured format is also what’s stored
to disk and what WebSurge parses from. The only ‘custom’ part of these headers is that 1st line contains the full URL instead of the domain relative path and Host: header. The rest of each header are just plain standard HTTP headers with each individual URL isolated by a separator line. The format used here also uses what Fiddler produces for exports, so it’s easy
to exchange or view data either
in Fiddler or WebSurge. Urls can also be edited interactively so you can modify the headers easily as well: Again – it’s just plain HTTP headers so anything you can do with HTTP can be added here. Use it for single URL Testing Incidentally I’ve also found this form as an excellent way
to test and replay individual URLs for simple non-load testing purposes. Because you can capture a single or many URLs and store them on disk, this also provides a nice HTTP playground where you can record URLs with their headers, and fire them one at a time or as a session and see results immediately. It’s actually an easy way for REST presentations and I find the simple UI flow actually easier than using Fiddler natively. Finally you can save one or more URLs as a session for later retrieval. I’m using this more and more for simple URL checks. Overriding Cookies and Domains Speaking of HTTP headers – you can also overwrite cookies used as part of the options. One thing that happens with modern
Web applications is that you have session cookies
in use for authorization. These cookies tend
to expire at some point which would invalidate a test. Using the Options dialog you can actually override the cookie: which replaces the cookie for all requests with the cookie value specified here. You can capture a valid cookie from a manual HTTP request
in your browser and then paste into the cookie field,
to replace the existing Cookie with the new one that is now valid. Likewise you can easily replace the domain so if you captured urls on west-wind.com and now you want
to test on localhost you can do that easily easily as well. You could even do something like capture on store.west-wind.com and then test on localhost/store which would also work. Running Load Tests Once you’ve created a Session you can specify the length of the test
in seconds, and specify the number of simultaneous threads
to run each session on. Sessions run through each of the URLs
in the session sequentially by default. One option
in the options list above is that you can also randomize the URLs so each thread runs requests
in a different order. This avoids bunching up URLs initially when tests start as all threads run the same requests simultaneously which can sometimes skew the results of the first few minutes of a test. While sessions run some progress information is displayed: By default there’s a live view of requests displayed
in a Console-like window. On the bottom of the window there’s a running total summary that displays where you’re at
in the test,
how many requests have been processed and what the requests per second count is currently for all requests. Note that for tests that run over a thousand requests a second it’s a good idea
to turn off the console display. While the console display is nice
to see that something is happening and also gives you slight idea what’s happening with actual requests, once a lot of requests are processed, this UI updating actually adds a lot of CPU overhead
to the application which may cause the actual load generated
to be reduced. If you are running a 1000 requests a second there’s not much
to see anyway as requests roll by way too fast
to see individual lines anyway. If you look on the options panel, there is a NoProgressEvents option that disables the console display. Note that the summary display is still updated approximately once a second so you can always tell that the test is still running. Test Results When the test is done you
get a simple Results display: On the right you
get an overall summary as well as breakdown by each URL
in the session. Both success and failures are highlighted so it’s easy
to see what’s breaking
in your load test. The report can be printed or you can also open the HTML document
in your default
Web Browser for printing
to PDF or saving the HTML document
to disk. The list on the right shows you a partial list of the URLs that were fired so you can look
in detail at the request and response data. The list can be filtered by success and failure requests. Each list is partial only (at the moment) and limited
to a max of 1000 items
in order
to render reasonably quickly. Each item
in the list can be clicked
to see the full request and response data: This particularly useful for errors so you can quickly see and copy what request data was used and
in the case of a
GET request you can also just click the link
to quickly jump
to the page. For non-GET requests you can find the URL
in the Session list, and use the context menu
to Test the URL as configured including any HTTP content data
to send. You
get to see the full HTTP request and response as well as a link
in the Request header
to go visit the actual page. Not so useful for a POST as above, but definitely useful for
GET requests. Finally you can also
get a few charts. The most useful one is probably the Request per Second chart which can be accessed from the Charts menu or shortcut. Here’s what it looks like: Results can also be exported
to JSON, XML and HTML. Keep
in mind that these files can
get very large rather quickly though, so exports can end up taking a while
to complete. Command Line Interface WebSurge runs with a small core load engine and this engine is plugged into the front end application I’ve shown so far. There’s also a command line interface available
to run WebSurge from the Windows command prompt. Using the command line you can run tests for either an individual URL (similar
to AB.exe for example) or a full Session file. By default when it runs WebSurgeCli shows progress every second showing total request count, failures and the requests per second for the entire test. A silent option can turn off this progress display and display only the results. The command line interface can be useful for build integration which allows checking for failures perhaps or hitting a specific requests per second count etc. It’s also nice
to use this as quick and dirty URL test facility similar
to the way you’d use Apache Bench (ab.exe). Unlike ab.exe though, WebSurgeCli supports SSL and makes it much easier
to create multi-URL tests using either manual editing or the WebSurge UI. Current Status Currently West Wind WebSurge is still
in Beta status. I’m still adding small new features and tweaking the UI
in an attempt
to make it as easy and self-explanatory as possible
to run. Documentation for the UI and specialty features is also still a work
in progress. I plan on open-sourcing this product, but it won’t be free. There’s a free version available that provides a limited number of threads and request URLs
to run. A relatively low cost license removes the thread and request limitations. Pricing info can be found on the
Web site – there’s an introductory price which is $99 at the moment which I think is reasonable compared
to most other for pay solutions out there that are exorbitant by comparison… The reason code is not available yet is – well, the UI portion of the app is a bit embarrassing
in its current monolithic state. The UI started as a very simple interface originally that later got a lot more complex – yeah, that never happens, right? Unless there’s a lot of interest I don’t foresee re-writing the UI entirely (which would be ideal), but
in the meantime at least some cleanup is required before I dare
to publish it :-). The code will likely be released with version 1.0. I’m very interested
in feedback. Do you think this could be useful
to you and provide value over other tools you may or may not have used before? I hope so – it already has provided a ton of value for me and the work I do that made the development worthwhile at this point. You can leave a comment below, or for more extensive discussions you can post a message on the West Wind Message Board
in the WebSurge section Microsoft MVPs and Insiders
get a free License If you’re a Microsoft MVP or a Microsoft Insider you can
get a full license for free. Send me a link
to your current, official Microsoft profile and I’ll send you a not-for resale license. Send any messages
to [email protected]. Resources For more info on WebSurge and
to download it
to try it out, use the following links. West Wind WebSurge Home Download West Wind WebSurge Getting Started with West Wind WebSurge Video© Rick Strahl, West Wind Technologies, 2005-2014Posted
in ASP.NET
Tweet
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
