Most SOA based architected applications need to have webservices load tested before we assess the quality of code. Tools like QTP, OpenLoad, NeoLoad etc. provide you with infrastructure and sophistication to achieve this with a price tag attached to it. There is also an open source alternate Apache JMeter. If you are interested in build an in-house java code that just serves your purpose, you should be good to start here
What do you want to test?
- Take one webservice call and test it for the load. Say webservice that fetches list of customers in the database with a matching property criteria (say search of customer from UI)
- You can simulate a constant load of say 50 users
- You may want to setup a step load, of say 10 initial users ramping at the rate of 5 users every two seconds
- Or more….
If you have a network monitor tool or a http proxy debugging tool, you can watch while you perform your screen action how data is going over the network (of-course http only). This will give you an idea of what the input payload is to the webservice end url. Say take an example of Customer search screen where user search criteria options are sent to the webservice and the results are fetched
An important point to remember is “Load Testing is not test the client front end UI but loading the middle tier to see how the database server is responding, how your application server is handling the threads, memory, CPU utilization etc.”
Let’s create the input SOAP Request in a flat XML that can be parsed in your java client which is ready to fire. Say a sample here is search a customer with SOAP request containing firstName starting with ‘Jam’ (ex: James, Jamey, Jamoe)
Simulate a constant load of say 50 users?
Lets first start with One User trying to send SOAP Request to end url
Works for one User? Lets Test it first. Yup, it works.. lets move on…
You can create instances of this thread class in a for loop (want load of 50 users, loop it on counter of 50?), kick of all threads. You can customize this code logic with how you want to see the workflow / actions the way you want to.
You may want to de-couple some of these into small functions where a constant load will just read the input SOAP one by one (50 times) and at one go you can hit the out.write(); that just flushes all at one go.
You can simulate a step-up load by implementing a timer and kicking in the users the way you need it. You can also add markers on the time taken for the requests to get served thread-wise
Want to implement a record and customize script kind of tool? Try JPCap utility which provides you with a http sniffing. Capturing the input and providing a nice interface with tons of data points, you get to keep your job for 3 months atleast.
0 comments:
Post a Comment