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.
If you read this far, you should follow me on twitter here.
Related posts:
Tags: architectural, critical, database, db, decoding, decoding server, diagram, erformance, ip, ip decoding, ip decoding server, might, scale, scale using, scaling, server, system, using
Comments on this entry are closed.