Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
From: "Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org>
To: "Rainbows! list" <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: EventMachine with thread pool and thread spawn
Date: Fri, 27 Sep 2013 01:59:51 +0800	[thread overview]
Message-ID: <CAA2_N1sy9Nqf1Tnk6+Sg70WbqWOgHbTsWo3H5qk4MqoCD0o=Cg@mail.gmail.com> (raw)
In-Reply-To: <20130905230305.GA5823-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>

On Fri, Sep 6, 2013 at 7:03 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> "Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
>> On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
[...]
>> That is, oneshot would be the way to go in this scenario?
>> I also heard that libev is merely a thin wrapper around epoll...
>
> Yes.  Fwiw, I've been working on yet another Ruby server :)
> It's not Rack-specific and the design is based on cmogstored
> (a oneshot + multithreaded storage server for MogileFS).

Great news! From last time I knew, there's only Perl server
for MogileFS, though part of it could be replaced by Nginx.
I haven't been using MogileFS for several years, it would be
cool to revisit it. I still remember my super naive patch for
mogilefs-client... I knew so much more these years.

>> After benching mark against Heroku, I feel it does have some kind of
>> buffers. It's hard to tell though........ but yeah, maybe we don't really
>> need full buffering at application server level.
>
> If your responses are all small, you'll never need/hit output buffering
> in userspace (the kernel always buffers some).  I think any proxy
> (Heroku included) does full header buffering, it's just few proxies can
> do full request body (PUT/POST) buffering like nginx.

Just checked Heroku's document again. It seems the header
buffer size is 8K, and the response would have 1M buffer.
https://devcenter.heroku.com/articles/http-routing#request-buffering
The request body is still not buffered at all, if the document is
up-to-date. This is another reason I am quite disappointed.
Their stuffs are black boxes which we could only check the
document frequently and hope it's up-to-date. (which is not before)

Our responses should be far less than 1M though.

>> Is it because it might not make too much sense to buffer in
>> XEpollThread*, or implementation-wise, it's easier to do it this way?
>
> Yeah, it was easier.  (Lazy) buffering with multiple threads helps,
> too, but not as much as buffering with a single thread.  Threads
> are fairly cheap nowadays.

However we'll need to reduce the number of threads to avoid
exhausting PostgreSQL connections though :(
We only have roughly 400~450 connections available,
and connections could not be shared among threads.

I guess in order to escape from this constraint would be using
PgBouncer, which is a PostgreSQL connections pool. With this,
we could have more threads than PostgreSQL connections.

However this is not a standard Heroku addon which we could use,
we need to use some custom scripts to do so, and I am quite
worried that they might change something one day and it breaks.

I don't know why PostgreSQL connections are so heavy...

>> The reason why they don't fully buffer is because of latency concern
>> as far as I know. But I feel in most of the web apps, we don't really do
>> realtime stuffs.
>
> Latency for slow streaming?  Sure, but unicorn is completely wrong for slow
> streaming in any direction.

Interestingly, I also tried Thin which is behind EventMachine. Unicorn still
outperforms Thin easily with my simple benchmarks, unless I exploited the fact
that Unicorn does not buffer, sending a lot of very slow and large
POST requests.

So overall if no one is trying to attack like this, Unicorn still
performs better
than Thin. But I would still think leaving this kind of vulnerability
for people to
attack easily, and only solve it when we face it is not that good, especially
when we could make it much harder easily by putting some buffers.

> For fast requests/responses, any latency introduced by nginx is dwarfed
> by network latency to the client.

Yeah, right...

> Heh, I don't get it, either.  Especially given _my_ disapproval of
> the default Heroku setup with unicorn.  Oh well, I get the feeling
> some unicorn users only use it because of buzz from a handful of
> blogs, not because they read the documentation and understand it.

Exactly. I don't understand why sending links to archives for this mailing
list didn't really work... They seem to trust fancy blog posts more than
this list. I even doubt if they read the documentation... which is so clear
and inspiring. I learned so much from reading it.

> That probably goes for most tech :<

If this is true, I probably haven't used to it. I doubt if I would ever.
Sometimes I feel the more I understand, the more cynical I would be.
Not sure if it's a good thing...
_______________________________________________
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


  parent reply	other threads:[~2013-09-26 18:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23 21:22 EventMachine with thread pool and thread spawn Lin Jen-Shin (godfat)
     [not found] ` <CAA2_N1uiz7Razb5J6wYCnD0w8sXrbCRp6LnLC+hTg2+Oipfrrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-23 22:51   ` Eric Wong
     [not found]     ` <20130823225114.GA5691-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2013-08-25 12:34       ` Lin Jen-Shin (godfat)
     [not found]         ` <CAA2_N1sqvUap-97EjpiKyLicXt3J5zeNSws3O4CAJ3VKUvgVcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-25 21:57           ` Eric Wong
     [not found]             ` <20130825215701.GA31966-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2013-09-05 19:59               ` Lin Jen-Shin (godfat)
     [not found]                 ` <CAA2_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-05 23:03                   ` Eric Wong
     [not found]                     ` <20130905230305.GA5823-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2013-09-26 17:59                       ` Lin Jen-Shin (godfat) [this message]
2013-09-06  6:52                   ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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='CAA2_N1sy9Nqf1Tnk6+Sg70WbqWOgHbTsWo3H5qk4MqoCD0o=Cg@mail.gmail.com' \
    --to=godfat-hoe/xeebyyidnm+yrofe0a@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 public inbox

	https://yhbt.net/rainbows.git/

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).