The following outlines a generic approach to rational problem solving that has been adapted to the situation:

1. State the problem
2. Collect evidence
3. Identify possible causes, and check they are consistent with the evidence gathered. Consider testing or gathering new evidence to prove the cause is present.
4. Look for evidence to identify the relative impact of each cause.
5. Restate the problem with causes, level of impact and confidence in the conclusion.
6. For the causes with the most significant impact decide on a set of solution options, and work out the associated costs and potential benefits of each.
7. Examine in detail potential dependencies between solutions, some will be reinforcing and others at odds. Some solutions may also have functional impact or benefits, and need to be considered beyond the performance arena.
8. Recommend the most appropriate selection of solutions, and gain acceptance of this. Remember to include obtaining the necessary budget, which may require a business case.
9. Develop, test and implement the chosen selection of solutions. Check throughout that the expected benefits will be realised.
10. Monitor the results to check the problem has been resolved to the degree expected.

This process may seem self evident to you, or it may seem un-necessarily complex and long winded. I would strongly recommend, however, the adoption of an approach that is: a) standardised; b) evidence based; c) concentrates on predicting a level of benefit; and d) proves that the level is achieved. There are few organisations with complex applications and infrastructures who have never implemented a performance solution only to find little end user benefit. A structured approach can reduce the incidence of such expensive problems.

If you would like to discuss an appropriate approach for your organisation then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

http://www.businessgreen.com/

Among its articles is this one about the green IT:

http://www.businessgreen.com/financial-director/comment/2214911/emerald-city

The article concentrates surveys about the state of green IT, and the lack of trust that IT purchasers have in the “Green” claims of suppliers. The rush to green wash products is leaving many, me included, sceptical that the benefits extend to the environment and purchasers bank balance – rather than the suppliers.

It is true that there are products that have the capacity to reduce IT’s carbon footprint and hence have real environmental benefits. It is these that need to be examined in the search for a coherent and effective green strategy. If implemented correctly these should also have a reasonable payback period – since the energy consumption will have to be paid for if it isn’t saved.

Without buying new technology, however, it is worth pointing out that only deploying the capacity actually needed may be a strong green IT option. A strong capacity management approach will mean that only the capacity actually needed in the short term will be operating in the data centre. Thus, only that hardware will be using space, power and cooling. If your capacity management strategy is to have sufficient capacity from day 1 to allow the system to perform in the long term then this may be inconsistent with any green agenda.

If you would like to discuss matching IT strategy to your organisation then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

When creating test scripts via “record and playback”, however, the tool will usually record page delays and play them back during the script run – and so the problem is solved. Isn’t it?

There are two issues that must be considered here. The first follows on naturally from the comment above: If the recorded wait time is not realistic then the resultant loading will not be realistic, and so the test will be better but still not correct. This could be fixed by simply using a user who is likely to have realistic waits – assuming you can identify such a user and make them available for the testing. I can be surprising just how long real users do spend on think time.

The next issue is more important, and harder to understand. For illustration let us assume we have 10 users with a 5s think time. Let us further assume that requests usually take 0.1s to process, and that simulated users are started 0.5s apart. In normal operation these requests will never coincide. This could be an issue in itself, but this isn’t the worst of it.

Let us now presume there is a problem – a temporary server issue would be sufficient – that causes all of the responses to arrive back at the client at the same time. It does happen in load testing for various reasons. Now all of the scripts will wait 5s and send the next requests at exactly the same time. The message loading on the server suddenly goes up dramatically, and is likely to continue in this pattern for some time. The result is that the system doesn’t seem to be able to cope with even 10 users in realistic conditions.

The solution is to introduce a level of randomisation in think time delays. It is then possible to introduce an appropriate statistical think time profile – and to break up bursts. The cost is extra test script development time, but the benefit is much more realistic testing.

If you would like advice, or to discuss how to decide on the most appropriate way to set up load testing in your circumstances then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

