Jeanfrancois Arcand wrote:
> charlie hunt wrote:
>> If a change in configuration shows a significant change in Grizzly's
>> performance, then I think we have a bug, i.e. an "out of the box"
>> configuration bug.
>>
> Right now the only way to configure grizzly properly is by properly
> calling the SelectorThread.setXXX...since documentation is quite bad,
> it is easy to forget to call one method and get bad results :-)
> Documentation will helps a lot :-)
Documentation is good. But, IMO, I think we need to set the bar higher. :-)
There will (still) be people who will not look at documentation and
(potentially) do comparisons against a non-optimally configured grizzly.
When / if we get "transport configuration" integrated into grizzly, we
should consider improving the "out of the box" performance for grizzly.
I think we could integrate some ergonomics into that "transport
configuration" based on what we see as the underlying operating system.
We could also add the ability to "hint" at the runtime desired, i.e.
desktop development, qualification environment, multiplexed protocol,
simplex protocol, etc.
Looks like we have more enhancements for version 2.0 ;-)
charlie ...
>
> A+
>
> -- Jeanfrancois
>
>
>> charlie ...
>>
>> Jeanfrancois Arcand wrote:
>>> http://weblogs.java.net/blog/forax/archive/2008/02/sorry_but_ive_t.html
>>>
>>> I would think he should post its configuration :-) But that's good
>>> publicity for us anyway :-)
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
--
Charlie Hunt
Java Performance Engineer
<http://java.sun.com/docs/performance/>