[ruby-core:24072] Re: [Bug #1696] http downloads are unuseably slow

I believe if the descriptor is set to non blocking then sysread will return
whatever data available or raise an error if there isn't any.
But non block is critical for large buffer sizes as select will return the
socket as ready even if it has only one byte to read.

I would also recommend the nonblocking call happens before the select. This
way fast connections will not be taxed by two system calls, while slow
connections are slow anyway so they can wait for the Errno::EAGAIN exception
to be handled

oldmoe

On Sun, Jun 28, 2009 at 9:26 PM, Steven Hartland <[e-mail]>wrote:

> Issue #1696 has been updated by Steven Hartland.
>
>
> As you can see from the test results a 16Kb buffer is way to small for high
> bandwidth connection, so as Eero mentioned this definitely needs to be
> documenting. N.B. I assume this has been moved to either a class variable or
> other accessible option.
>
> None blocking support should be trivial, simply setting the flag on the
> socket should be sufficient, but with the current patch select will be
> achieving this anyway assuming sysread is actually using recv under the
> covers and returns with what ever data is available instead of waiting for
> size data. This is not clear from the docs as sysread, readpartial and
> read_nonblock contain conflicting info and in places some English which just
> doesn't make sense. If not just changing that one line should be sufficient.
>
> Having a quick look at the current nightly snapshot the code:
> 1. It may not be ordered in the best way for performance especially on
> slower connections. I would suggest testing if inverting the order and
> allowing select to do its work before doing a none blocking read, or in fact
> a standard recv ( no need for none blocking, as its already guaranteed to
> work due to the select check ). Careful benchmarking of differing speed
> connections would be needed to confirm which is better.
> 2. slice is still in place, which could also still be causing an issue
> unless the underlying slice implementation has been fixed for the no-op
> case.
>
> ----------------------------------------
> http://redmine.ruby-lang.org/issues/show/1696
>
> ----------------------------------------
> http://redmine.ruby-lang.org
>
>