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 <[EMAIL PROTECTED]> 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 >>> [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
