tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <tcw00l...@yahoo.com>
Subject Re: Coyote Performance
Date Fri, 19 Sep 2003 13:05:50 GMT
 
I'm totally lost :)
 
The only other thing I can think is NIO or differences between HTTP 1.0 vs 1.1.  I looked
at the parseRequestLine method and it's pretty straight forward. From what I can tell, it
only parses: method, uri and protocol.
 
java.net.SocketInputStream.read isn't called directly from within the method. I only see it
use the ascii buffer and byte buffer. Remy will know more about it, since he wrote it. I get
a feeling something else is holding up the input stream. If I remember correctly, in jdk1.4,
java.net uses NIO internally when it can. Someone correct me if I am wrong.
 
Last year I discovered a bug in NIO call back, which resulted in weird behavior. I believe
it is fixed in the latest version, but there could be a similar bug in NIO which indirectly
affects Coyote connector.
 
 
peter
 


David Morris <David.Morris@plumcreek.com> wrote:
In this case, we get better performance from a single processor server
than multi-processor. The average response on the single processor
system is about 7 seconds under load. With the http connector I see
about 4 seconds on the multi-processor system, which is OK and will
support our user load, but it isn't that great considering the
capabilities of the machine. With the http connector I do see quite a
bit more CPU activity, but it is still constrained.

Our iSeries uses IBM's Power4 processors and from what I understand may
re-order instructions. In other words, it is weakly consistent hardware
and can break optimization techniques like lazy loading with double
checked locking, which assume instruction ordering. I doubt that the
inconsistent hardware is causing this problem but wouldn't be surprised
at all if the multi-processor part is.

Overall, the wait on the socket read is taking the vast majority of the
time. I don't have the actual numbers here at home but it was something
like 95% of the time. I have run this dozens of times switching between
the coyote and http connectors and see the same results each time. I am
in the process of installing WebSphere so that I have something to test
this against and may try out Apache if I get enough time.

Thanks,

David Morris


>>> tcw00lfel@yahoo.com 09/18/03 6:45 PM >>>

After reading Tim's response, I think his idea might provide some clues.
If the CPU usage is low and the page is simple, it should only take
200ms to process the page.

I would test the page on a single processor workstation and measure the
actual page processing time. Once you have a base line measurement, it
will be easier to figure out if multi-cpu race condition is causing it.

in the benchmarks I've done on a hello_world.jsp with 4.1.07-21 using
both connectors, coyote was always faster. I'm a little suspicious of
the 35 seconds for a simple page. Simple jsp pages that don't make DB
queries should finish within 1 second.

peter 



David Morris wrote:
I agree it is odd. We do not have any filters defined and this is a
pretty simple JSP page that is 32K. There is no database interaction and
very little processing going on to service the request. This is running
on a fairly capable multi-processor iSeries system. In this case we see
response times that grow disproportionately to the size of the response.
We see almost no CPU activity for these requests, it is all a wait on
that socket read. There could be a comm problem but the http connector
is using the same underlying comm support. 

Thanks,

David Morris

>>> tcw00lfel@yahoo.com 9/18/2003 5:03:46 PM >>>

that is truly bizzar. Are you using any request filters?

The only thing I can think of is if some request filter is processing
the inputstream. By any chance, did you try the same profiling with a
super simple hello_world.jsp. If you see the same exact behavior from
hello_world.jsp, then it is coyote. If not, there could be something
else interfering with coyote.

the bug may not appear with the older connector and is the result of
your page + coyote. I've seen this kind of bugs in the past.


peter


David Morris wrote:
I hope this is a simple configuration issue. Here is my setup for the
Coyote and HTTP connectors:

port="8080"
minProcessors="5"
maxProcessors="95"
enableLookups="true"
redirectPort="8443"
acceptCount="10"
debug"0"
connectionTimeout="60000"
useURIValidationHack="false" />

-vs-

className="org.apache.catalina.connector.http.HttpConnector"
port="8080"
minProcessors="5"
maxProcessors="95"
enableLookups="true"
redirectPort="8443"
acceptCount="10"
debug"0"
connectionTimeout="60000" />

I profiled the an offending page interaction using a tool from IBM
called performance explorer. To analyze the results I used a tool from
IBM called Performance Trace Data Visualizer. Compared to other tools
I
have used, it is more similar to JProbe than jProfiler in that it
shows
hierarchical clock time. This tool also tracks processor usage, inline
time, locks, threads, object creation, garbage collection, etc. From
what I can see there are no locking issues and the read method of
java.net.SocketInputStream is taking the majority of the processing
time.

When I saw that the Coyote Connector was invoking the
SocketInputStream.read(byte[],int,int) routine, I tried the old HTTP
connector without expecting any performance change. The > 8 X's
performance increase was totally unexpected and I am just trying to
find
out how to do the right thing (use the coyote connector). In both
cases
there are 17 calls to with one being a thread startup. Of the 16
calls,
the 15th is the one taking up the bulk of the time (6,437,348 NS vs.
5,950 - 150 NS). 

Thanks,

David Morris

>>> tcw00lfel@yahoo.com 9/18/2003 12:18:49 PM >>>

I'm not totally clear on how you profiled the page. Did you use
OptimizeIt/JProbe, or simply added a start time at the beginning and
at
the end.

from first hand experience, I doubt the connector is the cause, but I
could be wrong. What in your struts page is causing it to take 35
seconds? You might want to time the actual application process and see
how much time it takes.

In theory and practice reading the input into buffers scales better.
What exactly does the page do with the input in the first place?

peter


David Morris wrote:
I did some profiling of a slow page (Struts based) on a site using the
Coyote connector. This site does not use Apache. It appeared that a
java.net.SocketInputStream.read being invoked from
org.apache.coyote.http11.InternalInputBuffer.parseRequestLine() was
causing a bottleneck. In this case average response over a 5 page
interaction with three being relatively simple and two being complex
averaged 35 seconds per response when repeated 20 times. 

I changed the site to use the old and deprecated http connector and
performance improved to 4 seconds per response. It appears that the
org.apache.catalina.connector.http.SocketInputStream was much faster.
Since Coyote is recommended, does anyone have any ideas on how I can
get
it to perform better? Over dozens of tests, it appears that large
pages
take a long time with the Coyote connector.

Thanks,

David Morris

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message