• The most obvious approach to assure performance is to have sufficient capacity from day 1 to allow the system to perform in the long term. This means that you don’t, in theory, need to monitor the system carefully. The problem is that you then buy considerable capacity up front – which may be an expensive approach given the falling cost of hardware and the reducing time value of money. This approach is also liable to involve extensive up-front testing, which further extends any project pay back period.
• The other extreme is to have hardware, software and procedures in place to only install capacity on a “just in time” basis. This means that you only invest in capacity when it is strictly necessary. In turn that means there is more spend in monitoring, projection and control. It also leaves a question over the objectives during volume and performance testing, and exposes the organisation to a level of additional risk.
• There is an intermediate point where capacity is installed that is believed sufficient to cover a period (such as a year). This is coupled with an end of period review process that examines a need for extra capacity in time for the end of the period. This needs monitoring and projection, coupled with some purchase of excess capacity.

Thus the answer to the original question depends on the strategy adopted for capacity management. Unfortunately, the most appropriate strategy inherently depends on the individual situation. If the cost of the hardware needed in the long term is low then up front installation of the projected capacity requirement makes sense. If the organisation already has the necessary tools and procedures to meet just in time capacity management then that would make sense. What is most critical, however, is that this is a management decision made with a through understanding of the considerations and implications.

If you would like advice, or to discuss how to decide on the most appropriate approach in your circumstances, then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

This is where technologies such as Netezza and its competition approach the problem a different angle. Their solution is to break a data warehouse into pieces spread across large numbers of processing elements. The individual elements then have processing capacity and storage space. They provide a fragment of the answer for each query, and pass their part of the answer back to a process to perform a merge. The fragments aren’t necessarily indexed because the data fragment it runs on can be small enough that it doesn’t provide a performance improvement. The time to process the query improves linearly with the number of processing elements – so pick the number of elements to achieve the required response time. There are many systems that would find this sort of solution very useful.

There are potential pitfalls here too though, especially where there are large numbers of parallel queries occurring, or queries are relatively complex. As usual there is “no silver bullet” and the solution needs to fit the needs of the problem. If you practical experience of these technologies then please share your experience of the approach with me at dh@sarquol.com, or call on +44 7887 536083.

Where there are no manufacturer guidelines, or as the next stage, you would usually to produce your own early tests. The same issues apply though, unless you are able to work with production-like data on a production-like platform. I am not saying not to use this approach – in fact I strongly recommend doing so – only that care needs to be taken in understanding where the test is realistic. As with other forms of planning, consider the risk carefully and plan in a level of contingency that is appropriate for capacity plans.

If you need help in interpreting manufacturers figures, or in setting up a benchmarking exercise then feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

In essence the ITIL approach to capacity management and that which is outlined in Sarquol’s “Principles of Capacity Management” White paper are very similar. The Sarquol Whitepaper provides some information on the “How to…” of Capacity Management and provides less information on the products and activities that are needed. The way that ITIL is constructed is documentary and procedural in nature, which is consistent with the overall objectives that it is seeking to meet. As the basis of a capacity management process it is intended to provide a foundation on which to construct an organisation’s service management approach. As would be expected, however, there is a long way to go from the definition provided by ITIL and a fully worked out process.

I can strongly recommend the design and organisational implementation of a mandatory performance and capacity management approach. If this is to be started then examination of ITIL Capacity Management will provide a strong basis for the early design. If, of course, you need help in such an initiative then Sarquol would be able to provide expertise and support. Please contact me at dh@sarquol.com, or call on +44 7887 536083.

There have been tools available to inject traffic into a system and monitor that data for a while. There have also been tools available to allow such monitoring on a one-off basis when a problem is known or suspected. This doesn’t, however, really go far enough in overall system monitoring since both approaches would usually be used retrospectively. It would seem, however, that the tool manufacturers have started to fill this gap in the performance monitoring market.

The Compuware “Vantage” toolset is a good example of this class of tool. This suite has included a strong range of monitoring, investigation and analysis tools so some time. They have now added a “passive monitoring” facility that starts to meet the requirement to be able to monitor the performance of all client transactions. If you would like to know more about this particular toolset then Compuware have published a fact sheet about it here.

http://jmt.sourceforge.net/

These tools provide a strong set of analytical and simulation capabilities that are designed for computer system modelling. They provide an integrated set of tools with a graphical user interface, meaning that the learning curve necessary to use the tools and understand the models will not be too steep. If you need to apply queuing theory models to a piece of performance analysis these tools are well worth looking at.