The main overhead is with keeping track of and processing Filters (which don't exist in Servlet-2.2). TC 3.3.x also has some optimizations based on the fact that it is illegal to wrap the Request/Response objects in Servlet-2.2. Of course, Servlet-2.3 encourages wrapping the Request/Response :-).
"Chris Agmen-Smith" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hello, Thanks for all the great feedback so far. Firstly, Bill Barker writes that: >For non-JSP sites that don't require Servlet-2.3 features, >it is very hard to beat TC3.3 for performance. Oh dear! We use Velocity, not JSP. What are the additional overheads in the Servlet 2.3 spec? Secondly, some clarifications for Yoav Shapira, who had some good questions to ask: (1) Is the problem CPU or speed? The high CPU use is our main concern. When CPU load gets too high, speed suffers and users get errors as connections become limited. So we get concerned if CPU use gets too high - and it seems like a good way of estimating the maximum number of pages we can serve from a single box. Quite simply, we max out our server if we use Tomcat 4.1, yet it runs well within safety limits on 3.3. (2) JDK? Yes, it is the same JDK and hardware (Java 1.4.1_02-b06, Solaris 8 on the same boxes we use for Tomcat 3.3). (3) Down-weighting? We down-weighted the Tomcat 4.1 server from a load factor of 9 to a factor of 4. The CPU %usr is then roughly the same as for the Tomcat 3.3 machines, but the number of pages served is far less. (4) Profiling results? (skip this bit if it bores you) - note first that the Tomcat 4.1 process clocks up more _TOTAL_ CPU time than the Tomcat 3.3 process. The exact amounts vary, but we just ran another load test and Tomcat 4.1 used about 1.35 times as much CPU time, over a 10-minute period. Under Tomcat 3.3, 34% of that time was spent on java.net.URLEncoder.encode; for Tomcat 4.1, 23%. This method is being called roughly the same number of times, to encode the same number of links - and the total number of CPU cycles on each server dedicated to this method is roughly _the same_. The % difference comes because the _total_ number of cycles for the whole Java process is greater on the Tomcat 4.1 box. I don't think encode() is the cause of the difference in performance. I _DO_ think that java.net.SocketInputStream.read uses twice as many cycles under Tomcat 4.1 as it does for Tomcat 3.3. Is it being called twice as often? That still doesn't account for the huge difference in CPU utilisation overall, though. (5) Profiling tools? Evaluated Jprobe and OptimizeIT. OptimizeIT was about a million times easier to use, the documentation was more succint, remote profiling worked first time, it ran OK on the command line on the remote server, etc. It really does work out of the box! The results, though, were pretty much the same (measured CPU time, not elapsed time!). I still can't see an obvious CPU-hog that wasn't there in Tomcat 3.3. (6) JVM runtime options? These were the same for the tests, but I have tried tuning them, to no avail. Heap size of either 256mb or 384mb, depending on which test run we used. (7) Why upgrade? Damn good question - we might decide not to. We would like to make use of servlet filters for various things, we want to build a web services portal and we want to hook up to Jboss and revamp our business tier - and Jboss is conveniently bundled with Tomcat 4.1, not 3.3. We also thought we might be able to serve more pages from fewer servers, amusingly enough. Thirdly, Endre Stølsvik writes: > TC5 is supposed to take the good-shit from both TC3.3 and > TC4 and make "the very best" Servlet Container in the universe. I really hope so. It doesn't look very stable yet, but I will try it out when it is. Any more thoughts or suggestions from anyone? Chris Agmen-Smith ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs service. ________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
