Re: EventMachine with thread pool and thread spawn

["Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@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
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying