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: domain of knst.kolinko@gmail.com
 designates 209.85.220.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=EpVLQYpob37fyEsf8YGxDdt9QR0VCFS5/bv1VBkWqzR4yY4DamBHnvzwfud0ITQ5f3
         w4BGCI7qYD0976g3SujXLuzeWgtg6bmOkMHOV1o0RH05qVPIS0C/s2kLwkpVp8LiFByg
         aIL21cKaQu3a4BPW3RDkGA9/WaWj18td1Rhk8=
MIME-Version: 1.0
In-Reply-To: <4DC05F39.2060102@apache.org>
References: <4DC05F39.2060102@apache.org>
Date: Wed, 4 May 2011 15:04:47 +0400
Message-ID: <BANLkTi=fcnnhk6UTx6Ls4qnjHAJsWowFcQ@mail.gmail.com>
Subject: Re: BIO performance issues
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Tomcat Developers List <dev@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/5/4 Mark Thomas <markt@apache.org>:

> Time: 2s
> Activity: Group B clients connect and are added to the queue
> =A0 =A0 =A0 =A0 =A0100 threads are allocated to process the B connections
> =A0 =A0 =A0 =A0 =A0The B connections are processed and returned to the qu=
eue
> =A0 =A0 =A0 =A0 =A0100 threads are allocated to process the B connections
> Queue: None
> Threads: A, B
> Group A: Allocated threads. In HTTP keep-alive for 1s
> Group B: Allocated threads. In HTTP keep-alive for 0s
> Group C: Inactive
> Group D: Inactive
> Group E: Inactive
> Group F: Inactive
> Group G: Inactive
> Group H: Inactive
> Group I: Inactive
> Group J: Inactive
>

> Time: 6s
> Activity: Group F clients connect and are added to the queue
> =A0 =A0 =A0 =A0 =A0A connections send requests
> =A0 =A0 =A0 =A0 =A0A connections are processed and returned to the queue
> =A0 =A0 =A0 =A0 =A0C connections are processed and returned to the queue
> =A0 =A0 =A0 =A0 =A0D connections are processed and returned to the queue
> =A0 =A0 =A0 =A0 =A0E connections are processed and returned to the queue
> =A0 =A0 =A0 =A0 =A0F connections are processed and returned to the queue
> =A0 =A0 =A0 =A0 =A0A connections are allocated threads but are in keep-al=
ive
> Queue: C, D, E, F
> Threads: A, B
> Group A: Allocated threads. In HTTP keep-alive for 0s
> Group B: Allocated threads. In HTTP keep-alive for 4s
> Group C: Queued. In HTTP keep-alive for 0s
> Group D: Queued. In HTTP keep-alive for 0s
> Group E: Queued. In HTTP keep-alive for 0s
> Group F: Queued. In HTTP keep-alive for 0s
> Group G: Inactive
> Group H: Inactive
> Group I: Inactive
> Group J: Inactive

I do not quite get what happens in 6s. My first understanding from
reading the scenario was that the threads at 2s are busy because we
need them to process keep-alive connections. Then I see that at 6s
keep-alive connections are in the Queue.

What prevents those connections that exist at "2s" from being placed
in the Queue?


What is "simulated polling" that you tried to implement? Was it trying
to read data from each of keep-alive sockets in turn with a short
timeout? Where increased CPU usage comes from?


> The proposed changes are:
> a) restore disabling keep-alive when threads used >=3D 75% of maxThreads

Anyway, if the problem persists, I'll be +1 for a), as it should
prevent us from falling in this state.

+0 for b)..e), as I do not quite get them. An alternative could be to
change the default value of maxConnections and calculate it from
maxThreads.


I wonder, maybe it is time to use the NIO connector as the default one
in Tomcat 7.

Best regards,
Konstantin Kolinko

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