Salut,
Niall Gallagher wrote:
> 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.
This is the part I don't like to be honest. You seems to want to make
noise on others :-) I don't think this is a good way to build a
community :-) Anyway just push the code/result out and once I get a
chance I will take a look at how you configured the monster.
>
> 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?
Just do what you think is right :-)
A+
-- Jeanfrancois
>
> 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
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net