tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Marlow <scott.marlow.opensou...@gmail.com>
Subject Re: Tomcat performance patch (in development) to reduce concurrency...
Date Wed, 27 Jul 2005 23:34:08 GMT
On Tue, 2005-07-26 at 16:55 +0200, Remy Maucherat wrote:
> Remy Maucherat wrote:
> > Scott Marlow wrote:
> > 
> >> Anyway, my point is that this could be a worthwhile enhancement for
> >> applications that run on Tomcat.  What I don't understand yet is whether
> >> the same functionality is already in Tomcat.
> >>
> >> I should point out that some applications shouldn't limit the max number
> >> of concurrent requests (long running requests won't benefit but maybe
> >> those applications shouldn't run on the web tier anyway :-)
> > 
> > I agree with the intent, but this is not implemented properly. I think
> > the idea is to restrict concurrency in the application layer, rather at
> > the low level (where, AFIK, concurrency isn't that expensive, and is
> > better addressed using a little non blocking IO). The performance
> > benefits for certain types of applications will be the same, but without
> > introducing any unwanted limitations or incorrect behavior at the
> > connector level.
> > 
> > I think you should write a ConcurrencyValve instead, which would do
> > something like:
> > 
> >     boolean shouldRelease = false;
> >     try {
> >         concurrencySemaphore.acquire();
> >                 shouldRelease = true;
> >         getNext().invoke(request, response);
> >     } finally {
> >                 if (shouldRelease)
> >             concurrencySemaphore.release();
> >     }
> > 
> > As it is a valve, you can set it globally, on a host, or on an
> > individual webapp, allowing to control concurrency in a fine grained
> > way. In theory, you can also add it on individual servlets, but it
> > requires some hacking. Since it's optional and independent, I think it
> > is acceptable to use Java 5 for it.
> > 
> > As you pointed out, some applications may run horribly with this (slow
> > upload is the most glaring example).
> 
> It took forever (given it's only 10 lines of code), but I added the 
> valve. The class is org.apache.cataline.valves.SemaphoreValve.
> 
> So you can add it at the engine level to add a concurrency constraint 
> for the whole servlet engine, without constraining the connector (which 
> might not be low thread count friendly).
> 
> Rémy
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
I tried SemaphoreValve today and it worked as expected. Nice job! :-)

I also tried a JDK1.4 flavor (SemaphoreValve14) which uses Doug Lea's
concurrent.jar and that worked as well (I omitted fairness support and
defaulted to fair.)

Depending on the Doug Lea concurrent jar will be a problem as that jar
is not used in Tomcat.  However, if someone wanted to build it
themselves with their own copy of concurrent.jar, that would work.

Should I post the Java 1.4 flavor of SemaphoreValue14 here?

Scott


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


Mime
View raw message