News: Performance: A Chapter from Professional JSP 2nd Edition
A chapter on performance excerpted from "Professional JSP 2nd Edition" from WROX Press has been posted on the resouces page. The chapter covers "general strategies and specific techniques for optimizing Servlets and Java Server Pages" by examining stress testing, profiling, optimizing JSP pages along with looking at the effects of the JVM on performance.
- Posted by: Ed Saikali
- Posted on: August 28 2001 20:08 EDT
Read Chapter Here
- Performance: A Chapter from Professional JSP 2nd Edition by Niles Ho on August 28 2001 22:42 EDT
- Performance: A Chapter from Professional JSP 2nd Edition by Magesh Lakshmi on August 29 2001 13:27 EDT
- Performance: A Chapter from Professional JSP 2nd Edition by Niko Schmuck on August 30 2001 04:44 EDT
- Performance: A Chapter from Professional JSP 2nd Edition by dan daly on August 31 2001 06:56 EDT
- Performance: A Chapter from Professional JSP 2nd Edition by Ken Horn on September 03 2001 12:53 EDT
- Performance: A Chapter from Professional JSP 2nd Edition by Niko Schmuck on September 04 2001 09:14 EDT
May I add that besides the quality of the application code, the quality of the servlet container has a big influence on the speed and scalability as related in the book. Tomcat, for example, is well known to have very slow speed. Rexip AppServer, on the other, has been tuned to have superior speed compared with other known brands.
Yet another article on performance benchmark. Nothing special.
It's very interesting to see some explict comparision of the stress testing results when the optimization comes along, but IMHO it's not only important to mention how many clients are accessing in the same time, but also the time (and distribution!) between the requests. This i've not found, only that the tests are running over 4 minutes. It's far more easy to achieve good response times when the servlet container has the chance to "recover".
I believe both Orion and Rexip uses a test in which you stress test the server by bombarding it with requests one after another.
For example, you start 10 client threads, each of which send a request. Upon receiving ther response for this request, it immediately sends anohter request.
This is the so-called saturation analysis.
Reading the code, I see a couple of significant problems. The connection references in the servlet code, Controller.java are instance variables -- ie not thread safe, this would certainly cause problems during stress testing. Also, the getConnection method in ConnectionPool, has a scary busy loop that would cause livelock for up to 10secs(!) if the pool was empty (and scanning arrays is hardly the most efficient method). I realise the code is supposed to be demonstrative, but it shouldn't lead inexperienced coders into quite important thread issues.
Bit disappointed there was no mention of buffering issues -- I've found on Jasper, that tag and nested buffers are one of the main performance hits..
that's very interesting that you are mentioning Jasper here, because we really want to use and push it, but it has several performance lacks when it comes to the execution of custom tags. Please have a look to
bug #3130 that i reported about that issue.
We are also in discussion (see a thread on tomcat-dev from my colleague) with one of the Jasper developers to get this further.
What is your conclusion, still using Tomcat? Any hints are very welcome.