Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4DC0363C.6090701@hanik.com>
Date: Tue, 03 May 2011 11:07:08 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: bindOnInit and maxConnections for AJP connectors
References: <BANLkTin3-=RmgdAOv+nHSAHquTqfN5akNA@mail.gmail.com>
	<BANLkTinJLMixTa0qmfrj==vo2+QmY7k0wg@mail.gmail.com>
	<4D9C4B72.5060308@apache.org>
 <BANLkTinPAc4dPNc2B3-mkaN=uJQnbkxOnw@mail.gmail.com>
 <4DB083B3.2020404@apache.org> <4DC03240.7010901@apache.org>
In-Reply-To: <4DC03240.7010901@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 5/3/2011 10:50 AM, Mark Thomas wrote:
> On 21/04/2011 20:21, Mark Thomas wrote:
>> On 06/04/2011 22:51, Tim Whittington wrote:
>>> On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas<markt@apache.org>  wrote:
>>>> On 05/04/2011 10:50, Tim Whittington wrote:
>>>>> Is what's actually going on more like:
>>>>>
>>>>> APR: use maxConnections == pollerSize (smallest will limit, but if
>>>>> pollerSize<  maxConnections then the socket backlog effectively won't
>>>>> be used as the poller will keep killing connections as they come in)
>>>>>
>>>>> NIO: use maxConnections to limit 'poller size'
>>>>>
>>>>> HTTP: use maxConnections. For keep alive situations, reduce
>>>>> maxConnections to something closer to maxThreads (the default config
>>>>> is 10,000 keepalive connections serviced by 200 threads with a 60
>>>>> second keepalive timeout, which could lead to some large backlogs of
>>>>> connected sockets that take 50 minutes to get serviced)
>> This is still an issue. I'm still thinking about how to address it. My
>> current thinking is:
>> - BIO: Introduce simulated polling using a short timeout (see below)
>> - NIO: Leave as is
>> - APR: Make maxConnections and pollerSize synonyms
>> - All: Make the default for maxConnections 8192 so it is consistent with
>> the current APR default.
>>
>> The other option is dropping maxConnections entirely from the NIO and
>> APR connectors. That would align the code with the docs. The only
>> downside is that the NIO connector would no longer have an option to
>> limit the connections. I'm not sure that is much of an issue since I
>> don't recall any demands for such a limit from the user community.
> Apologies for what I expect will turn out to be a long e-mail.
>
> I have reached the point where I believe the best way forward is:
> - remove maxConnections from NIO and APR
> - remove the ability to set maxConnections for BIO and hard code it to
> maxThreads
-1
maxConnections serves a purpose. It protects against a DoS.
There must be a way to configure a system to eventually push back, and not just keep accepting connections.
Therefor the maxConnections should stay.
> - restore the disable keep-alive when>75% BIO threads are in use
why, make it configurable. I would believe that on many systems, the queued approach that BIO has, still can provide significant improvement 
in performance. If I don't want queued behavior, I'll just turn off keep alive.

> My reasoning is as follows:
> - Servlet 3.0 async requests mean that current connections in use may be
> greater then current threads in use.
>
> - This provides potential efficiency savings as less threads are required.
>
> - That connections may be greater than threads led to the new
> maxConnections attribute.
the maxConnections attribute is simply to restrict the acceptor thread from just going on and on.
It had nothing to do with servlet 3 or async. It's a protective measure for the server.

> - maxConnections>  maxThreads introduces an issue where a connection
> with data may be in the connection queue waiting for a thread whilst all
> the threads are busy doing nothing waiting for data on connections that
> will eventually time out.
and this is still better than simply not accepting any connections at all.
Right now, in order to work around the blocking aspect, one has to configure acceptCount so that connections are not simply turned away.
> - This issue can be fixed with simulated polling.
I wouldn't do simulated polling. I'm not sure what benefit there would be.
> - Testing showed that simulated polling was very CPU intensive (I saw a
> typical increase from ~40% to ~50% CPU usage with 4 Tomcat threads, 2
> 'fast' client threads making requests as fast as they could, 10 'slow'
> client threads making a request every 5s and a pollTime of 100ms on an
> 8-core machine.
>
> - The additional resources required by simulated polling are likely to
> be greater than those saved by reduced thread usage.
>
> - It is therefore better to just increase maxThreads, expecting that not
> all of them will be used and hard-code maxConnections to the same number
> as maxThreads. Better still, just use NIO.

you still need maxConnection


> Further, the complexity of BIO code required to support:
> - Optional configuration of maxConnections>  maxThreads
> - simulated polling when maxConnections>  maxThreads
> - auto-disabling of keep-alive for users that don't want the overhead of
> simulated polling when maxConnections == maxThreads
> was getting to the point where I had stability concerns.
>
> Given the above, and assuming there are no objections, I intend to
> implement the way forward I set out above tomorrow.

I'm confused about what you are trying to do or achieve. What problems are you trying to solve?
This email thread started with two missing attributes.
I'd start a new thread describing the problem you are having.

best
Filip

> Cheers,
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1321 / Virus Database: 1500/3612 - Release Date: 05/03/11
>
>


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