Imagine an e-commerce provider running out of memory on Black Friday or a search engine provider paying 20 times the cost of their optimal server capacity. Both these scenarios are great examples of what makes a solutions architect cringe. That’s why the ability to forecast the capacity of a system is an important activity in enterprise system design and solution architecture.
Capacity planning is an art as much as it is a science. Along with certain parameters, it also involves experience, knowledge of the domain itself and insight into the system. In some instances, it goes as far as analyzing the psychology of the system’s expected users and their usage patterns.
Mifan Careem from the WSO2 Solutions Architecture team recently wrote a white paper that looks at factors affecting the capacity of a system and how you can calculate your system’s capacity using these factors.
Here are some insights from this white paper.
There are multiple methodologies for carrying out capacity planning. A few parameters that will help include:
- Transactions per second: number of actions per unit time
- Work done per transaction: level of operations a transaction triggers
- Think time: delay between user requests
- Active users: users who use the system at a given time
- Concurrent users: a subset of active users that perform actions at the same time
- Message size: size of the message passed across the ‘wire’
- Latency: additional time spent due to the introduction of a system
- Other non-functional QoS requirements such as guaranteed message delivery, transmission of secure messages, throttling and uptime
After taking the above parameters into consideration you’ll also need to decide what the forecasting period should be, either focusing on only year 1 or whether your requirements will double in year 2. and if so would there be a significant downtime at the end of year one to accommodate this?
Mifan points out that the design of the application or software plays a big role in capacity planning. For each operation factors such as database connections, the number of objects stored in memory, and the amount of processing that takes place determine the amount of memory and processing capacity required. You need to keep these numbers low or share resources effectively in order to create a well-designed and efficient system with lower capacity requirements.
There are some things you’ll need to consider when designing your architecture:
- Profiling and load testing your application
- Caching to improve your performance and latency
- Having buffer capacity when allocating server specifications
- Server profiling via monitoring and profiling tools
You will also need to consider the type of hardware that will be used. This makes a difference as well, Mifan explains. The ideal way to calculate capacity across different forms of hardware is to have benchmarks on these distinct environments.
Here are a few more things Mifan notes that you need to keep in mind for a well-designed architecture:
- Scalability: the ability to handle requests in proportion to available hardware resources
- High availability: a system that is continuously operational for a long period of time
- Disaster recovery: the replication of the primary site onto a geographically separate site
- Backup and recovery: the replication of system state and system data onto a backup medium
- Cloud: allows servers to be deployed in different geographically separated locations providing accessible means of achieving full-scale, high availability
The above-mentioned factors can be used for your capacity planning. The importance of these factors varies based on your environment type. It’s also important to have an accurate business architecture that can be converted to a high-level solution architecture. Based on that your team can start gathering capacity data in order to create the most accurate capacity plan. In addition to forecasting capacity, it’s important to test the environment to identify its peak capacity.
In part two of this white paper, Mifan will show how you can apply these concepts to determine the capacity of an actual use case using the WSO2 middleware platform.