2011/5/4 Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
