You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2009/03/06 03:06:17 UTC
Re: nio connector configuration
hi Peter,
I ran your jmeter test and I get an average request time for Comet to be
13.5 seconds.
I'm running this on what will be 6.0.19, meaning 6.0.x/trunk
With a 10second timeout, you wont get timed out in exactly 10 seconds.
timeout are of absolutely lowest priority.
If there is request data coming in for the poller, then that will get a
preference. Timeouts happen when the poller thread is free, and the time
has passed.
But 13.5 sounds pretty reasonable in this case
Filip
otismo wrote:
> Thanks for the response, Filip. Hopefully this is more helpful...
>
> I put a war at http://www.nomad.org/test.war containing my web app, the
> source, and my jmeter test plan.
>
> My question: why are comet timeouts getting generated substantially behind
> the timeout setting?
>
> Is it because I have incorrectly configured tomcat? Is there something
> wrong with my test? Can anyone else confirm this behavior?
>
> It seems as though the normal (non-comet) http requests are taking priority
> over the comet requests.
>
> The test is very simple. One set of threads sends non-comet http requests
> every 10 seconds. Another set of threads sends comet requests with a single
> byte in the body. The comet servlet sets a comet timeout of 10 seconds,
> reads the request body, and then closes the connection on receiving the
> comet timeout event. On close of the connection, the comet test threads
> then send another comet request.
>
> I have JMeter set to start 100 threads for the http thread group and 100
> threads for the comet thread group, ramping up at 1 thread per second.
>
> A fifteen minute test shows:
> http requests: 9750 samples
> http response time: avg 109ms, min 66ms, max 3699ms
> http errors: 0%
> http throughput: 9.5 requests/second
> comet requests: 1942 samples
> comet response time: avg 50149ms, min 10353ms, max 120876ms (tcp timeout is
> set to 120000)
> comet errors: 0%
> comet throughput: 1.9 requests/second
> cpu use is minimal (1-4%)
>
> There are no errors in the catalina log.
>
> I also added timing code to the test servlet to confirm that JMeter's
> measurements are accurate and found they are. After confirming the
> measurements, I removed the timing code.
>
> I noticed on even short tests the http requests predominate, even though
> there should be roughly the same # of http requests as comet requests (1
> request/10 seconds/thread and there are 100 threads for each thread group,
> http and comet).
>
> My NIO configuration is:
> <Connector port="80"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="1000"
> acceptorThreadCount="2"
> acceptorThreadPriority="10"
> pollerThreadCount="2"
> pollerThreadPriority="10"
> redirectPort="8443"
> enableLookups="false" />
>
> os: ubuntu 8.10 (although also observed same behavior on Windows XP SP 3)
> tomcat 6.0.18
>
> (Note: the following are also in the war bundle referenced at top)
> The client TCP request looks like this (without the ####s):
> ####
> POST /test/cometTest HTTP/1.1
> Host: 173.45.237.215
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2)
> Gecko/20081201 Firefox/3.1b2
> Connection: keep-alive
> Content-Type: text/plain
> Content-Length: 1
>
> 5
> ####
>
> The http test servlet's doGet method looks like this:
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws IOException {
> response.getWriter().println("response");
> }
>
> The comet test servlet's event method looks like this:
> public void event(CometEvent event) throws IOException, ServletException
> {
> HttpServletRequest request = event.getHttpServletRequest();
> if (event.getEventType() == CometEvent.EventType.BEGIN) {
> event.setTimeout(10000);
> } else if (event.getEventType() == CometEvent.EventType.ERROR) {
> event.close();
> } else if (event.getEventType() == CometEvent.EventType.END) {
> event.close();
> } else if (event.getEventType() == CometEvent.EventType.READ) {
> InputStream is = request.getInputStream();
> byte[] buf = new byte[512];
> do {
> is.read(buf);
> } while (is.available() > 0);
> }
> }
>
> Thanks for any help,
> Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: nio connector configuration
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
otismo wrote:
> Thanks for checking it out, Filip.
>
>
>> I'm running this on what will be 6.0.19, meaning 6.0.x/trunk
>>
>
> Yes, running from the trunk yields very different #s. Looking into it more,
> 6.0.18 didn't honor the pollerThreadCount setting.
>
> results (all tests were run for around 3000 samples):
> 6.0.18:
> with 2 acceptors and 2 pollers set (really only 1 poller was used because
> 6.0.18 didn't honor the poller setting):
> avg 20s, min 10s, max 60s
>
> 6.0.19:
> 2 acceptors, 2 pollers:
> avg 15s, min 10s, max 32s
>
> 10 acceptors, 10 pollers:
> avg 13s, min 10s, max 53s
>
> 50 acceptors, 50 pollers:
> avg 11s, min 10s, max 27s
>
> 1 acceptor, 50 pollers:
> avg 11s, min 10s, max 32s
>
> So it seems that in my app, where timely timeouts are important, raising the
> number of pollers helps.
>
actually, instead of changing poller count, try to reduce the
selectorTimeout="50", set it to 50ms
default is one second.
>
>> Timeouts happen when the poller thread is free, and the time has passed.
>>
>
> Ok, so the results above make sense because having more poller threads will
> increase the likelihood that one will be free and that my timeout will get
> serviced more quickly.
>
> What I don't understand is the connection between non-comet http requests
> and comet requests. Running the same test above, without the non-comet http
> requests (setting the # of threads in the HttpTest thread group to 0, and
> upping the comet threads to 200) on 6.0.18 I get:
> avg 10.3s, min 10.0s, max 13s
>
> A non-comet request shouldn't be tying up a poller thread, should it? So
> why would non-comet requests delay the delivery of comet timeouts?
>
no it doesn't, but here is the logic
when the poller thread wakes up from a select(), it checks to see if
were any events, or if the select timed out
if there were no events, and select() timed out, then it checks comet
connections for their timeout status.
You see, checking timeout means the poller spends cpu cycles not
polling, and that can affect other running connections.
so a timeout is a lower priority.
but reducing selectorTimeout, should yield very different values
> Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: nio connector configuration
Posted by otismo <pe...@nomad.org>.
Thanks for checking it out, Filip.
> I'm running this on what will be 6.0.19, meaning 6.0.x/trunk
Yes, running from the trunk yields very different #s. Looking into it more,
6.0.18 didn't honor the pollerThreadCount setting.
results (all tests were run for around 3000 samples):
6.0.18:
with 2 acceptors and 2 pollers set (really only 1 poller was used because
6.0.18 didn't honor the poller setting):
avg 20s, min 10s, max 60s
6.0.19:
2 acceptors, 2 pollers:
avg 15s, min 10s, max 32s
10 acceptors, 10 pollers:
avg 13s, min 10s, max 53s
50 acceptors, 50 pollers:
avg 11s, min 10s, max 27s
1 acceptor, 50 pollers:
avg 11s, min 10s, max 32s
So it seems that in my app, where timely timeouts are important, raising the
number of pollers helps.
> Timeouts happen when the poller thread is free, and the time has passed.
Ok, so the results above make sense because having more poller threads will
increase the likelihood that one will be free and that my timeout will get
serviced more quickly.
What I don't understand is the connection between non-comet http requests
and comet requests. Running the same test above, without the non-comet http
requests (setting the # of threads in the HttpTest thread group to 0, and
upping the comet threads to 200) on 6.0.18 I get:
avg 10.3s, min 10.0s, max 13s
A non-comet request shouldn't be tying up a poller thread, should it? So
why would non-comet requests delay the delivery of comet timeouts?
Peter
--
View this message in context: http://www.nabble.com/nio-connector-configuration-tp21969270p22378593.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org