On Fri, 22 Mar 2002, peter lin wrote: > I've been doing benchmarks with JSTL on some dynamic pages and noticed > under medium & heavy load 4-64 concurrent connections, the performance > degrades rapidly. I looked at ExpressionEvaluatorManager and it looks > like it doesn't create a pool of parsers. I posted some benchmarks on > tomcat user mailing list > http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg48946.html > > It might be beneficial to recyle the parsers. this way it would reduce > memory usage and gc. The reason I say is because I am witnessing heavy > disk caching with 4+ concurrent connections. These problems might be > solved by adding 1gig of memory, but that would only be a temporary > fix, especially for systems that can only support 2gigs of ram.
Interesting thought, Peter. Given that instantiating an Evaluator object involves no specific logic on construction, the only cost of not having a pool is that of object creation itself, which should be exceptionally well optimized under any JIT. As a general rule, I strongly hesitate to pool objects unless there's a demonstrated reason it'll help. (Most products pool objects WAY too much, which leads to unnecessary complexity and -- indeed -- potential performance problems.) The performance you're experiencing doesn't sound too good, but do you have any reason to think that the logic within ExpressionEvaluatorManager (in particular) is to blame? The evaluator keeps a static cache of values, so literally the only benefit of pooling our interpreter instances would be to save the instantiation itself, which should take about ten low-level instructions on a modern JIT. (That is, the evaluator has an empty constructor, and all its work is done on the stack -- with the aid of a few static caches.) Thanks very much for the suggestion, though; I'd be curious if you have any data that does implicate one part of the JSTL RI over another. -- Shawn Bayern Author, "JSP Standard Tag Library" http://www.jstlbook.com (coming this summer from Manning Publications) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>