On 07/09/17 23:30, Yasser Zamani wrote:
> Thanks for your attention.
> Now I downloaded a fresh apache-tomcat-7.0.81-windows-x64 and chenged 
> it's connector in same way (BIO,20,20,10). I get same result, fortunately :)
> "C:\Users\user\.IntelliJIdea2016.3\system\tomcat\Unnamed_Async-Servlet-Example_2"
> "C:\Users\user\Downloads\apache-tomcat-7.0.81-windows-x64-IJ\apache-tomcat-7.0.81"
> "C:\Users\user\Downloads\apache-tomcat-7.0.81-windows-x64-IJ\apache-tomcat-7.0.81\temp"
> Using JRE_HOME:        "E:\jdk1.7.0_79"
> INFO: Server version:        Apache Tomcat/7.0.81
> INFO: Server built:          Aug 11 2017 10:21:27 UTC
> INFO: Server number:
> INFO: OS Name:               Windows 8.1
> INFO: OS Version:            6.3
> INFO: Architecture:          amd64
> INFO: Java Home:             E:\jdk1.7.0_79\jre
> INFO: JVM Version:           1.7.0_79-b15
> INFO: JVM Vendor:            Oracle Corporation
> C:\Users\user\.IntelliJIdea2016.3\system\tomcat\Unnamed_Async-Servlet-Example_2
> Container MAX used threads: 10

I see similar results.

There looks to be things going on either in JMeter or at the network
level I don't understand. I had to resort to drawing it out to get my
head around what is happening.

The first 20 requests (10 seconds) are accepted and processed by Tomcat.
The 21st request is accepted but then the acceptor blocks waiting for
the connection count to reduce below 20 before proceeding.

Requests 22 to 31 are placed in the accept queue. We are now 15.5s into
the test and the first request accepted won't finish processing for
another 4.5 seconds.

Requests 32 to 40 are dropped since the request queue is full. We are
now 20s into the test and the first request is about to complete
processing. Oddly, JMeter doesn't report these as failed until some 35
seconds later.

Request 1 completes. This allows request 21 to proceed. The acceptor
takes a connection from the accept queue (this appears to be FIFO).
Request 41 enters the accept queue.

The continues until request 10 completes, 30 starts processing and 50
enters the accept queue.

Next 11 completes, 41 starts processing and 51 enters the accept queue.
This continues until 20 completes, 50 starts processing and 60 enters
the accept queue.

At this point there are 20 threads processing, 10 in the accept queue
and no thread due to complete for anther 10s.

I'd expected requests 61 to 70 to be rejected. However, 65 to 70 are
processed. It looks like there is some sort of timeout for acceptance or
rejection in the accept queue.

That explains the rejected requests.

The other question is why maxThreads is reported as it is.

The answer is that the thread pool never grows beyond its initial size
of 10. A request comes in, it is processed by a container thread,
dispatched to an async thread and then the container thread is returned
to the pool to await the next request. Tomcat is able to do this because
the container doesn't perform any I/O on the connection once it enters
async mode until it is dispatched back to the container. The default
thread pool implementation cycles through the threads so the max value
you see is 10 which is the initial size.



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to