Hi Vicenc,
sorry for the delay.....
Vicenc Beltran Querol wrote:
> Hi,
>
> attached you'll find a patch for Grizzly, that changes the coyote multithreading
> model to a "hybrid" threading model (NIO+Mulithread). It's fully
> compatible with the existing Catalina code and is SSL enabled.
>
> Like Grizzly, the Hybrid model breaks the limitation of one thread per connection,
> thus you can have a higher number of concurrent users with a lower number of threads.
> NIO selectors are utilized to detect when a user connection becomes active
> ( i.e. there is a user http request available to be read), and then, one thread
> processes the connection as usual, but without blocking on the read() operation
> because we know that there is one available request.
This is quite impressive. I took a closer look at your implementation
and I see it looks promising for implementing SSL non blocking. For
normal HTTP processing, it seems a pure non blocking approach perform
better (using a benchmark that measure both scalability and throughput
simultaneously). With only 20 threads, Grizzly perform better than any
WebContainer. Grizzly only creates 20 Processor (the number of thread)
and also supports keep-alive using the SelectionKey (which might explain
why it perform better) instead of an internal object (in Coyote, the
Processor is keeping tack of the keep-alive count, which under high load
consume memory and because InternalInputBuffer creates 3 bytes array,
produces an OutOfMemory error.
But before saying Grizzly is better than yours, I would like to
integrate your work directly into Grizzly instead of Coyote, because
your patch cannot re-use the Pipeline/Multi Read selector implementation
Grizzly is using.
The steps would be to define an AcceptBlockingReadTask and a
ReadBlockingRead classes (OK I'm bad with name :-)) and port your Coyote
implementation. I suspect performance will improve by just having those
classes.
What do you think? I'm in the process of implementing SSL non blocking,
and I think the first logical steps will be to re-use what you have done
instead of starting from scratch (quite dangerous in term of stability).
Once we have your Grizzly implementation, we can decide if we want to
add a property to http-listener to allow use to switch mode based on
their environment (I suspect you approach will perform very well on a
single processor).
Thanks
-- Jeanfrancois
>
>
> The Hybrid model eliminates the need to close inactive connections (especially
> important under high load or SSL load) and reduces the number of necessary threads.
>
> The major difference between Grizzly and Hybrid approaches is that Grizzly does
> the read of the request in non-blocking mode so it can deal with lot of large uploads,
> but the Hybrid supports SSL connections.
>
>
>
> To enable the hybrid implementation add the following "jvm-option":
>
> ./glassfish/domains/domain1/config/domain.xml
> <java-config ...
> ...
> <jvm-options>-Dcom.sun.enterprise.web.connector.useHybridConnector=true</jvm-options>
> ...
> </java-config>
>
>
> Best Regards,
>
> Vicenç Beltran
>
> eDragon Research Group
> Barcelona Supercomputing Center (BSC)
> http://www.bsc.es/edragon
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net