Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: synchronous controllers taking 6 seconds in Eventmachine config
Date: Wed, 15 Sep 2010 14:04:04 -0700	[thread overview]
Message-ID: <20100915210404.GA21719@dcvr.yhbt.net> (raw)
In-Reply-To: <97F7A036-4DA6-4CF3-B842-5870F7DE59E7-Re5JQEeQqe8AvxtiuMwx3w@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

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
Do not quote signatures (like this one) or top post when replying

  parent reply	other threads:[~2010-09-15 21:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 13:46 Christoph Sturm
     [not found] ` <2B157204-E5C6-4F5D-98A9-E2A79F9F9765-Nf+wZpSdgweeYOMve9Zru9BPR1lH4CV8@public.gmane.org>
2010-09-15 18:50   ` Eric Wong
     [not found]     ` <20100915185007.GA13709-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2010-09-15 19:30       ` James Tucker
     [not found]         ` <97F7A036-4DA6-4CF3-B842-5870F7DE59E7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-09-15 21:04           ` Eric Wong [this message]
     [not found]             ` <20100915210404.GA21719-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2010-09-17  9:00               ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100915210404.GA21719@dcvr.yhbt.net \
    --to=normalperson-rmlxzr9ms24@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).