Salut,
Niall Gallagher wrote:
> Hi,
>
> In response to your comments.
>
>> I have to admit ab benchmark are not something I usually
>> like:
>>
>> http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
>>
>> Also you just set the WorkerThread to 5 :-) How many thread
>> are you configuring with your framework? I would also like
>> to see the server and ab logs to see what is the issue.
>> Which JDK/OS are you running on? What kind of network. And
>> more important, what you framework offer in terms of http
>> :-)
>
> Thanks, this is what I have been looking for.
>
> I have 5 servicing threads also, but I use an event distributor (based on the proactor pattern) which also uses 5 threads to distribute select events (both read and write). So, basically I would like the optimal Grizzly configuration. Because comparing the two based on thread count is not going to be fair as both have very different architectures.
>
I see. You might want to turn on that functionality as well on Grizzly
by setting:
SelectorThread.setSelectorRedThreadCount(5);
It may makes a difference.
Have you committed your Grizzly main somewhere so I can take a look?
> I am running on an Intel core 2 duo running linux kernel 2.6.27. Using suns JDK 1.5.
>
> My framework offers the full set of HTTP/1.1 features including.
>
> 1) asynchronous write support, similar to what grizzly 1.9 introduced, however I use fixed segment sizes rather than cloning
> 2) asynchronous execute support, as in read and write can be done on separate threads, or dispatched to any other thread of execution,
> similar but more transparent to Servlet 3.0 proposals, so read/write/execute can all be done in parallel
> 3) HTTP and HTTPS support
> 4) 100 continue
> 5) integrated multipart support including nested multipart lists
> 6) its NIO throughout but offers BIO semantics via an output stream or writable byte channel on the response
> 7) Internal file system to manage massive file uploads without blocking or exhausting memory
> 8) Leased sessions
> 9) No external depandancies, so is extremely light weight
:-) I agree this is impressive.
>
>> Well most probably yes :-) But your goal is to claims your
>> framework is faster than Grizzly, right?
>
> Well, in a way yes. But more importantly I want to get an accurate picture of how it compares to other NIO servers. I've only done comprehensive benchmarks on Jetty and AsyncWeb because Grizzly 1.8.x kept dropping connections for some reason,
Really? I'm not aware of such issues. I saw your benchmark against
Jetty. Did you talked with Greg W. about it? I suspect Jetty is not
properly configured... Anyway, back to Grizzly.
1.9.x has been very robust so far. Simple beats Jetty by about 60% and
AsyncWeb by about the same.
AsyncWeb is almost dead so I would not compare to it. The MINA community
is working on 2.0 right now and AsyncWeb support/improvement are
almost inexistant. Watch the Netty's http implementation...that one is
"dangerous" :-) :-)
>
>> A lot of framework
>> did that as well, but at the end it is always quite easy to
>> run something different (like Faban above) and demonstrate
>> the contrary :-) Anyway, I'm interested helping and see
>> how it goes :-)
>
> I have run a number of load testers, and have found ab is useful for a number of reasons. Importantly for NIO servers its very good at scattering load, and so causes a signifigant number of select interrupts. Some other frameworks just fill the socket with the whole scenario, and so does not reflect a real traffic profile.
Agree. But ab is not reflecting the reality IMO. You should really try
Faban and see what you are getting.
A+
-- Jeanfrancois
>
> Niall
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>