# Deployment questions **URL:** \ **Category:** Rails\ **Created:** [January 23, 2007, 6:30pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104 "2007-01-23T18:30:01Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 6:30pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/1 "2007-01-23T18:30:01Z")
All, I have some basic deployment questions: 1. How many concurrent requests can be served, on average, by one Mongrel process (I know, it depends)? Just a rough idea. 2. I thought I read something about ~40MB of memory/request used on the server on average - is this correct? That seems really high to me. Thanks, Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 8:43pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/2 "2007-01-23T20:43:00Z")
Wes: Run your owntests. It’s the only way you’re going to get good results. Can be as low as 3, can be as high as 100+. Use httperf and test, test, test. I’ve posted some test strategies on this form a few times… maybe do a search for httperf and you might see something I wrote a few weeks ago. I’d recommend running more than one Mongrel unless you can delegate most of your requests to a static server using caching. Browsers need to grab your css files and js files, and if you’re not offloading that to Apache then one instance is really going to choke. ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 9:23pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/3 "2007-01-23T21:23:15Z")
Hi~ On Jan 23, 2007, at 9:30 AM, Wes G. wrote: > All, > > I have some basic deployment questions: > > 1. How many concurrent requests can be served, on average, by one > Mongrel process (I know, it depends)? Just a rough idea. mongrel and any other way of running rails can only serve 1 concurrent request at a time. ActionPack is not threadsafe so there is a big mutex lock around each dispatch to rails. This means you really need at least 2 mongrels for a production app. If you only had one and for example a user uploads a large file, no other requests will get served until the upload finishes. So you have to run a cluster of mongrels to get around this. 2 or 3 mongrels behind nginx or apache can serve quite a bit of traffic and users. But it varies depending on the type of app. > 1. I thought I read something about ~40MB of memory/request used on > the > server on average - is this correct? That seems really high to me. Mongrel uses a bit less memory on 32 bit systems but on 64bit systems a rails app running on 1.2.1 will take on average 40-75Mb of ram per mongrel, and you need 2 or 3 mongrels per app. Rails is memory hungry it’s just a fact of life for a rails dev. It’s way cheaper to create great software with rails but it will require more ram and hardware to deploy your app. So it’s a tradeoff of developer time and hosting costs. > Thanks, > Wes Cheers- – Ezra Z. – Lead Rails Evangelist – removed\_email\_address@domain.invalid – Engine Y., Serious Rails Hosting – (866) 518-YARD (9273) ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 9:30pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/4 "2007-01-23T21:30:17Z")
Ezra Z. wrote: > mongrel and any other way of running rails can only serve 1 > concurrent request at a time. ActionPack is not threadsafe so there > is a big mutex lock around each dispatch to rails. Ezra, Thanks for the response. This raises a couple of questions for me. 1. I thought that I had heard that ActionPack is not thread safe. Is this because there is common class-level code being executed for each request? Is it difficult to make it thread safe? What would be involved? 2. Is it a true statement that Rails can only support as many (truly) concurrent requests as Mongrel instances? Thanks, Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 10:24pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/5 "2007-01-23T22:24:31Z")
> way cheaper to create great software with rails but it will require > more ram and hardware to deploy your app. So it’s a tradeoff of > developer time and hosting costs. Another option is litespeed (or any server that can spawn/kill the rails instances on demand). I recently switched from apache/mongrel to litespeed for exactly this reason. I have several small sites (by small, I mean I’m pretty much the only one who cares). Running 6-8 mongrels simply wasn’t going to happen on my little box. But with litespeed I can tell it not to run _any_ lsapi instances, then spawn a max of 5 for each app, then kill them off if they’ve been idle for more than a couple of minutes. This way I get the best of both worlds in my physically limited server. Anyway, just another option… ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 10:25pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/6 "2007-01-23T22:25:32Z")
> 1. Is it a true statement that Rails can only support as many (truly) > concurrent requests as Mongrel instances? Yes, but remember that mongrel can serve a lot of rails requests per second (depending on the app)… We run 4 mongrels at work, but serve quite a bit of traffic with that… -philip ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 10:43pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/7 "2007-01-23T22:43:35Z")
On Jan 23, 2007, at 12:30 PM, Wes G. wrote: > 1. I thought that I had heard that ActionPack is not thread safe. > Is this because there is common class-level code being executed for > each > request? Is it difficult to make it thread safe? What would be > involved? There are a number of things that make AP not thread safe. Part of that is because thats the way it has been from the begining mostly, and so code is added without thought to thread safety. This is a viable approach that has allowed rails to do so much of the magick that it is known for, but it sacrifices multi threaded performance to do so. I have experimented with a mongrel rails dispatcher that doesn’t lock around route recognition and mime parsing but only locks when your controllers action is being run. But this fails miserably when hit with concurrent requests. I suspect it is a large job to make AP thread safe and the boat has kinda sailed on it. If someone really wanted to make AP thread safe they coudl start by writing failing test cases that show where it falls down in a threaded env. But there is a lot of code to audit in AP to make this happen. > 1. Is it a true statement that Rails can only support as many (truly) > concurrent requests as Mongrel instances? Yes this is true. But in practice you will almost never get requests at exactly the same time. So if you keep your rails actions fast then 3 mongrels can serve quite a bit of concurrency with httperf before it falls down. > Thanks, > Wes Cheers- – Ezra Z. – Lead Rails Evangelist – removed\_email\_address@domain.invalid – Engine Y., Serious Rails Hosting – (866) 518-YARD (9273) ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 23, 2007, 11:03pm UTC](https://www.ruby-forum.com/t/deployment-questions/83104/8 "2007-01-23T23:03:41Z")
Thanks for the post, Ezra. That helps. Now I see that optimizing your Rails app. is even more important that it always was, if that makes sense :). I just finished reading that length post on the Ruby forum where you, a guy named Sunny, and Ed Borasky hashed out performance issues in Ruby/Rails. It was incredibly informative (see: [Two Advanced Ruby Performance Questions - Ruby - Ruby-Forum](http://www.ruby-forum.com/topic/89451)). Are you still working on Merb? Wes ---
**Author:** ![weyus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/7ab992/32.png) [@weyus](https://www.ruby-forum.com/u/weyus)\ **Post date:** [January 24, 2007, 2:11am UTC](https://www.ruby-forum.com/t/deployment-questions/83104/9 "2007-01-24T02:11:07Z")
On Jan 23, 2007, at 2:03 PM, Wes G. wrote: > [Two Advanced Ruby Performance Questions - Ruby - Ruby-Forum](http://www.ruby-forum.com/topic/89451)). > > Are you still working on Merb? > > Wes Yeah I am still working on merb. It is coming along nicely. It is running over 20 production apps now. I still use ActiveRecord but I pretty much wrote my own implementation of actionpack that is a lot more thread safe then AP. I still have a mutex lock but it only locks while a controller action is being run. All the route recognition and mime parsing happens in a thread safe way so that merb can handle many concurrent connections with one instance. For example, a fresh rails app with one controller that just does render :text =\> “hello!” so that it invokes the full rails stack. Right now that benchmarks on my macbookpro at 120 req/sec on one mongrel, it also cannot handle it when you set the httperf concurrency setting to more then 1. Doing the same thing in merb clocks in at about 350-400 req/sec and can handle up to 100 or so concurrent connections before it starts to slow down. Merb also only uses 20Mb of ram per instance so you can run 2 or 3 of them in the same ram that you can run one mongrel with rails loaded. Anyway merb is great for smaller projects or for rewriting critical sections of your rails app in something faster. But merb is nowhere near as cushy as rails with regard to features. Merb is definitely heavily inspired by rails. I took a great many idioms from rails. But I left out some stuff I feel is bloat and cruft in favor of being closer to pure ruby and letting you build the framework to suit your needs instead of just getting the kitchen sink and whatever baggage comes with that. [http://merb.devjavu.com/](http://merb.devjavu.com/) Cheers- – Ezra Z. – Lead Rails Evangelist – removed\_email\_address@domain.invalid – Engine Y., Serious Rails Hosting – (866) 518-YARD (9273)