By Ravinder Singroha

In this series of blog, we will understand what we mean by performance testing of a web service, and with each upcoming series, we will take the various commercial and open source tools available to assist us in this venture. Let us first begin with a very basic question:

What is Web Service?

Web services are an XML based technology that allow applications to communicate with each other, regardless of the environment, by exchanging messages in a standardized format ( XML ) via web interfaces ( SOAP and WSDL APIs ). In simpler terms a Web services is a web enabled API. To read and understand further about web services you can visit, Pallavi’s blog.
Lets us now understand what we mean by the Performance Testing

What is Performance Testing?

Performance testing is the process of determining the speed or effectiveness of a computer, network, software program or device. This process can involve quantitative tests done in a lab, such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions. Qualitative attributes such as reliability, scalability and interoperability may also be evaluated. Performance testing can verify whether a system or software meets the specifications claimed by its manufacturer or vendor. The process can compare two or more devices or programs in terms of parameters such as speed, data transfer rate, bandwidth, throughput, efficiency or reliability. For further reading, visit Himanshu’s blog.

Why Web Service Needs Performance Testing?

The next question that comes to our mind is why our web services need performance testing. Here I am going to assume that you are either an experienced reader or you had taken my recommendations seriously and visited the blogs mentioned above.
As you can see in the diagram below that, there is common service provider, which is used by all service requestors. These requestors would want assurance that the web service meets acceptable performance criteria when under stress/load. The goal of performance or load testing of a Web service application is to find how the web service scales as the number of clients accessing it increases. Also, to gather the performance and stability information of the server such as throughput, CPU usage, the time taken to get a response from a web method, etc. when there are, say, 5, 50, 200, 500 concurrent users or more.
The service requestors require these statistics to ensure that the provider is meeting the SLA’s set. Whether they can expect a reliable user experience when a web service is used under load, which may be caused due to, increase in the number of users accessing it and under volume stress, which may be caused when large requests and responses are generated.
In addition, the service providers need to ensure that they have enough web server resources where the service is hosted to cater to the expected load and the web service is scalable enough to function rightly under stress.

Web Service Performance Criteria:

There are various performance criteria, which one should consider when testing a web service for performance.

Server Side:

Throughput: It is measured as number of request sent per second.

Latency (Transaction Time): It is the time taken between service request arriving and being serviced per second. We test the response time as we,
a. Increase the size of web service request, b. Increase the number of virtual users

Resource Utilization: We should be able to figure out the resource demand of the web service under various virtual user workloads/requests volume, so that an optimum resource can be provided for the expected load.

Client Side:

Latency: Time taken for service call to return the earliest response bytes, includes network latency.

Throughput: Average bytes flow per unit time including latency.

Conclusion:
Loosely coupled service environments provide unique benefit for the organizations that utilize them but they introduce new challenges. Both the service providers and consumers should be aware of the performance of the service so that they can ensure it meets the SLA’s specified. Many tools and profilers are available to detect and optimize the performance of a web service. In the next series of blogs, I would be taking a few tools and understand how to do performance testing of a web service using the various tools.

(to be continued…)

By Ravinder Singroha

Software Development approaches have been changed significantly throughout the last decade. Projects typically took several months or even years to complete. After completion of projects, only those projects consider successful which implemented all the given requirements correctly and completely. Until the recent emerge of e-business, Software development project were mainly targeted at the well known business process (Classical approach). Although this method has been applied somewhat successfully to software development projects in the past, the approach is not suitable for commercial projects in the era of e-business process where things are moving fast. Also due to the fact that many projects development efforts are using leading edge technology that is yet not well understood or even evolves during project lifetime and the underlying business models typically rely on a quick time to market, it is impossibly to pin down the complete requirements list at the onset of the project. Projects goals and system functionality need to be frequently adapted, in order to stay competitive in the market.

Well so far so good, before I joined Company even I had read this all about ‘Agile’ or ‘XP’ development technology. But to read and to actually do it is two different worlds experience all together trust me on it.  Reading is easier…

I joined Company as part of a team, which was planning to develop software. The platform we used was dot net + excel as backend. As I was new to the Dot net and language we are using vb.net, first of all I need to learn vb.net as soon as possible I was give one full day for that. I then demanded the requirement document of the project, my Lead told me that there are no such documents, I was little surprised and my TL was even more surprised than me! Work kicked off aggressively. We had a month to complete the first phase; the team started coding the s/w as per the so-called “current requirements”. We had a very dynamic manager, which just added to the agility of the project. Every third day he use to get some new ideas and we had to incorporate the same mind you without changing the time lines. Well I still would like to ponder did we ever had any real time lines!

The first major change which stuck was changing the backed from excel to a much lighter ‘xml’
It was although the very first but not the last bolt of lightening which stuck the team. After successful completion of the phase one and demo, the manager asked us to change the UI altogether so that it is more tested focused! Well till then I had taken my Miranda so ‘zor ka jhatka dheere se laga’. By continuing this agile mode of development we had also become agile i.e. alert for any and easily accepting the changes.

Then came into picture the testing team, well no requirement doc for the team to refer, But I tell you what a marvelous bunch of guys they were, not only they picked up the technology well they left no stone unturned to make our lives hell. In this situation where one side the manager was bombarding us with new features, the other side the testers with their bugs only I know how I survived it all. Every day we had a stand up meeting where the status reports were discussed the progress was monitored closely and issues were discussed and solved too in just those holy 15 minutes.

Well I can keep on writing my experience but my lead has given me just 4 mins to write this, how agile has she become oh god help me, just to summarize my experiences:

1.    Be ready for any type of change
2.    Be positive
3.    Get feedbacks frequently
4.    Try to think as your manager thinks
5.    Write Down All the Changes.
6.    Update Your Timeline As per changes, keep track on the timelines, and estimate the impact of changes on application.
7.    There should be very effective communication between team and respective manager.
8.     Frequent standup meeting for max. 15 mins.
9.    Every body should be present in the meeting.

And the most important thing, it is very vital to have a highly motivated and good leadership skills manager. Hasn’t it been our manager undying enthusiasm and support this product in agile mode wouldn’t have been possible. He gave us credit too though by giving us the “Performance Award” for the quarter.

Anyways readers, I sign off as an agile developer, changes are calling me.