On Thu, 21 Mar 2002, peter lin wrote:
> Date: Thu, 21 Mar 2002 12:24:24 -0500
> From: peter lin <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: coyote & httpconnector design
>
>
> I searched the tomcat-user archive and couldn't find anything on the
> design difference between coyote and httpconnector in 4.0.1-4.0.3 tomcat
> releases.
>
> If anyone can point in the right direction, I'd really appreciate it.
>
I'll let Remy speak to the details (Coyote is his baby), but the primary
motivation was to improve performance. A secondary motivation was to fix
some HTTP/1.1 things that were hard to make work correctly in the original
HttpConnector design.
> 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
> 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.
> Using action include each compiled class file is
> under 20K, most around 8K. Aside from the obvious "business logic should
> be in beans," I am trying to figure out ways to improve the performance
> and get a better understanding of why CPU utilization shoots through the
> roof.
>
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.
> Using the latest coyote beta with 4.0.3 seems to perform 2-4 times
> better than httpconnector, depending on the page. I've also done
> benchmarks with very simple pages that print out http header/request
> parameters and coyote seems to be twice as fast. For complex pages that
> have a lot of includes that call includes, the performance gains are
> bigger.
>
I wouldn't be surprised to see even larger improvements on some real world
apps, depending on how they do their request and response I/O.
> Obviously using JSTL is more process intense than putting java code in
> the jsp pages, but part of the goal of this experiment is to see how
> much of performance hit JSTL incurs. One of the goals of this test is to
> hide java code, so that designers and html coders don't see java code.
> It may be that some of the repetative logic should be made into custom
> tags, but before I do that, I want to get a deeper understanding of
> coyote architecture.
>
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.
For the long term, though, I would plan on optimizing performance based on
using Coyote for Tomcat stand-alone use -- it's looking pretty darn good.
> thanks.
>
> peter lin
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
