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? 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. 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. Best Regards, Jason Koeninger J&J Computer Consulting On Thu, 21 Mar 2002 13:48:15 -0500, peter lin wrote: > > >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]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
