Re: rails 2 and slow external services

[Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>]

ghazel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> On Mon, Dec 13, 2010 at 8:57 PM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> > ghazel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> > ghazel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >> >> Some of my page loads (currently serviced by Unicorn) spend a great
> >> >> deal of time waiting for external services (OpenID, OAuth, etc over
> >> >> Net::HTTP and curb), so I'm looking at Rainbows!. I use Rails 2.3.10.
> >>
> >> This is Ruby 1.8.7 (REE). Is there any interesting difference between
> >> ThreadPool and ThreadSpawn in this environment?
> >
> > ThreadPool is generally more predictable, but ThreadSpawn has lower
> > memory usage if your traffic spikes are intermittent or low.
> >
> > ThreadSpawn is much like the original Mongrel and ThreadPool was an
> > experiment with Ruby 1.9 in mind.  1.9 has more expensive (but slightly
> > more concurrent) threading.  If your bottlenecks are external HTTP
> > requests on 1.8, but first instinct would be to use ThreadSpawn.
> >
> > Ruby 1.9 + ThreadPool would probably be well-suited for large file
> > serving to LAN clients with many slowish disks as it can use sendfile
> > via IO.copy_stream), but if you can afford the constant memory overhead,
> > it could be good in 1.8, too.
> 
> I don't mind constant memory overhead -  actually I prefer it to
> spikey memory usage with an unknown peak. Otherwise they should be the
> same?

Having idle threads with ThreadPool would affect GC performance,
actually.

> I'm running a bit of my traffic through some Rainbows! right now, but I got:
> 
> 2010/12/14 02:30:24 [error] 3183#0: *9229917 upstream timed out (110:
> Connection timed out) while reading response header from upstream,
> client: 1.2.3.4, server: mysite.com, request: "GET /blah HTTP/1.1",
> upstream: "http://unix:/tmp/rainbows.sock:/blah", host: "mysite.com",
> referrer: "https://foofoo.com"
> 2010/12/14 04:28:25 [error] 3182#0: *9440717 upstream timed out (110:
> Connection timed out) while reading response header from upstream,
> client: 5.6.7.8, server: mysite.com, request: "GET /blah HTTP/1.1",
> upstream: "http://unix:/tmp/rainbows.sock:/blah", host: "mysite.com"
> 
> From nginx in the error log. My proxy_read_timeout is 300, and my
> listen backlog is 2048 (for now...). Basically my Rainbows! config is
> identical to my Unicorn config, where I have not seen that happen,
> except I added "Rainbows! { use :ThreadPool; worker_connections 100
> }".

Was your app hitting the Unicorn kill -9 timeout frequently before?  In
Rainbows!, the kill -9 timeout only kicks in when the entire
interpreter/VM is stuck due to a broken C extension or bug in Ruby.

If it's some component of your app taking a long time (and relying on
the Unicorn kill -9 timeout), you can try the Rainbows::ThreadTimeout
middleware: http://rainbows.rubyforge.org/Rainbows/ThreadTimeout.html

-- 
Eric Wong
_______________________________________________
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