Performance testing in an SOA application is done a bit differently compared to any other architecture. We don't just need to validate performance requirements of single service components but also test the orchestration, as well as the third-party services.

We can categorize performance testing in the following way:

Let's go through them in detail.

Component level: When we test the performance of a particular service in isolation it is known as component level performance testing.

Here we test if the response time of the service is within acceptable limits and we also analyze the behavior of the service under different types of performance tests.

This type of performance test is helpful to evaluate the performance of the service in isolation and we get the results early.

We can perform this type of testing easily using SoapUI. We will see this in the coming sections.

Scenario level: When we are done with component level testing and have identified and rectified the performance bottlenecks, the next step is to identify a critical business process to validate.

We aim to verify whether the given business flows, which are achieved via orchestration, are achieved within the acceptable performance measurements.

For example, a new customer order from a retail website will involve multiple service invocations and interaction with multiple databases and third party systems.

Our objective here is to verify the performance of the business tested under varied load conditions.

If the test took more time than expected, a root cause analysis is done to identify any performance bottlenecks like memory leakage, disk usage, and so on.

This type of testing requires a monitoring tool to be set up on the servers which can be used to identify the bottlenecks.

System level: A system level test focuses on putting the load on the architecture of the application and verifying the performance of the architecture under peak load.

To put the load at system level it is advisable to identify the following pre-requisites:

Also it should be noted that if the load balancer is in place we should target the load to the load balancer URL.

Once all the prerequisites have been identified and met we are now good to start system level performance testing.

It can be difficult to identify performance bottlenecks in an SOA solution if we have not first done a component level and scenario level performance test.

The analysis phase is the last and most complex phase in system level performance testing as we have multiple performance counters to monitor and analyze.

We should also take into account the third-party services, components, and systems which would be difficult to performance test and analyze. The reason for why it is difficult to analyze the performance of third party systems is because those services are rarely available to us before production, and we can only stub them till then, we should therefore isolate such services and create stubs of those services.

A solution to this issue is to make sure that the third Party services don't become a bottleneck for the system and should be mocked or virtualized effectively. The Third Party vendor can also share his performance results and then a comparison can be made in case of any conflicts by running a test on the virtualized environment and the performance numbers shared by third party vendors.

Apart from this solution, we can request the client or third-party vendor to provide us with a replica of production.

Let's go through some famous tools in the open source arena for performance testing:

Now let's go through some of famous Monitoring tools – the following are Open Source:

We also have lots of very good commercial tools for performance testing in SOA space: