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=0.8 required=3.0 tests=AWL,MSGID_FROM_MTA_HEADER, RDNS_NONE shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: "Lin Jen-Shin (godfat)" Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: EventMachine with thread pool and thread spawn Date: Fri, 27 Sep 2013 01:59:51 +0800 Message-ID: References: <20130823225114.GA5691@dcvr.yhbt.net> <20130825215701.GA31966@dcvr.yhbt.net> <20130905230305.GA5823@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 1380218434 13512 80.91.229.3 (26 Sep 2013 18:00:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Sep 2013 18:00:34 +0000 (UTC) To: "Rainbows! list" Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Thu Sep 26 20:00:35 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=godfat.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=aJUCBunpiNQ+kjY+OdOnSUBRicR7Lpd+/FeVSWKgkgE=; b=RR+fYb2NydpInOXFAvcmpjL9wGTSVvbFWIysafnO2FPnWD6cifoCRz50SYTPMdgNMo I/9tHcXlKO8suk44CdgN6GSYCynefvKc2d4sv0QKw96rgmVNnUKUB0IFDokls7SxfdyZ BTDc2fZADCgxDphKSr69p/m04Wc/3UKoVHFgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=aJUCBunpiNQ+kjY+OdOnSUBRicR7Lpd+/FeVSWKgkgE=; b=D4szBnmXCXUFv0Eh3L8lXwoi1HHF257cyNBiw1txE1/OoYkleA3yAIRM+YXh9kF91k qI/RCR1tqQlTQwwPN+GUt9+QKLLrHUI3XTceV4OsHq5oIKCDhNhAV7/Gj9uSctDqJVUB qv9rW/wwKXcaFOW6yz9vvJyHPoWaYMf1loRUCaVT2PvrnLsgpZFxKuxLIfKsqgi1SPCw SX07o27+L1XaZ0Ysj4qwJ4xAqc/FCYBDIbWxh/h9lwpLlb3R6u+lsVwr8VwhPYNUWYqf ra4eZub1VMk/Ohbpm+cgXx1iCAzs8YyowSMwjMu/2BmabHvTC6+1/GJFgc/lNofbwtaw 6kug== X-Gm-Message-State: ALoCoQmWBu7iKfti8oFmiPCe8XmwOAZIOHibY2qLIZinDb0CFpvviblJrQqIdT+uSmRUI50exadF X-Received: by 10.14.241.141 with SMTP id g13mr3093425eer.75.1380218421192; Thu, 26 Sep 2013 11:00:21 -0700 (PDT) In-Reply-To: <20130905230305.GA5823-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> 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:550 Archived-At: Received: from [50.56.192.79] (helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VPFrZ-0001aY-2w for gclrrg-rainbows-talk@m.gmane.org; Thu, 26 Sep 2013 20:00:29 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 313CF2E298; Thu, 26 Sep 2013 18:00:29 +0000 (UTC) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by rubyforge.org (Postfix) with ESMTP id 051272E28F for ; Thu, 26 Sep 2013 18:00:23 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id b10so712648eae.38 for ; Thu, 26 Sep 2013 11:00:21 -0700 (PDT) Received: by 10.223.200.132 with HTTP; Thu, 26 Sep 2013 10:59:51 -0700 (PDT) On Fri, Sep 6, 2013 at 7:03 AM, Eric Wong wrote: > "Lin Jen-Shin (godfat)" wrote: >> On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong 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