Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45E59E44.106@hanik.com>
Date: Wed, 28 Feb 2007 08:22:44 -0700
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: org.apache.catalina.util.InstanceSupport.fireInstanceEvent
References: <200702221217.16381.dpospisi@redhat.com>
 <45DD8ADD.6040801@apache.org> <200702281152.31509.dpospisi@redhat.com>
In-Reply-To: <200702281152.31509.dpospisi@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Dominik Pospisil wrote:
>> Dominik Pospisil wrote:
>>     
>>> So I am thinking if this could not be the problem. Is is necessary to be
>>> this implementation synchronized?
>>>       
>> Given the implementation, you are not supposed to be using instance
>> listeners at this time except for debugging purposes.
>>
>> Since InstanceSupport is array based, I don't see the point of the
>> sync+clone which happens in there.
>>
>> R�my
>>     
>
> R�my,
>
> thanks for fixing that issue. In my test I can see ~30% improvement in number 
> of concurrent sessions correctly served by single Tomcat instance. But still 
> it did not solved it completely.
>
> My idea is, that if there are enough memory and IO resources, Tomcat will be 
> able to handle all the clients "equally". So if there are clients which 
> produce equal constant load they should be served all and with the same 
> average response times. Do you think that it is achievable?
>
> The question is what should "equally" exactly mean. I know that in real 
> scenario there are various clients with different connections and injection 
> rates so just a simple FIFO rule would not be sufficient. Moreover, I am new 
> to Tomcat internals and at this point I have no idea of how it should work at 
> all.
>
> But what about general idea of having some scheduler which will somehow 
> control thread execution? Is it good idea or something completely wrong?
>   
there is no scheduler in tomcat, but the same logic has been implemented.
For example, connections are simply handled in the order they are 
accepted, for the blocking connector.
On the regular connector, the notion of a scheduler is obsolete since 
you will never have more connections than you have threads,
so its up to the operating system's scheduler to determine how threads 
are swapped onto the CPU.

For the Tomcat APR connector, the same as above, when a socket is 
accepted, the acceptor blocks until a thread is available to process the 
request.
For keep alive connections, when invoking the poll() events, the 
connections will be handled in that exact order.
The APR poller blocks for an available worker thread.

The Tomcat 6 NIO connector works a little bit differently. Upon 
accepting a connection, the NIO acceptor doesn't block for an available 
worker thread,
instead it registers it with the poller. The idea behind this is, when a 
socket is accepted, doesn't mean there is data to be read, hence no need 
to block a thread.
Also, the NIO poller never blocks, if there is a socket ready for read, 
but no worker threads are available, the poller simply processes other 
events, and when
a thread is available, the socket gets handed off at that time.

So in these three scenarios, the only implementation that doesn't follow 
a strict first-come-first-serve scenario is the NIO implementation.

in a recent test, with 12k concurrent connections, it seems that the 
equality is very good, example results below.

Let me know if you have any more questions.
Filip


Server Software:        Apache-Coyote/1.1
Server Hostname:        testhost
Server Port:            8080

Document Path:          /load/bd?size=64
Document Length:        65536 bytes

Concurrency Level:      12000
Time taken for tests:   290.520087 seconds
Complete requests:      1200000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    1200000
Total transferred:      78958306058 bytes
HTML transferred:       78771832843 bytes
Requests per second:    4130.52 [#/sec] (mean)
Time per request:       2905.201 [ms] (mean)
Time per request:       0.242 [ms] (mean, across all concurrent requests)
Transfer rate:          265412.72 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   80 1342.3      0   93017
Processing:   523 2804 955.4   2510    9082
Waiting:      161 2382 957.0   2099    8186
Total:        523 2884 1739.6   2513  100406

Percentage of the requests served within a certain time (ms)
  50%   2513
  66%   2693
  75%   2825
  80%   3659
  90%   4521
  95%   4946
  98%   5325
  99%   6050
 100%  100406 (longest request)

> Thanks for any comments,
>
> Dominik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org