Problems with mongrel_cluster and Rails 2.3 dispatcher reloading your metal every request 2

Posted by Tim Connor Wed, 15 Apr 2009 23:33:00 GMT

So, once I added a couple Rails metal to our high volume site, my boss complained that our performance took a serious hit. In tracking it down (with strace) we realized that every request was re-requiring each metal, which involves a full load path search. This was not happening on our local script/server started mongrels, but was happening on production for both thin and mongrel_cluster, even after we had gone through every setting and made them match exactly.

We traced it down to the difference of mongrel_cluster versus the script/server. Script/server is going to use the built in, updated for Rails 2.3, mongrel handler. The old stuff called by thin or mongrels started by mongrel_cluster, is going to use the old (“deprecated”) dispatch path, which in a cgi-ish fashion rebuilds the dispatcher and all rack middleware and metal each time, which means re-requiring them all.

So now I am not sure what to do. Do we have to start all of our mongrels with rackup? Do we take the rack mongrel handlers from rails and patch them into wherever? Do I file a bug for Rails that there at least needs to be some documentation, other than just deprecating the method that a stock mongrel will call?

Update I made a ticket for it Also having mongrel start up using the handler in the rails vendorized rack as a config will fix the problem for mongrel. I’m not sure about thin, as that handler seems to be rackup specific?

Update2 Ezra said he’d go with rackup and gave me a monit script for it

Update3 We made a barebone rails config.ru and made thin use that, forcing it down the path of using the built-in rails handler. That dropped our load by 30% roughly, so yeah, this behavior had a significant impact on us.

Installing mod_proxy on a Mac OS X - Tiger 10.4.8 1

Posted by Tim Connor Tue, 13 Mar 2007 08:13:00 GMT

I’m using Locomotive for my easy Rails install/set-up on my new iMac and been relatively unbothered by not having to download, build, configure, and manage a herd of tools. I installed MySQL, rather than be restricted to the included SQLLite3, but that is simple with the nice installers available from the MySQL AB. Now, I’ve come across the first more complicated “upgrade.”

With the default Locomotive (mongrel) set-up you end up with paths like localhost:3000. This is fine when you only ever have one site running, but causes a problem wih conflicted sessions when you have one site at :3000 and another at :3001. Now many of you are probably familiar with the idea of using Apache as a virtual hosting front-end/proxy. If you do so, and edit your hosts file (or take a quick trip to the NetInfo Manager in OS X) to map http://your_app to 127.0.0.1 you have a much improved situation.

Unfortunately, most of the instructions involved in setting this configuration up, either explicitely presume an Apache 2 install, or walk you through installing it, and OS X comes with 1.3. In the middle of developing a couple apps you may not wish to take time off to fully configure and mess with a full web server upgrade. It’d be much nicer to just add mod_proxy (the one missing piece), configure your vhosts, and call it good.

Figure out your apache version


shell$ httpd -v
Server version: Apache/1.3.33 (Darwin)
Server built: Aug 19 2006 07:55:18

Grab it from the archive and unzip


shell$ curl -O http://archive.apache.org/dist/httpd/apache_1.3.33.tar.gz
shell$ gnutar -xzf apache_1.3.33.tar.gz

Use apxs to build and install mod_proxy


sudo apxs -c -i src/modules/proxy/mod_proxy.c

Configure and you’re off (remember to uncomment the LoadModule and AddLoader)


<VirtualHost *:80>
ServerName your_app
ErrorLog /dev/null
CustomLog /dev/null common
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/