From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: * X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=1.7 required=3.0 tests=AWL,HK_RANDOM_FROM, MSGID_FROM_MTA_HEADER,RDNS_NONE shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: EventMachine with thread pool and thread spawn Date: Thu, 5 Sep 2013 23:03:06 +0000 Message-ID: <20130905230305.GA5823@dcvr.yhbt.net> References: <20130823225114.GA5691@dcvr.yhbt.net> <20130825215701.GA31966@dcvr.yhbt.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1378422292 24325 80.91.229.3 (5 Sep 2013 23:04:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2013 23:04:52 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Fri Sep 06 01:04:56 2013 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Broken-Reverse-DNS: no host name found for IP address 50.56.192.79 Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:534 Archived-At: Received: from [50.56.192.79] (helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VHibJ-0004rO-KH for gclrrg-rainbows-talk@m.gmane.org; Fri, 06 Sep 2013 01:04:33 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id ACE192E17C; Thu, 5 Sep 2013 23:04:33 +0000 (UTC) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 03BDD2E145 for ; Thu, 5 Sep 2013 23:03:08 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id A97701F6BD; Thu, 5 Sep 2013 23:03:06 +0000 (UTC) "Lin Jen-Shin (godfat)" wrote: > On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong wrote: > > 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. I came to the same conclusion as you a while back. The epoll_ctl() API isn't very efficient for single-threaded servers (this is probably the biggest complaint of existing single-threaded epoll users). The kevent() API is better for single-threaded operation, but I'm not sure if it's optimal for multithreaded. I might propose a new epoll_xchg syscall which behaves closer to kevent. It would only be a tiny improvement for multi-threaded epoll, but possibly big for single-threaded epoll (but would require rewriting existing single-threaded apps). I don't think it's worth it since there's lower hanging fruit for improving MT epoll performance. > 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). > >> 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. 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. > > 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? XEpoll is similar to the EventMachine use in Rainbows!. It just won't disconnect if a client goes overboard with pipelining, and there's no EM API. It reads all of the input before processing, and will buffer if writes are blocked. > 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. > > 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. Ah, the message says to send it again, I think. Anyways, I don't mind receiving too much email as long as it's plain-text. > 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. Yeah, I don't think I'll use librelist for new projects (especially since I favor reply-all more nowadays). Not sure if it's worth the migration hassle for small projects like s.p, though... I'll probably go with Rubyforge or savannah.nongnu.org for new projects for now. Maybe using something completely decentralized and friendly to command-line users will be suitable in the future. _______________________________________________ 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