Comments on: cat /proc/cpuinfo or Don’t Trust Your Cores To Rackspace, Part I http://www.rubyrescue.com/blog/2009/10/27/cat-proccpuinfo-or-dont-trust-your-cores-to-rackspace-part-i/ begin..rescue..end Sat, 10 Dec 2011 14:23:03 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Segedunum http://www.rubyrescue.com/blog/2009/10/27/cat-proccpuinfo-or-dont-trust-your-cores-to-rackspace-part-i/comment-page-1/#comment-911 Segedunum Wed, 27 Jan 2010 16:01:49 +0000 http://www.rubyrescue.com/blog/?p=73#comment-911 Conservative spawning just gives you the same issues as using Mongrels, so unless your application isn't compatible with Passenger's smart spawning then you don't really want to be using it. Few application running under Mongrel will have that problem. Passenger makes more sense on shared hosts with shared applications, or when you're not quite sure how many application processes you'll need at any given time. Conservative spawning just gives you the same issues as using Mongrels, so unless your application isn’t compatible with Passenger’s smart spawning then you don’t really want to be using it. Few application running under Mongrel will have that problem.

Passenger makes more sense on shared hosts with shared applications, or when you’re not quite sure how many application processes you’ll need at any given time.

]]> By: Brian Armstrong http://www.rubyrescue.com/blog/2009/10/27/cat-proccpuinfo-or-dont-trust-your-cores-to-rackspace-part-i/comment-page-1/#comment-877 Brian Armstrong Wed, 28 Oct 2009 14:17:12 +0000 http://www.rubyrescue.com/blog/?p=73#comment-877 Interesting writeup Chad. I use passenger/nginx and hadn't heard of unicorn. Will have to check it out. It sounds like more and more apps are moving to the one big machine solution instead of sharding or something. i read recently that the entire Basecamp database is served on one big machine, 8 core, 128gb ram. I think with InnoDB you can keep almost the entire database in memory. Or as they put it, they keep getting saved from sharding by Moore's law. That also definitely true where the moment you start dreading a deploy, your code suffers. It's worth trying to make them fast and painless. @Eric Waller - i agree passenger doesn't make a whole lot of sense on a 256mb slice. It really shines if you have many instances running because of the shared memory. But if you only have 1 or 2 instances it's just extra overhead. Conservative spawning mitigates some of this. Interesting writeup Chad. I use passenger/nginx and hadn’t heard of unicorn. Will have to check it out.

It sounds like more and more apps are moving to the one big machine solution instead of sharding or something. i read recently that the entire Basecamp database is served on one big machine, 8 core, 128gb ram. I think with InnoDB you can keep almost the entire database in memory. Or as they put it, they keep getting saved from sharding by Moore’s law.

That also definitely true where the moment you start dreading a deploy, your code suffers. It’s worth trying to make them fast and painless.

@Eric Waller – i agree passenger doesn’t make a whole lot of sense on a 256mb slice. It really shines if you have many instances running because of the shared memory. But if you only have 1 or 2 instances it’s just extra overhead. Conservative spawning mitigates some of this.

]]> By: Lamnk http://www.rubyrescue.com/blog/2009/10/27/cat-proccpuinfo-or-dont-trust-your-cores-to-rackspace-part-i/comment-page-1/#comment-872 Lamnk Wed, 28 Oct 2009 03:32:01 +0000 http://www.rubyrescue.com/blog/?p=73#comment-872 Sorry, but look like it's your fault. First thing i do on a new server is to check the specs and do some burn-in test. Sorry, but look like it’s your fault. First thing i do on a new server is to check the specs and do some burn-in test.

]]> By: Eric Waller http://www.rubyrescue.com/blog/2009/10/27/cat-proccpuinfo-or-dont-trust-your-cores-to-rackspace-part-i/comment-page-1/#comment-871 Eric Waller Wed, 28 Oct 2009 03:06:48 +0000 http://www.rubyrescue.com/blog/?p=73#comment-871 Somewhat of a tangent, but related to your apache+passenger to nginx+unicorn switch: I noticed a similar gain in throughput (10-12 req/s to 25-30req/s) for action cached pages (in merb) after switching out nginx+passenger for nginx+thin. This is on a 256mb slice, and seems totally counter to the general opinion that passenger is great for VPSes (or for anything if these performance numbers are representative). Somewhat of a tangent, but related to your apache+passenger to nginx+unicorn switch:

I noticed a similar gain in throughput (10-12 req/s to 25-30req/s) for action cached pages (in merb) after switching out nginx+passenger for nginx+thin. This is on a 256mb slice, and seems totally counter to the general opinion that passenger is great for VPSes (or for anything if these performance numbers are representative).

]]>