This really should be titled "How Ruby on Rails Could Be Much Better for Shared Hosting", as that's where the issue really was for Dreamhost at the time. In a s

This really should be titled "How Ruby on Rails Could Be Much Better for Shared Hosting", as that's where the issue really was for Dreamhost at the time. In a shared hosting environment back then: * You didn't get root shell access. Dreamhost were (and still are) one of the good platforms in that they allowed shell access at all. Many shared hosting platforms didn't even do that, requiring you to upload files using FTP. * The services provided were generally ones where a single server process (or processes) could serve a large number of shared hosting tennants: a web server with many virtual hosts, PHP applications running within that shared web server, jabber services, mail services, etc. * All web server configuration was either through the control panel or .htaccess files, because you were sharing the web server instance with everyone else on your shared server. * The economics of shared hosting meant you couldn't keep processes running for each individual hosting user for an extended period of time: memory was just too expensive to dedicate that way. Rails didn't really fit this model: a production Rails app loads all the code in to memory and then expects to run for a number of hours serving requests. Shared hosting required these processes to shut down when there was no traffic to the site, and then start up on demand when a new request for the app came in. So the fundamental problem was not "Ruby on Rails needs to be a helluva lot faster", it was "Rails is too slow to start up to serve a single HTTP request and then be shut down again". I did run a production Rails app on Dreamhost shared hosting for a while: it seemed to receive just enough traffic not to get killed, but not so much that it became an issue. But as soon as virtual server hosting became cheap enough to make the jump, we moved.