|
|
|
|
Back to newsletter 027 contents
This month I had the pleasure of interviewing Alex Rossi, a technology partner at Accenture. I first met Alex about seven years ago when he was project manager on one of the largest Java projects in the world - and that was 1996 when Java was only in the low 1.1's. No JIT, no HotSpot, basic garbage collection, and very few optimizations in the core classes! If he could make an enterprise project scale then (and he did), it's worth finding out what he's learned.
Q. Can you tell us a bit about yourself and what you do?
I am a technology partner in Accenture, my role is to identify business opportunities involving IT integration and n-tier architectures. We help our clients implement these at all levels, at the organisational level, the process level, the tool level, and from the design/build/run standpoint. My focus is primarily on open architectures, with Java being the core business solution on the application server and integration layers.
Q. You were an early Java adopter and by 1996 you were already involved in one of the biggest Java projects in the world at the time. Was that a sucessful project?
Definitely yes, we succeeded in a very complex integration thanks to our global approach, which considered the importance of creating a sound development architecture and the related processes needed to create a professional environment capable of supporting more than 100 developers. This was when Java IDE and design tools were at their infancy. We also had to pay a lot of attention to the operational side of the development solution, because at that time the Java marketplace did not supply the vast array of tools and products you can find now.
Q. What performance lessons did you learn from that project?
"Trop d'objet tue l'objet" - A too much object-oriented system kills object orientation, meaning that being too purist in OO leads to a system which has to handle millions of objects, which had serious performance issues and also maintenance complexity issues.
I would say that you need to plan for a "denormalization" process like the one you do in the E/R world. To achieve good performance you need to balance simplicity against the flexibility and "beauty" of your OO model.
Q. What do you consider to be the biggest Java performance issue currently?
Tuning the number of server JVMs serving the clients and tuning the number of threads per JVM is still a guru task, not to mention the complexity of this tuning when it has to be done in a specific container environment. Also Garbage Collecting, although it has significantly improved in the latest JVM versions, can represent an issue especially in real time systems when you need to handle the possibility of having a system "freezing" or significantly slowing down for a couple of seconds during GC.
Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?
Integrating your application server execution with your mainframe system achieves full reusability, but you walk on thin ice to get a decent end-user performance. You have to balance the number of layers and systems you have to cross in order to get data, against the performance cost of leaving data on the mainframe. To obtain acceptable performance I have often had to replicate business code or data onto the application server.
Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?
Not planning a serious performance and scalability test window. For a complex project, I am talking about 2-4 months with a 3-5 person dedicated performance team.
Q. Which change have you seen applied in a project that gained the largest performance improvement?
Handling the effects of the last question, i.e. creating a team which is focused on operational and performance issues.
Q. Have you found any Java performance benchmarks useful?
We have used many, but I really believe in the specificity of performance issues for each project and on the need for running adequate performance tests. Also, many benchmarks are commercially baised towards specific platforms/products which makes them less useful.
Q. Do you know of any performance related tools that you would like to share with our readers?
I have found OptimizeIT and Mercury LoadRunner two excellent tools, one in the domain of single user tuning of the application, the other in tuning of the application for scalability.
Q. Do you have any particular performance tips you would like to tell our readers about?
Forget about "Java takes care of object allocation and release". If you want to understand and tune your application, you need to understand the object allocation mechanisms of the JVMs. Do not hesitate in investing to create the right skills and buying the right tools for managing this very specific and important task.
(End of interview).
Back to newsletter 027 contents
