mod_rails – first impressions

  • Installing was easy as pie. I was missing the Apache development headers and the installer told me which ‘yum’ command I should use to install them. Nice.
  • When you don’t have heaps of memory, remember setting RailsMaxPoolSize to a lower value to avoid swapping. I’d experiment with RailsMaxPoolSize and saturating the number of concurrent requests using ApacheBench in any case. More concurrent threads is only better until a certain point.
  • Apache/HAProxy/Mongrel was a bit slower than Apache/mod_rails, which was a bit slower than HAProxy/mongrel (without Apache). The difference was nothing to loose sleep over. RailsMaxPoolSize was set the same as the nr of mongrels.
  • While ApacheBench testing, touching tmp/restart.txt to force a restart could cause a hang. Only restart of Apache helped.
  • I would get an occasional time-out and ab stopped (heavy testing, large nr of concurrent requests). BUT this also happened with Apache/HAProxy/mongrel (NOT when using HAProxy/mongrel ‘direct’) so I’d guess this is rather an Apache issue.

Mod_rails seems to be a surprising stable and finished product, and this for a first public release! I’m anxious to check out their Ruby Enterprise Edition.

The occasional hang when touching tmp/restart.txt makes me a bit weary, but this only seems to happen under heavy ApacheBench testing with a high number of concurrent threads. The hangs of Apache under heavy load on my test system, even when no mod_rails is involved might indicate this isn’t even a mod_rails problem. I don’t see this being an immediate issue under normal circumstances.

Thank you Phusion! (I don’t like the logo though)

One Response to “mod_rails – first impressions”

  1. 赖洪礼的 blog » Passenger (mod_rails): community response, InfoQ interview, Says:

    […] lots and lots of people have blogged about us, including even O’Reilly. The feedback has been overwhelmingly […]