Scaling up

by daniel on September 2, 2009

Post image for Scaling up
Performance is one of the critical aspects of any non trivial system as it affects all parts of the system. When scaling up the chances are that some part will be a bottle neck. Here are a few ideas on analyzing the performance of a system and how to scale up. As always, an ounce of prevention saves a pound of correction.

Performance can be measured in MB/sec, requests/sec or GUI performance. The performance is actually a set of performance metrics at different stages of the system. Lets assume a system for analyzing IP traffic and generating statistics, as depicted in the following diagram.

The diagram depicts two entities: the IP decoding server and a database (DB). Assuming we need one database to hold all information, we have several limitations:

• The input to the IP decoding server (1)

• The output of the decoding server (2)

• The input to the DB (3)

The input and output of the IP decoding server are simple to understand; They refer to the processing capabilities of one server of such type (without taking into account hardware issues). Database performance is trickier as it refers to insertion into tables as well as retrieval of the inform ation or processing statistics. The system performance is actually the capacity of the lowest link in the chain.

Assuming the IP decoding server is the bottleneck, the scaling up might mean allowing for multiple IP decoding servers connecting to one database. Usually such architectural changes, due to coupling between the components might require logic changes and database modifications. In addition db constraints on multiple accesses might appear.

Scaling up of databases is much trickier, since each database vendor provides different paths for scaling. Some scaling up paths are:

• Scale using more CPUs in an SMP machine – Microsoft SQL

• Scale using more machines in cluster environment- Oracle RAC

• Scale using more machines in MPP architecture – IBM DB2

Is it known that architectural changes are expensive and disruptive, but even more so is changing database vendor. Choices of architecture and scale are critical in the basic design of a system for making a small system adaptable to growth. Tradeoff is development time or additional costs.

Being performance such a critical issue for system design, explicit requirement and clear communication to stake holders is a must. Using performance requirements for selecting the components and having a development path can reduce the possibility of having a major architectural change when scaling up.

Comments on this entry are closed.

Previous post:

Next post: