Summary
Despite all the changes in tools and diagnostic technologies in the past few years, Web application performance-tuning still relies on basic trouble-shooting skills and simple common sense.
Advertisement
This afternoon, in a busy hallway of the Moscone conference center at JavaOne, I got mixed up and got into the wrong line: instead of entering the "Web Application Stress Testing" session, I attended "Top Ten Ways to Botch Enterprise Java Scalability and Reliability" session given by Cameron Purdy.
Cameron's presentation was to-the-point, and very effective, as he mixed witty quotations from leading programmers, writers, engineers and philosophers with his humor and personal experiences. I enjoyed the session quite a bit since it was obvious that he had come across real-world and complex Web application tuning problems before.
The ten ways of botching were all common-sense ways such as: know your requirements, use common sense and assume nothing—take things with a grain of salt, or know where your application's bottlenecks are. This was for sure the best technical, real-life session I have attended in the past two days.
What I found amazing, however, was that almost exactly three years ago to the day I posted a web-application article on Artima, written with Jeffrey Blake, about my experience with web-application performance tuning. It would seem that nothing has changed in the past three years in about Web application tuning: no silver bullets and no easy ways out, just simple trial and error, hard detective work, and good planning.
A word of comment to Sun and the JavaOne organizers: JavaOne technical sessions are so much more helpful when they are presented by battle-scarred programmers and IT professionals who have been through the real-life drama of programming and solving IT issues. A lecture from a Sun or Java project team leader is simply just that: a lecture filled with theory, overhead slides, and void of real-life experience. I find it extremely valuable to learn from the actual work-experience of others as it helps me avoid problems that they have faced before.
If you feel you discovered any enlightening experience or tip solving a Web application performance problem in the past few years, please feel free to add it to the comments. Who knows, you may end up helping a software engineer solve his or her performance problem on time, and get him or her to go home in time to catch the late-night show.
I think web application performance is a very good thing for us to be looking at. It's eye opening when you have the Fasterfox extension installed just to see how long typical page loads take. For instance with this years JavaOne Session Builder nearly every user interaction caused a page refresh or partial refresh that took at least ten seconds. And this experience is not uncommon. I think it's sad. We have faster servers, faster networks, faster desktops and yet we still spend a lot of time just waiting.
This may sound too much like an advertisement but I really don't mean it that way... Just sharing my experiences (which I had even before working at Macromedia/Adobe). With Flex my applications make less requests to the server, the server doesn't deal with state or page construction, and the data can move across the wire in a much more efficient binary protocol. This results in web applications that perform better in nearly all ways. Having a JIT compiler in the client side VM certainly helps as well. If you want to see this point illustrated check out the RIA performance benchmark application I built: http://www.jamesward.org/census
Anyways I think this is a great topic that we need to be talking more about and not just trying to cover up the problems with more/faster hardware/networks.
Previous Topic
