tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Fisk <af...@limepeer.com>
Subject Re: 5.next + 4.1.x future
Date Fri, 12 Dec 2003 22:31:25 GMT
Here's my excel spreadsheet.  All of these numbers are taken from the 
Windows Task Manager.  This is somewhat misleading in that the memory 
numbers don't properly reflect garbage collection, but it's informative 
nevertheless.

The "Sends (ms)" column reflects the timeout between client sends.  I 
originally intended to run these tests for many timeouts, but this 
became prohibitively annoying over the WAN.  These tests were done with 
all clients running on a single machine connecting to the servers over 
the WAN.

Thanks.

-Adam


Jeanfrancois Arcand wrote:

> 
> 
> Adam Fisk wrote:
> 
>> Just to chime in on the NIO issue, I agree that it's not immediately 
>> obvious what the performance benefits are.  Perhaps more importantly, 
>> though, the code changes to switch Tomcat (or any other good-size app) 
>> to NIO are tremendous -- basically a rewrite of the hard parts.
>>
>> That said, I've done simple tests of NIO vs. blocking IO on Windows 
>> using simple blocking and non-blocking servers with variable numbers 
>> of client connections (from 100 to 10,000).  At least on Windows, the 
>> performance benefits come down to memory allocated to threads.  My 
>> blocking server used one send thread and one receive thread per 
>> connection (no thread pooling).  Given the memory allocations per 
>> thread, though, the blocking server with 1600 connections used 137MB 
>> whereas the NIO server used 11MB, almost exactly the same as the 
>> memory use with 50 connections.
>>
>> I'd be happy to send my data to the group if people are interested. 
> 
> 
> Yes, I will be very interested to see those numbers.
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> 
>> Aside from memory, I was surprised to find that the effect on CPU was 
>> negligible (not much of a benefit from no context-switching between 
>> threads) -- CPU was virtually the same in both cases.  So, the scaling 
>> benefits on Windows basically come from not having to allocate more 
>> memory to new threads.  I'm unfortunately not as familiar with the 
>> Tomcat code as I'd like to be, but I assume it makes intelligent use 
>> of thread pooling, which may even the memory benefits of NIO 
>> negligible. At the same time, though, NIO may remove some of the 
>> constraints introduced by thread pooling, possibly allowing Tomcat to 
>> handle heavier loads without blowing up.  An optimized NIO server 
>> would if anything out-perform a blocking server, but maybe by not that 
>> much.
>>
>> -Adam
>>
>>
>> Remy Maucherat wrote:
>>
>>> Jan-Henrik Haukeland wrote:
>>>
>>>> Remy Maucherat <remm@apache.org> writes:
>>>>
>>>>> My opinion is that NIO is going to be really useless.
>>>>
>>>>
>>>>
>>>>
>>>> Eh, hello!? Oh, okay if it's not important that Tomcat scale and
>>>> perform well it may be useless. But, really, before NIO it was
>>>> hopeless to try and write a scalable and fast tcp server application
>>>> in Java. Tomcat's current connection handling with blocing all over
>>>> the place and "thundering herd" problem doesn't scale or work very
>>>> well under heavy load.
>>>
>>>
>>>
>>>
>>> You apparently have a very strong opinion on this, and that's fine. 
>>> You also obviously don't know what you are talking about. The purpose 
>>> of Tomcat is to make the web tier of an application server (Tomcat is 
>>> actually a mini application server), not some kind of non blocking 
>>> I/O toolkit to be used to build fixed function servers. Non blocking 
>>> I/O has great applications, and is a very useful technology, but it 
>>> does not apply to the application server world.
>>>
>>> I think you should find a servlet container which has NIO, compare 
>>> with Tomcat 5.0.16, and come back to report your findings about how 
>>> much scalability or speed NIO brings (note: doing the non blocking 
>>> socket handling in a native layer doesn't really count, since it's 
>>> not a fair comparison with Java's NIO; you might as well use Apache).
>>>
>>> Bring facts, not useless rants.
>>>
>>> Rémy
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>> .
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> .
> 

Mime
View raw message