Byte conversion
There are a million little applets and forms out there to do byte conversions, but for whatever reason this is the one I have bookmarked. I'm sure full time performance testers can do this stuff in their head, but us part-timers need help every now and then. Perhaps I like it because it's a simple clean interface, and it shows me the conversion rates:
1 Byte = 8 Bit
1 Kilobyte = 1024 Bytes
1 Megabyte = 1048576 Bytes
1 Gigabyte = 1073741824 Bytes
Do you have one you prefer? Or perhaps another similar simple tool you use when testing?
Manual calibration
Many times when performance testing, I'll manually calibrate my performance test script by loading the page manually and comparing those load times with those generated from my test tool. Doing this with a load of one user allows me to get an idea of how much my tool is skewing the numbers. Often, I find the tool is just a tad bit worse in terms of response times. If it's too far off, that normally tells me something is wrong.
Perfmon Counters
Today's tip comes from Senthilnathan over at Testing-Virtuoso. Senthilnathan provides a very succinct set of tips for network performance testing. From that post, some tips for performance counters in Perfmon:
Network Interface\Bytes Received/Sec
Network Interface\Bytes Sent/sec
Network Interface\Bytes Total/sec
Network Interface\Current Bandwidth
Network Interface\Output Queue LengthIf the Network Interface\Bytes Total/sec is more than 50 percent of the total network utilization, then your server is having some problems under peak load conditions.
Correlate the network counter values with Physical Disk\% Disk Time and Processor\% Processor Time utilization. If the Disk\% disk time and %processor time values are low and the network queues are high then there might be a problem with your network card/ bandwidth.
I love seeing what counters performance testers look at. If you have some different counters you use when testing, feel free to share.
PAL
PAL, which stands for Performance Analysis of Logs, is a free tool for pulling apart Microsoft log files (IIS, MOSS, SQL Server, BizTalk, Exchange, Active Directory) and analyzing them. The tool generates HTML reports based on recommended performance counters and shows when thresholds for those counters have been exceeded. You can also setup your own custom thresholds in the tool.
Fiddler
Fiddler is a Proxy which logs HTTP/HTTPS traffic. You can set breakpoints, change data, and perform event-based scripting. Fiddler is freeware and works with just about any browser.
LiveHTTPHeaders
LiveHTTPHeaders 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
Sometimes 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."
