Hi, I think your testing, servlets, configuration is all fine. The maxProcessors-1 observation is something I've noticed in the past, but as you say I don't think many people care because they deal with ~75 maxProcessors (the default value).
The second observation: two requests to the same servlet always handled serially. Tomcat normally creates one instance of a servlet for every declaration in web.xml. The exception is SingleThreadModel (deprecated, don't use this) servlets. There's no provision in tomcat to create more instances as the load on the server increases (maybe there is such a provision and I've missed it?). Instead, the processing threads should call the servlet methods in parallel. I'm not sure why you're not seeing this behavior, perhaps someone else could comment, as I have to run to a meeting ;) Yoav Shapira Millennium Research Informatics >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 25, 2004 1:56 PM >To: [EMAIL PROTECTED] >Subject: RE: TC V4.1.29 Coyote Connector / minProcessors maxProcessors / >Confusion > >Yoav, > >Thanks for the quick reply... > >>Create a servlet that takes a long time to process, so you can easily >>observe the connections. Then make sure you make two concurrent >>requests to that servlet, and that the servlet's HTML output doesn't >>contain images, CSS references, or any other entities which would cause >>a separate HTTP connection to be initiated by the browser for that one >>page. This type of page is the most common cause for perceived problems >>with concurrent request processing. > >I wasn't working with any images, etc. - reduced quickly to KISS level >configs & testing as a consequence of more than a couple of decades >worth of battle scars ;-) > >Simple servlet, doGet implementation, simple HTML out, 30 second sleep. >Built several variants, different only in class name. Manual deployment, >no WAR file, a set of servlet classes in several different contexts. >Servlets HelloWait, HelloWait2, HelloWait3, etc. Contexts cctest1, >cctest2, etc. > >Used a multi-tabbed browser (Mozilla) to test, though behavior the same >with separate browsers on multiple clients (enlisted the aid of several >of my cohorts). Also used lovely little multi-threaded Java HTTP test >client gadget to slam in requests from multiple clients concurrently. > >First observation: > >Behavior in general indicates number of concurrent requests serviced >equal to maxProcessors - 1 (not maxProcessers-minProcessors as I >suggested in earlier email). > >Second observation: > >This one really threw me. Independent of maxProcessors value, multiple >concurrent requests to the same servelet in the same context appear >to be handled serially - one at a time. Multiple concurrent requests, >each to a different servlet in the same context or a servlet in >another context appear to be handled concurrently, subject to my >first observation. > >I was ready to buy the maxProcessers-1 thing as a simple implementation >oversight - not surprising since most use Tomcat for much higher volume >stuff. Second observation suggests something really strange with 4.1.29 >(most of our earlier testing experimentation was with 4.1.27) or I have >made a really toady configuration error. > >I have attached 2 representative servlet source samples - pretty >trivial, server.xml, default web.xml (renamed as web_default.xml) and >example context web.xml for servlets. Would have zipped but found >that not permitted for list mail. Maybe something in these I'm doing >wrong? > >Tomcat running (for test execution) on an HP dual proc (Intel PIII 1.133 >GHz) platform running Linux - RedHat 7.1 - little or no extraneous load >during the testing. > >Any insight might have would be well appreciated. > >Regards, > > -Jim- This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
