> If those tests are automatable (if not, let's get 'em that way)
> let's set up a hudson job so we can track it and catch things quickly.
Theoretically they are. You can take a look at 2dot0 module called
grizzlypex. It could be set up on Hudson, but I guess we should have
own Hudson instance + server machine, to make sure client and server
are isolated as much as possible from side processes.
WBR,
Alexey.
>
> On 2/9/10 11:05 AM, Igor Minar wrote:
>> nice!
>>
>> On Feb 9, 2010, at 7:56 AM, Oleksiy Stashok wrote:
>>
>>> Hi,
>>>
>>> to prove that Grizzly 2.0 is not slow, I've run a small echo test.
>>> I've compared Grizzly 1.9.19 (svn trunk) and Grizzly 2.0 (svn
>>> trunk) configured with different strategies. The result shows that
>>> Grizzly 2.0 performing better or equal to 1.9.x. The difference is
>>> more significant when echoing tiny packets.
>>> Here are server and client configs:
>>>
>>> Server:
>>> numberOfCpus: 4
>>> osName: SunOS 5.10 Generic_Patch_118844-30 i86pc i386 i86pc
>>> numberOfSelectorThreads: 4
>>> numberOfWorkerThreads: 5
>>>
>>> Client:
>>> numberOfCpus: 2
>>> numberOfThreads: 32
>>> osName: Mac OS X
>>>
>>> I didn't use powerful machines during the test, but I think it's
>>> enough to confirm that Grizzly 2.0 with all its API extensions/
>>> changes is not slow.
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>> http://tinyurl.com/yemhry7
>>>
>>> ---------------------------------------------------------------------
>>> 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
>