In a previous blog I discussed benchmark testing tools I used for some benchmark perposes. At that time I really used Apache Bench(ab) for the purpose. However when I am again doing some bench mark testing I stumbled upon a new tool(at least for me) httperf which seems to be more advanced and reliable than ab. Although there were ample guidance on how to use this for http GET requests I could not find any easy to read guide on how to use httperf with http POST requests. Following I try to explain how httperf could be used in testing my services.
httperf --server localhost --port 9090 --uri /axis2/services/weather --num-conn 4000 --num-call 16 --rate 64 --timeout 5 > report
Above command is a simple scenario where I request a HTTP get request on a servic running on context /axis2/services/weather on localhost.
It is important to understand the options for the command.
1. –server – ip of the machine service is running
2. –port – port the service is running
3. –uri – The context path of the service on the server
4. –num-con – Number of test calls made to the service
5. –num-call – Number of calls per tcp connection.
6. –rate – Number of connections created per second to make requests to the service.
7. –time-out – This is the maximum time httperf wait for a successful response.
It is important to understand the correct balance between num-conn, num-call and rate options.
The maximum number of requests the httperf would generate = num-call * rate
Clearly your num-conn could be reasonably higher than this number. You could experiment between num-call and rate to produce a good load to the server. The actual number of requests to the server you will see in the generated report could be less than this number depending on the saturation of the server, client or network bandwidth. If such thing happen you need to reduce your num-call or rate options and find out at what point exactly saturation happen. If your num-conn is very large your server may exaust all servicing processes after some time.
Now let’s look at a more advance scenario. Here I am sending a http post request with some payload defined in the file name inputfile.
httperf --server localhost --port 80 --uri /axis2/services/weather --hog --method POST
--add-header="Content-type:application/soap+xml;charset=UTF-8``\n``"
--wsesslog=4000,0,inputfile --max-piped-calls 16 --rate 64 --timeout 5 > result
In adition to the payload you can also specify the http method and the server context uri in this input file. For more descriptions on writing this input file read [1]. Following is the content of the inputfile I used.
/axis2/services/weather method=POST contents="<soapenv:Envelope xmlns:soapenv= \"http://www.w3.org/2003/05/soap-envelope\"><soapenv:Header xmlns:wsa= \"http://www.w3.org/2005/08/addressing\"><wse:Identifier xmlns:wse= \"http://schemas.xmlsoap.org/ws/2004/08/eventing\"> urn:uuid:57becf58-0fc3-1de1-24ad-0012f0b857ac</wse:Identifier> <wsa:To>http://localhost:9090/axis2/services/weather</wsa:To> <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/GetStatus</wsa:Action> <wsa:MessageID>urn:uuid:14d256a2-0f95-1de1-2b1a-0012f0b857ac</wsa:MessageID> </soapenv:Header><soapenv:Body><wse:GetStatus xmlns:wse= \"http://schemas.xmlsoap.org/ws/2004/08/eventing\"></wse:GetStatus> </soapenv:Body></soapenv:Envelope>"
The important additional options of the above command is
1.–wsesslog – This value for this option is a three comma separated parameters. First one is the number of request sessions you need to make to the server. Second is used to emulate a real user delay between sessions. Third is the inputfile.
2. –max-piped-calls – Number of calls need in one tcp connection(in http 1.1). This is used instead of num-call here.
[1] http://www.xenoclast.org/doc/benchmark/HTTP-benchmarking-HOWTO/node6.html
