Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DC176C5.5060906@apache.org>
Date: Wed, 04 May 2011 16:54:45 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 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: BIO performance issues
References: <4DC05F39.2060102@apache.org> <4DC16E0E.6050302@hanik.com>
In-Reply-To: <4DC16E0E.6050302@hanik.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 04/05/2011 16:17, Filip Hanik - Dev Lists wrote:
> On 5/3/2011 2:02 PM, Mark Thomas wrote:
> In a similar fashion, we can also craft a test run that will yield a
> substantial improvement over the old implementation in throughput.
> So there is a test case to prove every scenario.

Could you outline what a test case looks like. It would help with the
general understanding of what problem maxConnections is trying to solve.

> Here is what I propose, and you'll see that it's pretty much inline with
> what you suggest.

Yep. That works for me. I do have some additional questions around
maxConnections - mainly so I can get the docs right.

>> c) remove the configuration options for maxConnections from the BIO
>> connector
> I think you still misunderstand why maxConnections is there, at some
> point you need to push back on the TCP stack.

Some more detail on exactly the purpose of maxConnections would be
useful. The purposes I can see are:
- limiting connections since the addition of the queue means they are
not limited by maxThreads
- fair (order received) processing of connections?
- ?

Mark


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