Capacity Planning of SOA-Based Systems - Service Technology ...

SOA in the Telco Domain
Part II: Capacity Planning of SOA-Based Systems
Service Technology Magazine (Issue LIV , September 2011)
Measuring can be done through benchmarking and performance test in environment that most resemble like
production one.
For example, let us measure a service for purchasing Blackberry package registration products from the UMB
channel, and we will refer to this as service-X. Forecasted loads will be at 300 transactions per second (tps)
with service level agreement not more than 25 seconds. To do the benchmarking, we can give load test stepby-step
from 100 tps until y-tps where the services performance starts to degrade. As a sample, we have the
below performance test results:
NO
# Load
(tps)
Response
Time (ms)
& Increase Form
1 2 3 4
1 100 1200
2 150 1250 4.17%
3 200 2300 91.67% 84.00%
4 250 3210 167.50% 156.80% 39.57%
5 300 4000 233.33% 220.00% 73.91% 24.61%
Table 1 – Service-X Performance Test Result
We can see that most response time is gained at 100 tps, which is our baseline. Performance starts to degrade
slightly when we give 200 tps loads to the service. Running service at 150 tps with 2 instances to handle 300
tps load can process faster than running 300 tps with 1 instance. On row no. 2, 1 transactions per second will
takes 8,33 ms to finished. For 300 transactions per second, it will needs only around 2500 ms. If we compare
with 300 tps with 1 instances it will need 4000 ms to complete. Within 4000 ms two instances of service at 150
tps can complete around 480 tps.
From this analysis, we can conclude that service-X can handle at most 150 transactions per second. And
running two service instances at 150 tps will give better results than running one instances at 300 tps.
Services Resources Sizing
Another sizing that we need to do at services level is the system resources. System resources sizing is more
about the processing unit and memory usage needed by a single service instance to run at certain transaction
load level. Planning services resources size will then correlated with the platform capacity sizing. There are two
main aspects we need to plan:
1. Processing Unit - is defined by how many cores are needed by a single instance to run a certain
transaction load. This is one of the most important aspects we need to calculate because service
availability depends a lot on the availability of the processing unit; we cannot run more services if there is
no processing unit available. We also need to put it when we try to design a Disaster Recovery Site for the
SOA.
To know how many instances we need, processing unit usage can be found out through benchmark and
performance test on the environment that most resemble the production environment. For example, we
Copyright © Arcitura Education Inc. 2 www.servicetechmag.com