W JAX Performance Workshop - Organisational Antipatterns
2 likes340 views
This document discusses conceptual and organizational antipatterns related to Java enterprise performance. It describes several conceptual antipatterns including misunderstanding scalability, treating performance management as premature optimization, relying on guesswork instead of metrics, and treating frameworks as black boxes. Organizational antipatterns covered include ad-hoc performance management, lack of responsibility for performance, and only addressing performance issues reactively after problems occur. The document provides explanations of each antipattern and recommendations for addressing them such as defining performance processes, roles, and goals.
W JAX Performance Workshop - Organisational Antipatterns
- 1. Java Enterprise Performance Organisational and Conceptual Antipatterns
- 2. People and Performance Good programmers write well performing code Functional bugs are ok Performance problems are not Performance Management is difficult Problems difficult to find Stress Situations Performance is a moving target If it works today, it might not work tomorrow Even testing does not prevent you from problems Unknown performance goals
- 3. Types of Antipatterns Technical Conceptual Organisational
- 4. Antipatterns – A Selection Conceptual Misunderstanding Scalability Performance Management as Premature Optimization Guesswork instead of Figures Black Box Organisational Ad hoc Performance Management Lack of Responsibility Wait for the Pain
- 7. Misunderstanding Scalability Description Scalability is taken for granted Missing performance to be solved by adding hardware Scalability is not tested Effects Performance problems are neglected Architecture has to be changed for scalability late in development Project is put at a high technical risk (maybe too high) Solution Understand that scalability has to be engineered into an application Identify the scalability points Test whether the system can scale
- 8. Premature Optimization Taken from K. Scott Allen‘s Blog : (www.odetocode.com)
- 9. Premature Optimization Description See performance management as premature optimization Do not validate dynamic application behaviour Critical parts of the application are unknown Effects Performance Management gets neglected Problems are discovered late Resolution of problems takes long Solution Perform architecture reviews as part of development process Make basic performance checks part of your Continuous Testing Processes Identify the hot spots in your application
- 10. Guesswork ?
- 11. Guesswork Description People rely on their feelings instead of real numbers The most clever people start to believe in „Performance Voodoo“ Trial-and-Error Problem resolution Effects Phantom problems are solved Long problem resolution times (with high costs) Problems get more complex than they are Solution Implement proper performance analysis procedure Educate people on performance management Build a solid toolbase people can use
- 12. Black Box
- 13. Black Box Description Developers use foreign code without understanding concepts A framework is considered a „silver bullet“ Developers expect frameworks to work how they think Effects Performance problems due to inadequate usage of frameworks High reengineering efforts Long testing cycles Solution Analyse the dynamics of foreign code and interactions with your code Get detailed knowledge about frameworks Never assume - always
- 15. Ad-hoc Performance Management Description Performance Management follows no defined process The actual performance of an application depends on the responsible people Delivering performance is not a key goal Effects Performance of an application cannot be guaranteed Performance management is highly ineffective Skills will not improve Solution Implement performance management in development, test and prod. Define Processes and Responsibilities
- 16. Lack of Responsibility Description Nobody is responsible for performance management Everybody thinks „the others“ will do it Effects There is NO performance management Applications will fail due to performance reasons Performance of applications is unknown There is no budget (time and money) Solution Define responsibilities of developers, testers, prod. People Create the role of a „performance engineer“ and assign it to somebody Communicate performance goals to your team (first you have to have some)
- 17. Wait for the Pain Description Performance is not actively managed and considered as given Performance management is driven by problems Effects Problems are discovered late in the lifecycle Problem must be resolved under time pressure No dedicated ressources for performance management Solution Define performance charateristics of your application Define how to verify they are fulfilled Verify as part of your software delivery process
- 18. alois.reitbauer@dynatrace.com Mail blog.dynatrace.com Blog AloisReitbauer Twitter