Hi,
Thanks, I am currently running tests with Faban, any config suggestions would be appreciated.
Here is the config I am going to start with. If you have any suggestions on how to configure this better, great. For now I am going to start with a simple single resource test.
Niall
--- On Mon, 2/2/09, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM> wrote:
> From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
> Subject: Re: Grizzly Strategies
> To: dev_at_grizzly.dev.java.net
> Date: Monday, February 2, 2009, 10:56 AM
> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail:
> dev-help_at_grizzly.dev.java.net