Re: synchronous controllers taking 6 seconds in Eventmachine config

[Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>]

James Tucker <jftucker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Eric, you don't do actual keepalive do you, or am i thinking of
> unicorn?

Rainbows! has had keepalive and pipelining since the earliest releases
for simple GET/HEAD requests.  At least there are integration tests
using curl that do keepalive, so it should work :)  Keepalive for
proxying sockets/pipes (without async.callback) has improved with recent
releases, too.

Rainbows! will support keepalive for all other body-less requests, too,
and _maybe_ optionally supporting keepalive PUT/POST requests with a
body.  For requests with a body, the app must consume the entire body
(which intentionally does not happen for "synchronous" concurrency
models).

Unicorn doesn't do keepalive since nginx doesn't do keepalive to
backends, yet.   That will change if nginx (or another comparable
frontend emerges) supports keepalive to the backends.

> If the request is sync, then you can close connection after body.each
> returns, else you need to use the deferrable api callback in
> deferrable bodies wiht the async api.

The EM deferrable doesn't do keepalive right now, and may not ever
because (I assume) it's used for long-polling and such.

Setting "keepalive_timeout 0" for any app doing long-polling/Comet stuff
is probably a good idea anyways, the client can't reliably know which
requests take a long time.

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying