dev@grizzly.java.net

Re: Some benchmarks ...

From: Emmanuel Lecharny <elecharny_at_gmail.com>
Date: Tue, 07 Oct 2008 01:14:21 +0200

Trustin Lee (이희승) wrote:
>>> It's a little bit annoying that Trustin didn't named the frameworks.
>>
>> Yes :-)
>
> Performance test report is always annoying to some extent, regardless
> of if the name of the frameworks were open or not.
So either you do some benchmark, and you do it providing all the needed
informations, or you don't. I don't see any problem in giving the names
when it comes to OSS project. And I don't see how annoying it can be.
> It's JBoss policy to anonymize the names of competitive technologies.
This is a stupid policy, when it comes to OSS projects. It's pretty
understandable in the WebApp biz, as oracle, Sun and some other big
players forbid you to do some benchs, but this is not the case here.
> On top of that, any performance test can contain some mistakes, and I
> don't want a certain framework gets hurt by my (potentially serious)
> mistake.
Again, either you are confident that your bench is ok, and you provide
the names, or you don't. Of course you will have mistakes in your
benchmarks, but that's not such a big deal. By publishing a benchmark
without providing the names, you are basically telling the world :"Hey,
look : my product is the fastest ! Don't bother use any other !".
>
>>> However, I think that could be interesting to build some valid set
>>> of benchmarks demonstrating different real life scenarii, helping us
>>> to improve the code.
>> I agree we should have something :-) Note that Trustin, when
>> "re-creating" Netty, has the freedom to innovate and change any API
>> he want. Something (at least with Grizzly) we can't do if we don't
>> want to upset all our users.
>
> Eventually, all NIO frameworks should have better performance than
> they have now, and I believe any sort of automated benchmark will help
> us somehow.
Very true. I think that what you have build is a very good base. What
would be interesting is to define some common use case scenarios, like
handling Http requests, or XMPP messages. IMHO, HTTP requests should be
the next target, in this <becnhmark> :)

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org