Tomcat BIO connector configurations ignored?

[Ionut Barau]

Hello,

I am trying to make some performance test on our application deployed on Tomcat 7. I have played around with connector configurations but I am under the impression that some of them are ignored. The connector is HTTP BIO.

I am using JMeter for performance testing, and my scenario is to test with simultaneous users. After reading Tomcat documentation I started playing with maxThreads, maxConnections, acceptCount and connectionTimeout.

From my understanding, in case of BIO connector, maxThreads value = maxConnections value (if you don't set them both specifically), so essentially there is a 1 to 1 relationship between thread and connection. AcceptCount is the queue length of incoming requests (the requests are stacked up until the number of connections is lower than maxConnections ). ConnectionTimeout represents the number of milliseconds taken until the request is presented to the server.

Take for example the following configuration :

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="1" redirectPort="8443" maxThreads="2"/>


I have tested with 20 simultaneous users in JMeter (ramp-up period of 0 seconds so they can be simultaneous). I expect based on my understanding that all 20 users will get "Connection Refused error", but they all succeed.
I have be playing for 2 weeks now and I am confused... Is connectionTimeout ignored in this case, or is my understanding poor ?

Thanks,
Ionut

[Tim Holloway]

Actually, we discussed something similar a month or 2 ago, so you might want to search the forum for that thread. Essentially, however, you CAN have more connections than threads. It's just that once all threads are allocated, the subsequent connectors are queued up up to the maxConnections limit, after which point they simply bounce.

[Ionut Barau]

I've read the post. Probably this is the one : https://coderanch.com/t/517692/Tomcat/understanding-connector-attributes. However it does not answer my question. My current problem is that the connectionTimeout parameter is not taken into account. I have set it at 1 millisecond, so no request should be processed from my understanding. I have played a lot with those other parameters that I mentioned but still the behavior is strange. I had maxThreads set to 100 and acceptCount to 100. I tested with 250 users simultaneous, and I expected that at least 50 users get a connection refused. But they all passed.

The problems mentioned in the existing post that I read, are happening to me also. But I am trying to figure it out one at a time. acceptCount did not work for me either., but i am expecting at least connectionTimeout to work. The Tomcat documentation seems to be wrong. I also had a problem for creating a datasource in Tomcat. In documentation they wrote that we should add the "username" attribute, but it is actually just "user" ... (PS. I tried chaning the attribute names for connector in lowercase but did not work...)

Thanks

[Tim Holloway]

To suppress queueing of requests, the timeout isn't 1, it's -1. Which is to say, an impossible value.

I posted my original thread using the Tomcat 6 docs. I notice that Tomcat 7 has confused/complicated and possibly garbled this information.

One thing that might help is if you use an appropriate tool to inspect the Connector's MBean and thereby see what the actual end product of the configuration options came out as.

[Ionut Barau]

I realize that there might some problems on how I use JMeter.
I will use JConsole and post a reply afterwards.

Thanks a lot !

[Ionut Barau]

OK, so i found out that i didn't fully understand how Tomcat is handling the request <> response mechanism.
I connected with JConsole, and saw that the parameters have the values that I have provided in xml, so I assume they are taken into account.

I'm posting now my understanding of how Tomcat handles requests in regards with the configuration parameters. Please correct me if I am wrong

What I understood :

connectionTimeot = how long does the server wait, after accepting a connection, for the request to be presented
keepAliveTimeout = how long is the connection kept open, waiting for subsequent requests from the same client. (Do not confuse with session timeout)
acceptCount = represents a queue where new connections are stored, when the "maxConnections" value is reached
maxConnections = the maximum number of simultaneous opened connections
maxThreads = the maximum number of simultaneous threads . (in case of BIO, each thread is tied to one connection, and processes requests from that single connection)


In BIO connector, there is thread per connection paradigm, not thread per request like in NIO or APR.
If the time taken until the request is presented to the server exceeds connectionTimeout value, the user receives an error.
A connection is kept open for the duration of keepAliveTimeout value

What happens during the request <> response mechanism with BIO connector?

The user initiates a request by clicking a button/link or typing and address in browser
The server checks if this client has an already opened connection.
If it has an opened connection (meaning that this is not the first request), then the connection will have access to a thread and will present it's request > the request will be processed > the user receives in turn a response
If it does not have a connection opened, the server will try to create a new connection.

The creation of a new connection is successful if
1)the maxConnections value is not reached - the connection has access to a thread and will present it's request > the request will be processed > the user receives in turn a response
2)there is still room in the acceptCount queue - the connection will be created, but it's request won't be processed until the server has a free thread, or it reaches the connectionTimeout value (user receives an error)

The creation of a new connection will not be successful if both maxConnections value has been reached and acceptCount value has been reached. The user will receive a "Connection refused" error.

Hopefully my explanation is clear...

Thanks,
Ionut

[Tim Holloway]

Thank you for your research and for publishing your findings. Have a cow!

Here's some info that may help you understand keepalive.

HTTP as originally designed was a stateless in-and-out protocol. One request/one response, that's it. Each request/response cycle is self-contained, unlike traditional "time-sharing" or other client-server sessions (such as CORBA).

However, it's not a trivial thing to open up a connection, determine an Internet route and all the related overhead so the concept of "keep-alive" was formulated. Essentially, you keep an open connection while pretending that you didn't. That way, if you have a series of requests, you don't have to start each one from scratch. However, since it's actually just transparently piggybacked on the HTTP protocols, there's no formal HTTP "close connection" command nor is it desirable to hold onto the connection for extended periods of silence. So the keep-alive timeout ensures that connections are reclaimed without having to code the process explicitly into HTTP.

[Ionut Barau]

Thanks for the cow !

I am posting some updates after further testing with JMeter.

It seems that whatever value you put in acceptCount, it is ignored. I found some threads where other users complained about this. If you run netstat -anp | grep 8080 on a linux machine you will see a lot of waiting tcp connections.
It comes down to the OS how many connections it can keep on hold.

Further more, I found out that once a connection is in acceptCount queue, the connectionTimeout value will not affect the lifetime. What will happen is the connection will be put on idle state until a thread is ready to process it's request. If the time taken to respond to the request is higher than the browser's requestTimeout setting, the user will get an error.


Hope it helps somebody else trying to understand this.

Thanks,
Ionut