Showing posts with label Tools. Show all posts
Showing posts with label Tools. Show all posts

Saturday, November 13, 2010

Java bench - Simple and lightweight service load testing tool

At WSO2, we use various types of tools and programmatic approaches to load, stress and performance test SOA middleware products. Out of them, one particular tool is part of almost all engineers workspaces. It is Java bench (or java-ab).
Java bench is the java clone of the popular ApacheBench load generator customized for better HTTP1.1 support.

Java bench is a very simple and easy to use utility. One of the greatest advantages of using it for performance testing is, its lesser overhead on load generation machines. Most of the load generators consist of rich UIs and reporting utilities hence the load generator it self consumes considerable amount of CPU and memory when you run performance testing in single server. It is always not practical to run load generators in separate machines. Sometimes we need to run load/performance tests against a server running on a local machine in order to provide quick feedback about the product under test or reproduce perf/memory issues. In these situations, Java-bench is the ideal solution.

Lets see how we can run a basic performance test using java bench.

Pre-requisites:
Linux or windows OS
jdk1.5 or higher

Step 1
Download Java bench from here and extract the downloaded zip file.

Step 2
Go to the root of the extracted directory and run 'java -jar benchmark.jar' to see the available options.

usage: HttpBenchmark [options] [http://]hostname[:port]/path
-v Set verbosity level - 4 and above prints response
content, 3 and above prints information on headers, 2 and above prints
response codes (404, 200, etc.), 1 and above prints warnings and info.
-H
Add arbitrary header line, eg. 'Accept-Encoding:
gzip' inserted after all normal header lines. (repeatable)
-n Number of requests to perform for the benchmarking
session. The default is to just perform a single request which usually
leads to non-representative benchmarking results.
-T Content-type header to use for POST data.
-c Concurrency while performing the benchmarking
session. The default is to just use a single thread/client.
-h Display usage information.
-i Do HEAD requests instead of GET.
-k Enable the HTTP KeepAlive feature, i.e., perform
multiple requests within one HTTP session. Default is no KeepAlive
-p File containing data to POST.

Step 3

We will run a load test against one of the publicly available web services. I use a simple web service hosted in xmethods which generates a list of prime numbers that are less than a specified max value.
First you need to invoke this service using SOAPUI or some other client and capture the SOAP request message. Then save it as a xml in your file system.

Sample request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://microsoft.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:GetPrimeNumbers>
<web:max>56 </web:max>
</web:GetPrimeNumbers>
</soapenv:Body>
</soapenv:Envelope>

Step 4

Now, we can use java bench to send series of requests to the above web service as follows.

java -jar benchmark.jar -p SoapRequest.xml -n 100 -c 10 -k -H "SOAPAction: http://microsoft.com/webservices/GetPrimeNumbers" -T "text/xml; charset=UTF-8" http://www50.brinkster.com/vbfacileinpt/np.asmx

As you can see, we specify the soap request xml with -p parameter. -c specifies the no.of concurrent threads/clients used in the test. -n is used to specify the no.of requests transmitted per a keep-alive connection. In our example, each client carries 100 requests therefore 1000 total requests will be sent to the service. -k enables HTTP keep-alive so that multiple requests share the same HTTP session. -H is used to specify the HTTP headers. In our example, SOAPAction HTTP header is appended to the message. You can find the relevant SOAPAction from the WSDL of the service. -T is used to specify the Content-Type header of the request. The last parameter is the endpoint of target service.

After the test is completed, you will see the result as shown below.

Server Software: Microsoft-IIS/6.0
Server Hostname: www50.brinkster.com
Server Port: 80

Document Path: http://www50.brinkster.com/vbfacileinpt/np.asmx
Document Length: 429 bytes

Concurrency Level: 10
Time taken for tests: 59.378401 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 756000 bytes
Requests per second: 16.84 [#/sec] (mean)
Time per request: 593.784 [ms] (mean)
Time per request: 59.378 [ms] (mean, across all concurrent requests)
Transfer rate: 7.22 [Kbytes/sec] received
5.51 kb/s sent
12.73 kb/s total

Simple. Isn't it? We will look in to more interesting tests with java-bench in future posts.

Sunday, January 11, 2009

Get your Axis2 service or module archives validated using WSO2 tools

When creating Axis2 service archives (AARs) or module archives (MARs), it is important to adhere to the defined archive structure and standards. With the help of automated tools, you can validate these archives. WSO2 service and module validators can be used to validate your service or module archives freely in an efficient manner.
These tools are shipped as components inside WSO2 WSAS and hosted in WSO2 Oxygen tank developers portal as well.

If you have WSO2 WSAS binary distribution, validating aar or mar files is a simple process as given below.

1. Access WSAS management console using http://localhost:9443/carbon
2. Select Service Validator in the left menu



3. Select your axis2 service archive (aar file) and click on Validate AAR
4. Validation report will be shown as given below.



If WSAS binary distribution is not available, you can get your service or module validated using the online validator hosted in WSO2 Oxygen tank.

1. Go to http://wso2.org/tools
2. Click on Service Validator link under Validators section

you will be directed to the above AAR validator UI where the service archive can be validated.

Similarly, module archives (MARs) as well as service and module descriptors (services.xml. modules.xml) can be validated.

Tuesday, August 5, 2008

How to use tcpmon inside Eclipse

Apache TCPMon is an utility that allows the messages to be viewed and resent. It is very much useful as a debug tool. If you don't know much about this tool, you can find more information here , here or here.

I found an extension of this great tool, which can be included as an Eclipse plugin so that developers can monitor message transmission within their workspace without opening a separate tcpmon instance. It is very cool indeed.

Saliya Ekanayake, a colleague at WSO2 has developed this utility as part of his university project. Lets see how this tcpmon plugin can be used in Eclipse WTP.

1. If you haven't done yet, download and install Eclipse WTP

2. Download tcpmonitor-1.0.0.jar from here

3. Copy tcpmonitor-1.0.0.jar in to Eclipse_home/plugins directory

4. Start eclipse

5. Select Window --> Show View --> Other --> Tcp Monitor --> TCP Monitor

6. Tcp monitor will be added as an view tab.



Now you can configure the necessary port settings and trace message transmission.

Thursday, July 31, 2008

Web application testing in Ruby(Watir) - 2 minutes guide

Watir (pronounced as Water) is a free open source tool which can be used to automate web applications. It is an extension of Ruby programming language. Unlike most of the other testing tools it gains the advantage of powerful features of Ruby and simulate browser interactions in very simple manner.
Lets see how a simple google search is automated using Watir in few steps.

Pre-requisites
Install Ruby (1.8.5-24 or later)

Step 1

Install Watir. Open a command window or shell and issue the following commands
gem update --system
gem install watir

The above two commands update gem installer and then install watir in your system.

Step 2

Open SciTE ruby editor or notepad and start to create the following script.

require "watir"

ie = Watir::IE.new

ie.goto("http://www.google.com")

ie.text_field(:name, "q").set("WSO2 WSAS")

ie.button(:name, "btnG").click


Step 3

Save the above file as SimpleTest.rb and run it from the command line by typing SimpleTest.rb
You will see that an Internet Explorer browser instance will automatically be popped up, access google, type "WSO2 WSAS" text and click on search button as a user interacts with the web site.

Step 4

Lets see what each of the above statements of our test script do.

require "watir" - This is similar to an import statement. This tells ruby script to use Watir as an extension library

ie = Watir::IE.new - Instantiate a new IE browser instance and open it

ie.goto("http://www.google.com") - Instructs IE instance to access google.com

ie.text_field(:name, "q").set("WSO2 WSAS") - Set text, "WSO2 WSAS" as the search query

ie.button(:name, "btnG").click - Click the "search" button

If you need to simulate web interaction with Firefox, you can use FireWatir, which allows to write test scripts for Firefox browser.