Aryeh Katz wrote:
>without more details about what the CGI and servlets do, it's going to
>be really hard for others to say how to improve or fix the
>performance.
OK. We have a security module that will draw a login screen under certain
situations (not based on basic auth).
In order to accommodate customer look and feel, the login page is written as
a CGI, so nobody is locked in to a particular login page.
>If you're doing tons of regexp in your CGI to do string templating,
>then the answer if obvious. perl regexp is screaming fast and trying
>to do string parsing in a servlet is not what it was designed to do.
Most of the time it's just a matter of constructing HTML code based on
headers and cgi (and servlet equivalent) environment vars. Then send the
page to the user as part of HttpServletResponse.
After the first time the page is generated, it is cached in the servlet to save
processing calls.
Frankly, I tried to keep object creation to a minimum, used StringBuffers to
append, and globals to store. Based on what has to be done, I think I coded
efficiently.
I know I can/should use velocity for the same thing, but I'm hesitant to invest
too much effort if I can't deploy due to performance reasons.
One more update, just to take threading out of the picture. Even with one
request at a time, servlet performance was atrocious
Cgi
Time per request: 7.25 [ms] (mean)
Servlet
Time per request: 44.22 [ms] (mean)
That's only 22 req/s. Either your servlet is really resource intensive (although you think it's not), or either there's a problem somewhere.
Did you try getting the max throughtput using another servlet ? If there's a performance problem with your servlet, you could use something like OptimizeIt to figure it improve it.
R�my
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
