Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows!

[James Tucker <jftucker@gmail.com>]

On 15 Dec 2009, at 21:32, Eric Wong wrote:

> James Tucker <jftucker@gmail.com> wrote:
>> On 15 Dec 2009, at 04:37, Eric Wong wrote:
>>> James Tucker <jftucker@gmail.com> wrote:
>>>> On 14 Dec 2009, at 18:42, Eric Wong wrote:
>>>>> James Tucker <jftucker@gmail.com> wrote:
>>>>>> I really want to work out an abstraction away from IO instances, #read
>>>>>> and #write for this stuff. It's highly coupled, getting in the way of
>>>>>> tests, and heavy lifting environments. I have big plans for Rack 2.0
>>>>>> to remove all IO that has not been properly abstracted and decoupled
>>>>>> from implementation details, but that's a long way off, mostly due to
>>>>>> lack of time and incentive. In the meantime, I can implore you all to
>>>>>> take steps in the right direction :-)
>>>>> 
>>>>> Huh?  I don't see what the problem with IO instances/semantics is,
>>>>> especially with the availability of StringIO for testing.  "rack.input"
>>>>> is clearly specified and works fine as-is IMHO, though the rewindability
>>>>> requirement does add some unnecessary overhead.
>>>> 
>>>> I disagree with "works fine". It does not work fine with Thin, in
>>>> fact, on the contrary, it forces some real ugliness into the system. I
>>>> also think that StringIO is a really unfortunate thing to have to
>>>> resort to, as it has so many short comings.
>>> 
>>> Mind elaborating?  I do not see what's ugly about it[1].
> 
>> Sure. It forces authors to several (bad) APIs options for handling
>> complex IO scenarios.
>> 
>> 1. Buffer the entire request and then republish to the application
>> 2. Pass forward the raw IO
> 
> 3. stream input with a rewindable backing store like TeeInput:
>   http://unicorn.bogomips.org/Unicorn/TeeInput.html
>   This is already supported by several (but not all) Rainbows!
>   concurrency models: http://rainbows.rubyforge.org/Summary.html
> 
> I'll need to use Fibers to get this working with Rev and EventMachine,
> (the FiberSpawn/FiberPool models are select-based), but exposing an
> outwardly synchronous model is far easier for application developers to
> grok.
> 
>>> [1] - I admit to having a Unix bias here where
>>>     nearly everything is a file, or ought to be :)
> 
>> We're not stream processing here. It's a request/response cycle. And
>> they aren't files, they're sockets.
> 
> We can be stream processing, see examples/echo.ru in the Unicorn source
> which streams input to the output body:
> 
>  http://git.bogomips.org/cgit/unicorn.git/tree/examples/echo.ru
> 
>> Unix philosophy is good for the shell, but it doesn't extend well into
>> efficient systems. The simplest proof for this is the existence of
>> kqueue, epoll, completion ports, and eventlets.
> 
> "Unix philosophy" means that Unix is not bound by "Unix philosophy"
> (as in we shouldn't be bound by one true way of solving a problem :)
> 
> Yes doing concurrency efficiently can get ugly.  But getting the most
> performance/efficiency out of _anything_ will get ugly[1].
> 
>> To optimise for efficiency or for performance (they needn't be the
>> same), it is absolutely required that abstractions move away from
>> strictly synchronous and external-lock scheduled IO (like group select
>> or per-socket select, etc).
> 
> Fibers in Ruby 1.9 are fairly lightweight and likely the most efficient
> way for Ruby networking concurrency right now (balancing "efficient" in
> both programmer cycles and hardware cycles).
> 
> Performance is "good enough" for most applications, but that's the trade
> off for using Ruby (vs C vs asm).  Most of the lack of performance I've
> seen lies in the underlying applications served.

I need to dig out the old discussions with ryah when he was working on flow (a rebuild of Ebb), this was fairly well covered by looking at performance and efficiency stats from apps based on the async_app.ru tests i wrote in the Thin repo. Specifically, you can get a measure of the scheduling efficiency by looking at the request rate for this example, and 5% overhead is pretty darn low.

> 
> 
> [1] - Though I've been tempted to write a Linux-only synchronous
> clone(2)-based server with sane[2] stack sizes just to see how well a
> synchronous model performs against (mentally-)uglier event-based
> solutions.
> 
> [2] - I do not consider the 64K stacks enforced by pthreads to be a
> sane lower bound.
> 
> -- 
> Eric Wong