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
next prev 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 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' \ --firstname.lastname@example.org \ --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \ --subject='Re: EventMachine with thread pool and thread spawn' \ /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
Code repositories for project(s) associated with this inbox: ../../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).