Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.
Sun Tzu
Sun Tzu was not thinking about IT systems, nevertheless the ability to forecast behaviors is quite useful in the modern IT. One discipline very important where the "war" can be won before fighting is the Capacity Planning. Actually Capacity Planning is one of the most useful proactive phases of the Application's Quality Management. At the end of the day it answers to the question: when do I have to buy extra hardware to support my online business? The question itself is not stupid or pointless. It involves spending and rational costs management. If I buy today because I need next year I am probably wasting money because within six months the same hardware will be cheaper. The answer to this question is not trivial either, although I have seen CIOs taking the decision of deploy huge CRM systems with poor or no performance testing and without the clue of the system behaviour under load. In these cases the answer to the question has beed easy: get me extra RAM today, buy extra hardware, work 24h to fix the damned app server. Usually CIOs are more concerned about performance and availability of their applications. Let's find out how a good capacity planning can be carried out.
Three main tasks can be identified:
The second task has to be worked out producing a math model. This task it's obviously very important and very complicated. You can assume that the growth of the load will be linear or parabolic or whatever you think it fits your business and you BI data. When I have to deal with this kind of issues I start with some hypothesis that I state very clearly at the beginning of the process then I work out a model, then I review the results: if they are not reasonable I go back and review my hypothesis. This is trivial but it is better to state clearly that this is the only valid method. The core of the Capacity Planning is hidden behind this task, it has to be done carefully. Cannot be a 5 minutes job.
Then working out the time left before performance decreases is easy.
In the graph above I have summarized the overall idea of the capacity planning. This approach is heuristic and has its strength in the starting point: you have the real situation of the application! A performance test discovered the limit of the actual architecture therefore you know point A and C in the graph. You do not know how quickly the applicatiion will get to C. This is really unknown and depends on several factors. To work out a good model is the trick and the most important task. To assume a linear behaviour is the easiest way and can be very accurated in the short term.
Three main tasks can be identified:
- Analyze the Actual system in order to find out which is the current peak load and the current total capacity of the system.
- Predict the growth of the load in the system. This task is always a prediction, therefore it has the precision of a forecast. The more data you have to support the prediction the more accurate it is, nevertheless you still have several degrees of uncertainty.
- Calculate the time before failure.
The second task has to be worked out producing a math model. This task it's obviously very important and very complicated. You can assume that the growth of the load will be linear or parabolic or whatever you think it fits your business and you BI data. When I have to deal with this kind of issues I start with some hypothesis that I state very clearly at the beginning of the process then I work out a model, then I review the results: if they are not reasonable I go back and review my hypothesis. This is trivial but it is better to state clearly that this is the only valid method. The core of the Capacity Planning is hidden behind this task, it has to be done carefully. Cannot be a 5 minutes job.
Then working out the time left before performance decreases is easy.
In the graph above I have summarized the overall idea of the capacity planning. This approach is heuristic and has its strength in the starting point: you have the real situation of the application! A performance test discovered the limit of the actual architecture therefore you know point A and C in the graph. You do not know how quickly the applicatiion will get to C. This is really unknown and depends on several factors. To work out a good model is the trick and the most important task. To assume a linear behaviour is the easiest way and can be very accurated in the short term.
Nessun commento:
Posta un commento