Posts in Performance Testing
LiveHTTPHeaders
livehttpheadersLiveHTTPHeaders is a Firefox plugin for viewing and manipulating HTTP headers. From the site:
The goal of this project is to adds information about the HTTP headers in two ways:

  • First by adding a 'Headers' tab in 'View Page Info' of a web page.

  • Second by adding a tool in the 'Tools->Web Development' menu to be able to display http headers in real time (while pages are being downloaded from the Internet.

  • Third by letting you edit request headers and replay an URL (beta). Look for the Replay button in the live window!


This project may be of some help for the following:

  • Help debugging web application.

  • See which kind of web server the remote site is using.

  • See the cookies sent by remote site.




I've found it to be handy when creating performance test scripts or when trying to debug a script.
JMeter
If you do performance testing on a regular basis, and you've not used JMeter yet, you need to give it a try. It's free, open source, and very lightweight. I find it's well suited to many of the day-to-day performance test projects, and because it's lightweight I can make new tests and changes to tests quickly.

From the website:
Apache JMeter is open source software, a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.

Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.
Create multiple versions of your UCML load model
When I'm creating initial load models for an application, I find that I create multiple versions of UCML. The first draft is often quite large. It often has several branches per user. If I were to create it, I might have 25 to 75 scenarios. I use this first model as a discussion tool. What I'm interested in here is if I've accurately captured what users and and can't do, and roughly how often they do it.

Then, once I feel I've got that well understood, I create a consolidated model that I'll actually use to create and calibrate test scripts for. Where I might have previously had 50 of scenarios, here I'm going down to 10 (or even under 10 if I feel I can do that without affecting the validity of the testing). I'm looking for the simplest combination of scripts/scenarios that will give me the load profile I'm looking for.

The reason I take this approach is because I've never been on a project where I've had the time or resources to create all the scenarios. And even if I did, it would likely be a waste. But later in the project, when we find an issue and someone asks why I'm running my simplified load model (which will only look loosely like the original), I'll have something that shows what we started with and how that maps to what we're currently running. It reduces confusion around why we're running the model we're running.
Gathering data and stats for performance testing
alexaSometimes when performance testing you need to do some research into other websites so you can make predictions on how people will use yours. This can be a time consuming. You need to think of sites that will have similar users with similar usage patterns. They need to be roughly the same size and scope for the data to be transferable. It's not easy.

Once you've thought of some sites, you then need to get stats. There are a lot of ways and places to get those stats. Some of them reputable, some of them not. One place I turn to for some basic stats is Alexa. They seem to have good data, it's a very easy site to use, and I always find out a bit more than I was looking for.
Grinder
From the Grinder tool website:
"The Grinder is a Java load testing framework that makes it easy to run a distributed test using many load injector machines. [...] Load test anything that has a Java API. This includes common cases such as HTTP web servers, SOAP and REST web services, and application servers (CORBA, RMI, JMS, EJBs), as well as custom protocols. [...] Tests are written in the powerful Jython scripting language. [...] A graphical console allows multiple load injectors to be monitored and controlled, and provides centralised script editing and distribution. [...] Automatic management of client connections and cookies. SSL. Proxy aware. Connection throttling. Sophisticated record and replay of the interaction between a browser and a web site."