Java Theory and Practice: Performance Management-Do you have a plan?

Performance management is often seen as a sorcery, because performance problems usually occur after application development is complete. By then, it would be difficult to determine their origins. However, once the cause of the performance problem is determined very accurately, it is often easier to fix it. Engineers are often quite creative in finding more effective ways to perform special tasks (sometimes they are too creative). For any given performance problem, by using caching to reduce redundant computations or simply adding more hardware, the solution may be as simple as replacing it with a more efficient algorithm. However, it can be difficult to clearly identify the root cause of a performance problem, and it is even more difficult to design complex programs so that they do not have a performance problem first.

While programming decisions-such as the suboptimal (sub-optimal) choice of algorithms or data representations-cannot reuse the results of previous calculations, or poor resource management-often considered a direct cause of performance problems, most performance problems have a deeper cause: inability to integrate performance management, goals, and measurements first into the development process.

Problem? What's the problem?

How do you know when you have a performance problem? For most development teams, the answer (in terms of the description of the crime by the US High Court Judge Potter Stewart) is that it is known when it is encountered. This is the core of the problem-performance goals, metrics, and measurements are often not considered until it is too late to find them.

The most common performance management strategy is ... Also nothing, it usually takes one of the following two forms:

Completely ignore performance before application development is complete

Optimization at development time, which usually means focusing only on very small performance considerations and ignoring the larger aspects

The two strategies share the same basic problem-they do not see performance management as an integral part of the development process.

Defective performance Strategy A: completely ignoring performance

The first approach is to completely ignore performance, which sees performance as something that can be handled at the end of a project, such as writing a release note or building an installer. The strategy is largely a matter of luck, because the computer is running faster than a year, so it can always cope with performance.

This problem of luck (even when the odds of success is very high) is that when performance problems arise, you do not have the framework to deal with it, determine its root cause, or address it in a special way. You also did not schedule the time for performance measurement and tuning in your development plan. This is a bit like a Web site, in addition to installing a firewall with a default configuration, does not attempt to use a consistent security policy and then discovers that they have been stolen. Where do you start?

Defective performance Strategy B: Optimizing at development time

Another common but even worse approach is to drive architecture and design decisions with minimal performance considerations. Developers like to optimize code, and the justification is that it's satisfying and fun. However, knowing when to optimize is more important when it comes to the code of concern and the timing of addressing performance issues during the development cycle. Unfortunately, developers generally cannot intuitively determine where a performance problem will actually appear in the application. As a result, they have wasted a lot of effort to optimize code paths that are rarely executed, or worse, they have compromised design and development practices to optimize components that didn't have any performance problems earlier. When you're buried in writing code, it's easy to see a tree without the forest on performance issues.

Making the individual code paths run as fast as possible does not guarantee that the final product will perform well. It is impossible to make local optimizations to compensate for the fundamentally inefficient design, even if each component is implemented as fast as possible. The development-time optimization strategy replaces the performance strategy implemented for the entire project with a focus on low-level performance considerations, and it makes you unsure that you really have a performance strategy.

One of the many problems with optimization during development is that it ignores inherent risks in optimization. Few optimizations also make the design better and fewer errors, but these are exceptions. In general, optimization involves trade-offs between performance and other considerations, such as clean design, clarity, flexibility, and functionality. Optimization takes a certain amount of cost and risk: it may introduce errors, limit the functionality of the code, or make it more difficult to use or maintain. Before you accept these costs, make sure it is worth it.

Take performance management as part of the development process

From the outset, performance measurement and planning should be integrated into the development process, with separate, staggered iterations for development and performance measurement and tuning. This means setting performance targets, preparing performance measurement scenarios, and often reviewing code performance when developing code. It is a good idea to save old test results in a database so that you can easily compare the performance changes when you change the code.

A separate iteration of development and performance allows you to focus on writing error-free code during development iterations, and you know that there will soon be an appropriate opportunity to improve performance if needed. If you think of a clever trick to make your code run faster, add a comment in your code to describe your idea in detail, but don't do it now! Now is not the time to optimize. If this is ultimately necessary, then return when you are concerned about performance. Performance optimization should be driven by performance targets and supported by performance metrics. Something else is just "secondary".

Measure it two times and then measure it several times.

Measurement is a key element of performance management. Think about this: does a given trick make the code run faster? We are ready to verify this. The Performance measurement tool is used to test performance before and after implementation of the ingenious plan. What if you don't get an improvement? Well, prepare to take back your coup. If you can't measure the benefits, why risk damaging the work code?

During performance iterations, the performance of the application or its components is measured and compared to the measurements of the previous iteration. Have you slowed down in some ways? Find out why. If it doesn't reach the performance goal, you don't necessarily have to change it, but now you've got valuable feedback about the performance impact of your changes.

Have you reached your goal?

Performance tuning seems pointless if you don't have quantitative performance goals and a measurement plan that supports them. How do you know you've reached your goal? Other development phases, such as coding, testing, and packaging, define goals-implementing this set of functionality, correcting these errors, and so on. The performance phase should also have structure and objectives.

Performance goals are particularly important when performance concerns are derived from the outside, whether in the customer or another department within the company. When someone tells you to make a program run faster, you should first ask "How much do I have to make it fast?" "Otherwise, you may invest too much resources in tuning, but you still won't be able to satisfy your customers." Put Shipi energy to make the program run faster 30%, but someone responded "Gee, I was hoping to increase the speed by 50%." "It's going to be disappointing," he said.

Conclusion

Performance management includes not only optimization, but also many other things. It has a framework for deciding when to optimize when not optimized. You should make these decisions based on clear performance goals, measurements, and planning, rather than intuition.