A common problem in JMeter is that you want a CSV file as an input and want to execute each line, then continue. So from a script perspective that would look something like this:
|-For Each CSV Line
| |-HTTP Request (CSV input)
|-Do something else
The issue though is there is no “For Each” concept in JMeter. I know that it is called a ForEach Loop in JMeter but it isn’t from a developer view. You need to know the length of your CSV file. You could just tell the For loop how many lines there are but that would make it very unflexible. You’d need to adjust the script every time the CSV changes.
So here is how I solved it. Not elegant but it actually works quite well.
Sorry for the ongoing spam about JMeter stuff but I am writing a LOT of coding at the moment and I thought I’d share some of the knarly stuff I come accross so others might benefit.
So I had the issue that I need to cobble together MIME HTTP/SOAP calls that contain attachments. JMeter has the ability to add files statically to an HTTP Request (Body Data) but if you need more control you need to roll your own. Best way to do this would be to load the file into a variable and just attach like this:
Content-Disposition: attachment; name="MyFile.pdf"
But how do you get it into the variable?
Some projects require authentication features that involve some quite intricate steps. But fret not, in JMeter we can use Groovy to do the heavy lifting. Below is a very simple example of how you can do a HMAC encryption. It also includes the SHA256 hashing and base64 encoding. The only thing missing are the functions to read the variables from JMeter and publish the hash to JMeter but that is trivial and you can fit it into whatever you already have scripted.
String secretKey = "secret";
String data = "Message";
Mac mac = Mac.getInstance("HmacSHA256");
SecretKeySpec secretKeySpec = new SecretKeySpec(secretKey.getBytes(), "HmacSHA256");
byte digest = mac.doFinal(data.getBytes());
encodedData = digest.encodeBase64().toString();
log.info("HMAC SHA256 base64: " + encodedData);
by Oliver Erlewein
Threading and keepalives in HTTP are always an issue in performance testing and testing tools. When does a keepalive session start and how many are started is a thing of mystery. So having a bit of clarity helps. On my current project I wanted to prove what thread connects to what server for how long.
Continuing on from David’s post here http://martialtester.wordpress.com/2013/11/22/buying-tickets-is-hard/, another thing just happened. With Microsoft’s release of the Xbox they seem to have misjudged their customers and how eager they are to give $$$$.
So if you hit http://xbox.com right now you will get the following:
Testers (and especially Stakeholders!!) out there, always think about your go live load and what can happen and how you want to mitigate it. Early Performance Testing is a good solution but even just having a good think about it can save you a lot of trouble. And if you think you’re not susceptible, then look at the above! Even Microsoft get’s it wrong sometimes.
JMeter is a wonderful product but in some aspects it has it’s kinks. So when you do testing on several remote clients and have CSV data that fills variables you start to hit some ugly issues. In my example here I am reading login data from a CSV file. The thing is, if the same user logs in twice (or more times) simultaneously it’s FIFO. All other users end up throwing an error.
The usual way to tackle CSV files in distributed JMeter environments is to copy the CSV to every client. But that would mean all of them kick off with the same line, thereby causing the problem. You can prevent that by cutting up your CSV into pieces and have one for each remote/client machine. This works but is tedious if the number of clients varies or the CSV changes often. You’d ideally want something more versatile and automagic.
This is somewhat of a strange post here but it’s something I need to remember how to do and because it was hard to find. So if you’re not into JMeter please move on, there’s nothing to see here!
I usually move in the performance testing realm and one of the things I regularly do, is check for obvious omissions in website design before I get into the low down with testing.
What do I mean by that?
There is such a thing as (and I am having difficulty writing this) Best Practice, when it comes to web page development. These are technological imperatives that can be easily checked by using simple tools. You don’t need to be an HTML guru to use these or to gain more knowledge about your website under test.
I do a lot of performance testing with JMeter and every now and again you get thrown a curve ball. I was trying set up a remote performance testing cluster and when invoking the servers with JMeter RMI calls the tests were executing but the valuable results were not coming back to the client. Looking at the log…
Why do we performance test?
*duh* because we want faster response times…. oh and we want to know how to scale our virtual machines…. oh and we want to tune our systems… oh and XXXXX…. there are tons of reasons. Performance testing has it’s testing rigor and we go and “hammer” the system to get at those answers.
One thing I like to do (because it’s fast and cheap) is use a calculator/spreadsheet for performance testing. I take architecture diagrams of present and future systems, infrastructure diagrams, requirements, human oracles and more and put all the numbers together. Then I check if they stack up. Like where the product tries to get 1GB of data across a 10Mbit network link in under a second. I don’t need a test to be able to tell you, that there’s a problem there.
But then it struck me today. There is something similarly simple that I am not doing (and am guessing not many performance testers do)….
Ask yourself, what is the web page that has a response time of 0.000 milliseconds and has a infinitesimally small throughput footprint?