thanks craig for responding. Here are more details.
"Craig R. McClanahan" wrote:
>
> > Here is a little background on why I am looking for the information.
> > I've been doing some performance benchmarks comparing coyote and
> > httpconnector on 4.0.2 and 4.0.3 with JSTL. My test pages use a lot of
> > includes to dynamically build the header, footer and look of a page.
> >
> > when I used include directive <%@ include file="" %> the performance for
> > 4-16 concurrent connections causes dramatic increases in CPU
> > utilization. When I use action include as in <jsp:include page=""/> the
> > performance is better. Tomcat is running on a resource limited box,
> > 600mhz w/256Mb ram.
> >
>
> Hmm, this result is a little counter-intuitive. The <%@ include %>
> directive causes a single (larger) JSP page to be created -- like the
> "#include" directive in C code -- versus multiple independent pages that
> are linked via RequestDispatcher.include() calls. I'm wondering if the
> "resource limited" part of your description is kicking in.
>
> It would be useful to compare all four combinations:
> - Old connector, include directive
> - Old connector, include action
> - New connector, include dirctive
> - New connector, include action
Before I saw the results, I expected include directive to perform
better. Actually I did several series of tests, including the ones you
suggested. My guess is it's a combination of the code generated and the
thread management causing the CPU spike. One noteable detail is for 32+
concurrent connections, coyote's CPU usage occasionally went down to
zero. The CPU drop had a direct effect on the response time. Here are
some numbers. All times are miliseconds.
include directive - 1 thread 1000 iterations
-----------------
httpconnector ave - 33
cpu usage - 40-70%
action include - 1 thread 1000
-----------------
httpconnector ave - 81
cpu usage - 60-85%
include directive - 2 threads 500
-----------------
httpconnector ave - 453
cpu usage - 85-100%
action include - 2 threads 500
-----------------
httpconnector ave - 299
cpu usage - 80-100%
include directive - 4 threads 250
-----------------
httpconnector ave - 27273
cpu usage - 100%
coyote connector ave - 590
action include - 4 threads 250
-----------------
httpconnector ave - 738
cpu usage - 95-100%
coyote connector ave - 211
cpu usage - 15% less than httpconnector
include directive - 8 threads 125
-----------------
httpconnector - failed to complete
cpu usage - 100%
coyote ave - 1546
cpu usage - 80-100%
action include - 8 threads 125
-----------------
httpconnector ave - 1867
cpu usage - 95-100%
coyote ave - 370
cpu usage - 90-100%
action include - 16 threads 63
-----------------
httpconnector ave - 1323
cpu usage - 95-100%
coyote ave - 792
cpu usage - 95-100%
people2.jsp - 32 threads 63
-----------------
coyote ave - 1215
cpu usage - 95-100%
Simple jsp page that prints out http headers java and jstl to print req
param
1 thread 1000 iterations
-----------------
httpconnector ave - 10
cpu usage - 20-30%
2 thread 500 iterations
-----------------
httpconnector ave - 11
cpu usage - 30-40%
4 thread 250 iterations
-----------------
httpconnector ave - 16
cpu usage - 40-60%
32 threads 65 iterations
-----------------
httpconnector ave - 252
coyote ave - 84
64 threads 35 iterations
-----------------
coyote ave - 136
>
> > Using include directive, the compiled class file gets close to the 64K
> > limit (around 61K).
>
> This is a fundamental limitation of the current JSP page compiler in
> Jasper), because all the code generated for your page ends up in a single
> _jspService() method.
related to this, are there plans to improve JSP page compilation?
>
> Tracking down whether that CPU usage is in the connector versus in the JSP
> page execution would be useful -- they are pretty much independent of each
> other.
My next set of benchmarks I will compare static pages to JSP pages of
varying complexity. the results from the static pages should establish
the theoritical limit, but other than use something like JProbe to see
what is happening, I'm not clear on the best way to see the exact cause.
> I would suggest that you make the experiments on which connector
> independent of which JSP implementation technique is used, as well as
> running them in combination. The performance of a given JSP page is very
> much driven by the quality of the code generated by the compiler (just
> like any situation where you're compiling code). What is not obvious from
> your reports to date is how much joint impact there is -- but it sounds
> like there is more interdependency here than I would have expected.
As I perform more tests and talk with Remy, I can track down what causes
the CPU spike. Or atleast I hope :)
peter lin
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
