tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote
Date Fri, 20 May 2005 14:53:32 GMT

----- Original Message ----- 
From: "Jeanfrancois Arcand" <jfarcand@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sent: Friday, May 20, 2005 6:56 AM
Subject: Re: Hybrid (NIO+Multithread, SSL enabled) architecture for Coyote


>
>
> Mladen Turk wrote:
>> Vicenc Beltran Querol wrote:
>>
>>> Hi guys,
>>>
>>> I'm not trying to be a Tomcat developer. I'm working on my PhD on web 
>>> performance and just decided to share with you the experimental code 
>>> I've developed after studying the performance obtained ;).
>>>
>>
>> I've done some serious testings with HTTP server and NIO.
>> The results were always bad for NIO.
>> Blocking I/O is minimum 25% faster then NIO.
>
> Faster in what? Throughput and/or scalability?
>
> I disagree ;-) I would like to see your implementation, because from what 
> I'm seeing/measuring, it is completely the inverse. I would be interested 
> to see how you did implement your NIO connector. The problem

> with HTTP is not NIO, but the strategy to use for predicting if you have 
> read all the bytes or not. Falling to implement a good strategy will ends 
> up parsing the bytes many times, calling the Selector.wakeup() too often, 
> thus poor performance. The way you register your SelectionKey is also very 
> important.


Yeah, the speed improvement with NIO is the only thing that makes 
ChannelNioSocket not a total PoC.  It's really depressing that any JVM 
vendor would allow such a huge performance difference between 
Socket.getOutputStream().write and SocketChannel.write.


>
> Also, blocking IO required 1 thread per connection, which doesn't scale 
> very well. That's why I think the new APR connector is interesting, since 
> it fix that problem. But even if with APR, you did workaround the JNI 
> bottleneck by using direct byte buffer, I suspect a pure NIO 
> implementation will perform better than APR (except for static resource) 
> just because of the C->Java overhead. But I don't have yet numbers to 
> show...come to my session at JavaOne, I will :-)
>
>>
>> You may tray that simply by using demo HTTP servers
>> Blocking/Blocking Pool/NIO single thread/NIO multiple threads
>> that comes with new Java6 (see java.net for sources).
>
> Right. This is actually a good example not to follow ;-).
>
> BTW the big patch use NIO blocking, which may improve scalability, but 
> will impact throughput. The patch should be improved to use NIO 
> non-blocking. And then we can compare ;-)
>
> -- Jeanfrancois
>
>>
>>
>> OTOH, I'm sure you must have some performance results :)
>> Simply run the 'ab -n 100000 -c 100 -k host:8080/tomcat.gif'
>> with your patch and standard Tomcat5.5.9.
>>
>>
>>> Anyway, it's OK. I'll work on the new patch and resubmit it.
>>
>>
>> Great.
>>
>> Regards,
>> Mladen.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> 



This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.



Mime
View raw message