Architectural Musings

Architectural Musings

Welcome to the musings page! Being a solution architect, I encounter many system architecture oddities that need working out. Usually, I start with what's already known by skimming the web. If that doesn't work well enough, I do my own investigations. And of course I document what I have learnt to be useful for others so they can skim the web etcetera etcetera.

I call those documenting efforts 'architectural musings'. I write them down here, feel free to use it at will.

Oh, and if you find these pieces of info useful, please drop me a quick feedback to help my self esteem. Thanks!

A Quick Trick to calculate services infra impact

Posted by Administrator (admin) on Feb 11 2010
Architectural Musings >>

You've designed all those neat new services and now it's time to deploy them. How do you calculate the infrastructure capacity impact of these services beforehand? At a recent project, I was faced with this issue when a major shift to a SOA architecture required the applications hosting party to know just that. I developed a quick and simple calculation method, which I'll share with you in this article.

For reference: The two components of capacity consumption

The two major components of the capacity usage of a services landscape are (for brevity's sake):

  1. CPU usage of operation execution logic
  2. CPU and memory usage by consumers of each service call transaction time

The first should be obvious. The second probably requires some additional explanation. From my experience, application servers hosting service consumers allocate threads, memory and CPU time to having those consumers wait for responses from other services. The allocated resources are proportional to the number of waiting consumers during a period of time. Quick responses require less resources than longer response times.

Step 1: Visualize service call flow

The first step is, of course, determining the service calls. Nothing too special abou this, just list each consomer-provider interaction.

To illustrate things, see the simple example below:

Don't think too much about the names, it's just to illustrate my story.

The above interaction graph (it's not really official UML, so I won't use an official name here) shows the consumer-provider interactions in the service landscape. It also demarcates the services ('boundary', 'process', 'core business', 'backend') which will be useful later on when we need to say something about resource usage. 

Now I've used a simple graph here, but for more complex landscapes you would probably use some combination of UML interaction diagrams (like a Sequence Diagram). The point is to have a means to visualize the service interactions and the types of services.

Step 2: calculate service call quantities

The next step is to use some smart calculation mechanism to calculate the total number of service calls in the flow. This is also nothing special (notice a pattern here?) and basically comes down to 'counting arrows'. The simple graph depicts that e.g. Core Service A is called once, Core Service B is called twice, Backend Services A and B are both called twice etc.

To calculate the total number of calls, an easy method is to put all interactions into a spreadsheet, like so:


Consumers go on the horizontal row, providers on the vertical row. Each cell is a 'hit' from one consumer to one provider. The total calls can be derived by simply summing up the numbers. 

Step 3: Apply Resource Capacity Consumption Criteria

So now we have a quick quantification of the service call flow. Although this gives us a calculation of the number of calls, it doesn't yet tell us anything about the total resource usage. To do that, we need to apply some extra qualitative critera and recalculate.

For the sake of brevity, I'm taking the two capacity consumption components mentioned above. I'm also making the following assumptions:

  1. A service call to an external system (backend system, third-party service) has a long response time
  2. A service call to a local service or database has a short response time
  3. The impact ratio of a long versus a short response time is 4 to 1, i.e. a long response time requires 4 times more resources than a short one.

Now, since we have our model in a spreadsheet, the effects of these assumptions are relatively easy to see. In the picture below, I have added two columns and simply added an extra multiplication factor of 4 to the 'long response times' column.


 The other advantage of using the spreadsheet is that you can also apply all kinds of nifty visualizations, like the 'short-to-long' pie chart to illustrate the capacity usage ratio.


I have shared with you a very straightforward method to quickly estimate the capacity consumption impact of a services architecture. I have experienced in everday practice that this type of estimate is becoming increasingly important, since SOA inspired architectures are somewhat standard by now.

If you use this method, please drop me a note to share your results.

Last changed: Feb 18 2010 at 12:32 PM



None Found

Add Comment