Hi jason,

Here are some answers to your questions. I should have
mentioned this in the original or second message.

--- Jason Koeninger <[EMAIL PROTECTED]> wrote:
> I have a few curiosity questions if you don't mind. 
> First, 
> what's your test configuration?  What platform is
> the machine 
> below running, and what else is running on it? 

PIII 600mhz, 256meg ram, win2K, jdk1.4, memory
settings in catalina.bat is default.

The configuration for coyote is the stock
configuration suggested on the coyote readme. The
httpconnector is set higher than the normal. I'm at
home now, but it should be 100min, 200max processors.
With lower min/max processors the performance is not
as good. The other values are default.

> Also, are you 
> running the load generator on the same machine or on
> a 
> different machine?  Second, have you checked to see
> if the 
> system is swapping memory during your tests?  And,
> what 
> JVM are you using?
> 
> Below, I noticed you said you were going to see how
> fast 
> static content would work.  It might be as or more
> interesting 
> to measure a servlet doing the same work as your JSP
> pages.
> I know that it's supposed to run just like a servlet
> after the 
> compile is done on the first request, but it would
> be interesting 
> nonetheless to remove that overhead and look at the
> differences.

I'm using Jakarta JMeter to do the benchmark from a
separate system. the other applications running on the
system running tomcat are text editor and windows
taskmanager. The disk caching is more heavy with
httpconnector. Not very scientific, but basically I
listen to the hard drive. With httpconnector, the
things spins with 4+ concurrent connections. With
coyote, 16+ concurrent connections I start to hear a
lot of disk caching. I've been know to kill hard
drives that way :)

> 
> Anyway, just curious for my own information.  I'll
> be having to 
> do some load testing of my own in the next couple of
> months 
> so this would be timely information.  

The other tests I am including in my next set include
static html and a third set of pages that use java
with include directive. When I look at the code
generated, using include directive with multiple
<c:choose> statements and nested includes within
<c:when>, the code is pretty messy in terms of how
many times tagfactory is called and nested conditional
statements. Here is an example:

page 1
-------------------
<%@ include file="page2.jsp" %>

page 2
-------------------
<c:choose>
  <c:when test="some condition"><%@ include
file="page3.jsp" %></c:when>
  "repeat previous line about 10 times.."
  <c:otherwise><%@ include file="page14.jsp" %>
</c:choose>

page 3
-------------------
<c:choose>
  <c:when test="some condition"><%@ include
file="page15.jsp" %></c:when>
  "repeat previous line about 10 times.."
  <c:otherwise><%@ include file="page26.jsp" %>
</c:choose>

page 15
-------------------
<c:choose>
  <c:when test="some condition"><%@ include
file="page27.jsp" %></c:when>
  "repeat previous line about 10 times.."
  <c:otherwise><%@ include file="page38.jsp" %>
</c:choose>

The actual pages sometimes add one more layer of
<c:choose> to print out some text, based on request
parameters.

Now of course, the obvious question is "why in the
world are you nesting files that way?" Unfortunately,
I've worked on systems that use includes to build
presentation logic that are pretty complex. Say I
built a web based recipe database and I want to make
it easy to programmatically add new custom templates,
like a cobrand or myrecipe site. Alot of HTML code is
dynamically generated. Using JSTL could be a way to
make it so a person with minimal HTML skills can
create their own cobrand easily.

> 
> Best Regards,
> 
> Jason Koeninger
> J&J Computer Consulting
> 

peter lin

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards�
http://movies.yahoo.com/

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Reply via email to