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, 6 Sep 2013 03:59:11 +0800	[thread overview]
Message-ID: <CAA2_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ@mail.gmail.com> (raw)
In-Reply-To: <20130825215701.GA31966-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>

On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> "Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
> kqueue is a queue, it's in the name.  I haven't looked too hard at the
> internal details, but the name says much about it :)
> I've studied epoll internals a bit and know that epoll is also a queue,
> it's just not in the name.
> Oneshot behavior basically makes epoll/kqueue behave like a traditional
> queue; once you pull a file/socket off the queue, it won't magically
> reappear unless you ask epoll/kqueue to watch for it again.
> This is significant for multithreaded servers, because it allows the
> kernel to handle synchronization (just like accept()).
> Level/edge-triggered epoll/kqueue is kind of like a tracklist in a music
> player with repeat=on + random=on.  It's fine if you're playing one
> track-a-time (like a single-threaded HTTP server), but if you try to
> play multiple tracks in different threads, you could end up playing the
> _same_ track in two or more threads.
> A multi-threaded HTTP server must implement its own synchronization
> on top of ET/LT epoll/kqueue to prevent serving the same client
> from multiple threads.

I searched and read a bit. I am not sure if I understand correctly,
but I have a feeling that both LT and ET epoll are not designed to
be used in a multithreaded server (i.e. handle I/O in epoll and dispatch
tasks to threaded handlers), or say it would be quite hard to get it right.

That is, oneshot would be the way to go in this scenario?
I also heard that libev is merely a thin wrapper around epoll...

>> I wonder if I should just go with XEpollThreadPool then? My concern
>> is that as Heroku does not buffer the entire request and response,
>> we need something which would do this for us. Not sure if XEpollThreadPool
>> would be sufficient?
> Probably using XEpollThread* is a good choice, but neither buffer (but
> you get more I/O concurrency anyways, so maybe it's not so bad)

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.

> Plain XEpoll does do full buffering, and you can probably add a
> TryDefer-like middleware on top of that, even...

Could you please explain to me why there's difference?
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?

> Anyways, it's still infuriating to me that Heroku cannot do full
> buffering and still claims to "support" unicorn.

They do provide a way to customize the deployment, so that we could
build an Nginx while deploying and run it for each unicorn process though.
They do not officially support this, but it could work... things might break
easily if they changed something though.

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.

And the most frustrating thing to me is that my co-workers don't really
trust me. They still prefer unicorn because Heroku recommends it
officially even when I showed benchmarks and some people at Heroku
did admit it could be an issue.

I am so tired of this.

> I can't officially support non-Free systems, but I can accept
> non-intrusive patches.  I'm not nearly as experienced with kqueue,
> so maybe you really found a bug in my kqueue API.
> Anyways, I've considered unifying a X{Epoll,Kqueue}Thread* interface,
> which is why I added kqueue support to sleepy_penguin before I forgot
> about it :x

Thanks for reading my patch. Hope one day I could jump to Linux
for my daily life as well :) I'll look into how clogger does the fallback.
I guess the idea is similar to duck "platforming" :P
This would also have the advantage that maybe one day the
platform would catch up and provide the same functions...

> I didn't get it on the list and can't find it on the archives, either.
> http://librelist.com/browser/sleepy.penguin/
> Are you sure it went out?  Feel free to Bcc me or send it here.
> (Librelist doesn't like plain Cc :<)
> It could be a librelist problem, too, but I just sent out a message
> considering a move away from librelist and it went through fine:
> http://mid.gmane.org/20130825212946.GA32430-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org

What's happening was that I sent it to librelist, and received an
email from librelist for confirming if I am subscribing it. I replied
the confirmation, wondering if my previous mail would show up
or not?

I was worried about sending it twice, thus didn't send again.
It seems after the confirmation everything works normally.
Not sure if librelist is a good choice, but at least it seems
working for me now.
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:[~2013-09-05 19:59 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) [this message]
     [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)
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:

  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_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ@mail.gmail.com \
    --to=godfat-hoe/xeebyyidnm+yrofe0a@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 public 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).