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
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
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 reques
On Wed, 2005-05-04 at 16:02 +0200, Remy Maucherat wrote:
> Scott Marlow wrote:
> > Hi,
> >
> > I wonder if anyone has any feedback on a performance change that I am
> > working on making.
> >
> > One benefit of reducing concurrency in a server application is that a
> > small number of requests
Costin Manolache wrote:
Mladen Turk wrote:
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see
it is still mapping one socket ( 'keep alive' connection ) per thread.
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the s
Costin Manolache wrote:
Which file implements this
( the 100ms timeout and poller ) ?
Poller is inside:
/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java
100ms timeout and passing to poller is in:
/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Ht
Costin Manolache wrote:
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put in the poller, and that thread is freed.
When the next data on that socket arrives, the socket is signaled and
passed to the thread pool.
Mladen.
Sorry, I missed that. So w
Mladen Turk wrote:
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see
it is still mapping one socket ( 'keep alive' connection ) per thread.
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put in the pol
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see it
is still mapping one socket ( 'keep alive' connection ) per thread.
No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put in the poller, and that thread
Costin Manolache wrote:
Further more I don't see how can you avoid keep-alive connection
problems without using a thread-per-connection model.
The point is that with 100 keep-alive connections you will still
have 100 busy threads.
Why ? 100 keep alive connections doesn't mean 100 active requests,
i
Remy Maucherat wrote:
I looked at this yesterday, and while it is a cool hack, it is not that
useful anymore (and we're also not going to use the concurrent utilities
in Tomcat, so it's not really an option before we require Java 5). The
main issue is that due to the fact keepalive is done in bl
Mladen Turk wrote:
Scott Marlow wrote:
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.
Can you compare the performance of you code with the standard
implementation when the concurrency is lower then maxThreads
value?
I see no point to make patches that
Scott Marlow wrote:
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.
Can you compare the performance of you code with the standard
implementation when the concurrency is lower then maxThreads
value?
I see no point to make patches that will deal with c
Scott Marlow wrote:
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.
One benefit of reducing concurrency in a server application is that a
small number of requests can complete more quickly than if they had to
compete against a large number of running
Hi,
Repeatable benchmarks showing a significant improvement for some use case
would be appreciated (certainly) and a prerequisite (probably) for addition
into this relatively core part of Tomcat. I don't think this is much
different than setting the current maxThreads (and min/max Spare threads) a
15 matches
Mail list logo
