On Mar 17, 2009, at 7:06 AM, Oleksiy Stashok wrote:
>>>
>>>
>>> I agree with your observation, comparing blocking vs. non-blocking
>>> modes.
>>> As I understand you make tests with small number of clients,
>>> right? (client_num < worker_threads_num)?
>>
>> yes, but even with client_num > worker_threads_num blocking io can
>> be faster if the clients are really fast, but that's not typical,
>> unless you control clients and can guarantee their speed.
> Right, also you can not "guarantee" the file size, right? :) So in
> general for send-file, IMHO, it's more important to be scalable.
It really depends on the environment. Let's say that you want to serve
mp3 files (3-10MB) on a local network with known number of clients and
relatively guaranteed bandwidth for both the server and clients. In
that case, it is very likely that blocking io will get the job done
faster that non-blocking io.
But when it comes to serving content for clients on the internet, you
are much better off with non-blocking io because there are too many
slow clients (compared to your server) out there, that would just hold
on to a worker, which would most likely result in a need for lots of
workers or likelihood of requests waiting in a queue for a worker.
So in general you are right, scalability is more important than
performance, but there some exceptions.
/i
>
> WBR,
> Alexey.
>
>
>>
>>
>> At least that's what I observed during my tests.
>>
>> /i
>>
>>
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>>
>>>>
>>>> On Nov 28, 2008, at 7:40 AM, Jeanfrancois Arcand wrote:
>>>>
>>>>> Salut,
>>>>>
>>>>> Igor Minar wrote:
>>>>>> Hi there,
>>>>>> On Nov 26, 2008, at 1:22 PM, Jeanfrancois Arcand wrote:
>>>>>>>>> Just invoke:
>>>>>>>>>
>>>>>>>>> selectorThread.addBannedSelectionKey(..);
>>>>>>>>>
>>>>>>>>> > /**
>>>>>>>>> > * Add a <code>SelectionKey</code> to the banned list
>>>>>>>>> of SelectionKeys.
>>>>>>>>> > * A SelectionKey is banned when new registration
>>>>>>>>> aren't allowed on the
>>>>>>>>> > * Selector.
>>>>>>>>> > */
>>>>>>>>> > public void addBannedSelectionKey(SelectionKey key){
>>>>>>>>> > bannedKeys.offer(key);
>>>>>>>>> > }
>>>>>>>>>
>>>>>>>>> I'm using this trick for Comet. Which version of GF are you
>>>>>>>>> using? I suspect the API is there.
>>>>>>>> Interesting! I must have missed that while reading the Comet
>>>>>>>> code.
>>>>>>>> So instead of canceling the selectionkey associated with the
>>>>>>>> main selector, you just mark it as "banned", which causes the
>>>>>>>> selector to ignore it.
>>>>>>>
>>>>>>> Indeed. So the CometSelector has full control over what's
>>>>>>> happening.
>>>>>> So I played with this today and realized that this api won't
>>>>>> work for me.
>>>>>> As I previously mentioned I have two kinds of algorithms
>>>>>> blocking and non-blocking (http://kenai.com/projects/grizzly-sendfile/pages/Algorithms
>>>>>> ). For in order to get the blocking algorithms to work, I need
>>>>>> to switch the SocketChannel to the blocking mode and that can
>>>>>> be done only when that channel is not registered with any
>>>>>> selector.
>>>>>
>>>>> I see. This is easy to do with 1.9...let me reminds myself 1.0 :-)
>>>>>
>>>>>> Since addBannedSelectionKey doesn't deregister the channel from
>>>>>> the selector, it is impossible for me to switch to the blocking
>>>>>> mode.
>>>>>> Any idea how to get around this? Is my only option to patch
>>>>>> grizzly and add my forceKeepAlive() method in order to get this
>>>>>> to work?
>>>>>
>>>>> Hum..I don't like the solution. Let me think of it.
>>>>
>>>> Any thoughts on this?
>>>>
>>>> I benchmarked my blocking vs nonblocking algorithms [1] and while
>>>> the performance of nonblocking is acceptable, the performance of
>>>> blocking algorithms is superior (10-20%). I totally understand
>>>> that blocking io is ugly and doesn't scale, but I can imagine
>>>> cases when performance is more important than scalability.
>>>>
>>>> Any chance I can get a patch like this accepted in grizzly:
>>>>
>>>> --- DefaultProcessorTask.java.orig 2009-02-18 20:54:29.000000000
>>>> -0800
>>>> +++ DefaultProcessorTask.java 2009-02-18 22:43:16.000000000 -0800
>>>> @@ -2228,5 +2228,16 @@
>>>> public boolean getDisableUploadTimeout() {
>>>> return disableUploadTimeout;
>>>> }
>>>> +
>>>> +
>>>> + /**
>>>> + * Ugly patch to prevent non-keep-alive connections from
>>>> being closed when
>>>> + * grizzly-sendfile takes over (when using a blocking
>>>> algorithm).
>>>> + */
>>>> + public void forceKeepAlive() {
>>>> + keepAlive = true;
>>>> + connectionHeaderValueSet = true;
>>>> + }
>>>> +
>>>> }
>>>>
>>>> I understand that this is a hack because I basically take
>>>> advantage of the fact that keepalive connections are being closed
>>>> differently than non-keepalive connections.
>>>>
>>>> A proper fix would require to add an api that would allow me to
>>>> take over responsibility for closing a socket channel when I
>>>> deregister a key from the main selector and register it with my
>>>> custom (grizzly-sendfile) selector.
>>>>
>>>> If you don't like this patch then don't worry about it, I plan to
>>>> use a nonblocking algorithm by default starting with grizzly-
>>>> sendfile 0.3, but I thought that it would be nice to have full
>>>> support for blocking algorithms as well.
>>>>
>>>> cheers,
>>>> Igor
>>>>
>>>>
>>>> [1] http://kenai.com/projects/grizzly-sendfile/pages/Algorithms
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>