Hi Igor,
>
> grizzly-sendfile-0.3-SNAPSHOT (the one used for tests) uses grizzly
> 1.9.15 not 1.0.x.
oh, didn't know that. Shame on me :)
> Is there more info/docs on aynchronous write queues?
http://blogs.sun.com/oleksiys/entry/grizzly_1_7_0_presents
we've changed API a little bit since that, but not much.
> btw I tried to run the same tests against glassfish v3b47 and it
> kept on getting into a state where after ~9min of testing it would
> start sending only partial responses or would refuse sending static
> files all together. I didn't have a lot of time to investigate (it
> took freaking forever to run all the tests I did), but I should run
> my tests against grizzly webserver to see if the problem repeats
> there.
> There were two or three glassfish tests that passed and with
> threadcount of 50 and buffer size 81k (10x the default), I still saw
> that gf could achieve only 40-60% of grizzly-sendfile's throughput.
hmm. Ok, if you'll have any further results, please let us know.
Thank you.
WBR,
Alexey.
>
> On May 11, 2009, at 2:02 AM, Oleksiy Stashok wrote:
>
>> Hi Igor,
>>
>> that's great blog and great observations.
>> It could be interesting to check one more strategy here:
>> asynchronous write queues. Unfortunately we don't have
>> implementation of one for Grizzly 1.0.x.
>> Unlike ENBA, asynchronous write queue first tries to write buffer
>> immediately, and only if it's not able to write whole buffer - it
>> registers for async. write (using the same selector, not new one).
>>
>> IMHO this approach could work better than ENBA, because, we will be
>> able to avoid selector/thread switches.
>>
>> Thank you!
>>
>> WBR,
>> Alexey.
>>
>> On May 11, 2009, at 4:17 , Igor Minar wrote:
>>
>>> I was hoping to post this sooner, but came across some *very*
>>> surprising results that I had to thoroughly validate - the
>>> blocking IO can scale!
>>>
>>> http://blog.igorminar.com/2009/05/grizzly-sendfile-and-comparison-of.html
>>>
>>> Let me know what you think, not very many people do multiplexed
>>> blocking IO and I think that it is an area that has a lot of
>>> potential and deserves more research.
>>>
>>> cheers,
>>> Igor
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>