Hi,
So from Apache Bench to Faban to JDK 6, Simple 4.1.3 is still almost twice as fast as Grizzly 1.9.3. Any more excuses (joke) :)
Referring to an earlier comment, many servers claim to be faster than Grizzly and turn out not to be. However I think its all but proven Simple is much faster and more scalable than Grizzly. Perform the tests yourself and see...Ill provide the code and test harness.
I have attached the latest Faban reports, increasing the number of concurrent users to 250. I see the following:
Simple:
<metric unit="ops/sec">7436.633</metric>
Grizzly:
<metric unit="ops/sec">4732.775</metric>
Any comments?
Regards,
Niall
--- On Tue, 2/3/09, charlie hunt <charlie.hunt_at_sun.com> wrote:
> From: charlie hunt <charlie.hunt_at_sun.com>
> Subject: Re: Grizzly Strategies
> To: dev_at_grizzly.dev.java.net
> Date: Tuesday, February 3, 2009, 5:38 AM
> > Using sun's JDK 1.5.
>
> Please use the latest JDK 6 versions. The performance
> differences
> between Java 6 JVMs and JDK 1.5 JVMs is very, very
> different
> (impressive). Whenever I see a perf test comparisons using
> JDK 1.5 I
> immediately lose interest. By technology standards, JDK 1.5
> is very old,
> nearly obsolete.
>
> I think if you update to latest Java 6 versions, you'll
> be very happy
> with its performance.
>
> charlie ...
>
> 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 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
> >
> >
> >> 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, 1.9.x has been very robust so far. Simple beats
> Jetty by about 60% and AsyncWeb by about the same.
> >
> >
> >> 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.
> >
> > 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