tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 侯树成 <chain...@gmail.com>
Subject Re: how http connector backlog attribute works?
Date Mon, 30 Dec 2013 07:10:41 GMT
Hi,
Today, I find the acceptCount  of connector is not work like it's config.
You can try it like this:
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" acceptCount="2" maxThreads="1"
minSpareThreads="1"/>

Also use LR/JMeter make more requests( >10) .  You will find that 5
requests will served correctly, others will be refused.

When the acceptCount=3
   <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" acceptCount="3" maxThreads="1"
minSpareThreads="1"/>

 You will find that 7 requests will served correctly, others will be
refused.


When the acceptCount=4
   <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" acceptCount="4" maxThreads="1"
minSpareThreads="1"/>

Also use LR/JMeter make more requests( >10) .  You will find that 9
requests will served correctly, others will be refused.

Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right?

why the acceptCount is not work like it's configuration?

Could you help me?



2013/12/27 侯树成 <chainhou@gmail.com>

> Yes, this must use BIO mode, because the NIO maxConnections=10000 in
> default, it won't block the LimitLatch. In my test case,(use JMeter, thread
> number is 5), 2 requests will refused soon(just 1s-2s later), then another
> 3 requests will served correctly.In source code, I find the backlog
> attribute will send to ServerSocket constructor, So, the backlog attribute
> is worked inside of JDK, not in Tomcat?
> Thank you all for reply.
>
>
> 2013/12/27 Mark Thomas <markt@apache.org>
>
>> On 27/12/2013 08:53, Mark Eggers wrote:
>> > On 12/27/2013 12:37 AM, Mark Thomas wrote:
>> >> On 27/12/2013 07:27, Mark Eggers wrote:
>> >>> On 12/26/2013 11:09 PM, 侯树成 wrote:
>> >>
>> >>>> 1.set tomcat connector like this:
>> >>>>       <Connector port="8080" protocol="HTTP/1.1"
>> >>>>                  connectionTimeout="20000"
>> >>>>                  redirectPort="8443" acceptCount="1" maxThreads="1"
>> >>>> minSpareThreads="1"/>
>> >>>>
>> >>>> 2. deploy a war file, which contains a servlet that will sleep 60s
in
>> >>>> it's
>> >>>> doPost method
>> >>>>
>> >>>> 3. use LR or JMeter send 5 requests to the serlvet above
>> >>>>
>> >>
>> >>> I'm going to guess based on the Tomcat 7 documentation:
>> >>>
>> >>> request 1 gets executed and sits in your doPost for 60 seconds
>> >>> request 2 consumes the minSpareThread
>> >>> request 3 consumes the acceptCount
>> >>>
>> >>> Per documentation, connections 4 and 5 are dropped immediately.
>> >>
>> >> That is almost right except that there should not be a spare thread at
>> >> step 2 since maxThreads includes any spare threads.
>> >>
>> >
>> > Yep, that's what I would expect as well. I was just trying to
>> > rationalize the third accept.
>> >
>> > I agree, I would think that 1 would be served, 2 would wait, and 3-5
>> > would be dropped.
>>
>> Figured it out. The OP is using BIO where maxConnections == maxThreads
>> by default.
>>
>> Request 1 uses the one available request processing thread.
>>
>> Request 2 is accepted but is blocked since the maximum number of
>> connections has been reached.
>>
>> Request 3 uses the accept count.
>>
>> Requests 4 & 5 are blocked.
>>
>> It might be worth a note in the docs that the number of connections
>> accepted will always be maxConnections + 1 with the "+ 1" being blocked
>> in the acceptor thread until the number of connections drops below
>> maxConnections again. I'll try and add something later today.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message