Sizing and Capacity Planning Tips and How-to

Question

I am often asked to perform sizing and capacity planning for our clients. When our clients buy our products (basically J2EE web applications), they often ask what hardware they will need to run those products. Our recommendations often result in high-cost hardware acquisitions.

So far, the best heuristics I developed is to compare the utilization projections (number of registered and concurrent users that application should attend) with the data gathered at our existing installations. Something like: If installation A attends 100 concurrent users with X hardware, then installation B will need 2*X hardware to attend 200 concurrent users.

This approach, however, has a number of problems. Clients often use different hardware and software platforms. The set of products they buy from us is generally never the same and generally parts of application are built on order for specific client. Put into account that software versions are changing etc. and there are so many parameters that can make the task of sizing very difficult.

I studied some books on the subject and some propose using complex mathematical models. The number of parameters these approaches require as input (for example detailed classification of application features) makes me think these are hardly useful. Hardware is generally ordered before even the basic requirements are defined not to mention that these will vary throughout application development and lifecycle. So, how do you go about sizing and capacity planning? Any tips and how-tos appreciated.

Answer 1

If the app scales horizontally in a gracefull way, a rough initial estimate is ok as a starting point. Adding or removing additional boxes as required should be easy once the app runs in production.

Answer 2

There is no easy or mathematical formula to predict scale in the description you gave, if you (or your company) are serious about this then the best way is to build a performance & scalability test environment where you can easily setup & tear down various client configurations and send load at them to see how they will do. Because you are building custom components, one poorly written component or missing index can mess everything up, so having an environment like this is where you can iron these things out before giving to the client. Once you have this type of environment, you can add memory & cpu to the app servers & databases to see how your application scales.

I would suggest a VM environment where they can easily add cpu & memory based on needs of the application, coupled with some realistic external load/scale testing using a service like watchmouse or browsermob.

Answer 3

If hardware must be ordered before the basic reqs are defined, well, about the best you can do is to ballpark the capacity by looking at your installed base for a similar set of projects (as you are doing now). Keep track of your existing customers experience in scaling and capacity needs as they grow their installations, and if you have a large enough base, you can probably do rough curve fitting by grouping similar projects with similar hardware and looking at capacity needs. Watch how existing customers capacity needs change during growth as well for additional data points.

Ideally, the initial HW/SW buy is for a pilot installation, and you benchmark the pilot setup once it is up and meeting spec. Use those results to project capacity needs for the move from pilot to production. Of course, this requires time in the pilot-to-production schedule to benchmark the app then order and take delivery of the equipment. But it will give a more accurate capacity estimate than doing it all upfront.