tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: BIO performance issues
Date Wed, 04 May 2011 11:04:47 GMT
2011/5/4 Mark Thomas <markt@apache.org>:

> Time: 2s
> Activity: Group B clients connect and are added to the queue
>          100 threads are allocated to process the B connections
>          The B connections are processed and returned to the queue
>          100 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
>          A connections send requests
>          A connections are processed and returned to the queue
>          C connections are processed and returned to the queue
>          D connections are processed and returned to the queue
>          E connections are processed and returned to the queue
>          F connections are processed and returned to the queue
>          A connections are allocated threads but are in keep-alive
> 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 >= 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


Mime
View raw message