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

More documents

Recommendations

Info

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
SOA in the Telco Domain Part II: Capacity Planning of SOA-Based Systems Service Technology Magazine (Issue LIV , September 2011) have a performance test result of service-X as given in table 2 below for processing unit usage and we are using 150 tps with 2 instances as we concluded from previous example. 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 2 – Service-X Processing Unit Usage In this the production environment, when the service runs and reaches 150 tps on load, it will give 2.75% extra for each instance on the platform processing unit. For example, the current condition of our platform still uses only 40% of the processing unit (on peak period). So it still safe to run two instances of service-X on the platform. This baseline data can also be useful when we need to do projection planning. Projection planning is important in making management decisions in regards to the expansion of the platform, both horizontally and vertically. This way they can overcome future events (like Idoel Fitri, Christmas Eve, New Year, etc.). 2. Memory - is used by the services to store data when transactions run, and more is released when the transaction is finished. In some cases memory leakage can also happen. Whenever memory leakage happens, a service cannot release all the memory resources back to the platform. This is because of the quality of service implementation code on object management. So, whenever we want to put a service in production we need to make sure that all the services are free from memory leakage problem. This way it will not disturb our production runtime environment. Unlike the processing unit, to determine how much memory is needed by the services, we will need to do an estimation from the services activity process itself. For example, figure 1 describes the five main activities service-X contains. Copyright © Arcitura Education Inc. 3 www.servicetechmag.com
Page 1: SOA in the Telco Domain Part II: Ca
Page 5 and 6: SOA in the Telco Domain Part II: Ca
Page 11: SOA in the Telco Domain Part II: Ca

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?