tag:blogger.com,1999:blog-8397311766319215218.post4890367200737136893..comments2012-01-20T00:57:44.840-08:00Marcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8397311766319215218.post-66346814820974227782012-01-20T00:57:44.840-08:002012-01-20T00:57:44.840-08:00Hi Jonah, thanks for the tips. I had looked at 'production' before, but it seems to assume that you will then create a whole production environment, which seems a little overkill. I'll see what I can do with your advice.Marcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-7626041800286849902012-01-18T10:50:26.687-08:002012-01-18T10:50:26.687-08:00That is very slow. I hesitate to speculate too much about your app configuration but one place to start is to check which rails environment you stared your server in. `rails s` will default to the development environment which is very handy during development but completely useless for determining what sort of load the framework can support. Among other things the development environment configuration sets `config.cache_classes` and `config.action_view.cache_template_loading` to false by default. That means that on every request to a development environment the server not only re-renders the view templates from scratch but also reloads every class it uses to do so! Very convenient when it allows you to edit a class and pick up the changes on the next request without requiring a server restart but no way to measure the performance of your application. Use `rails s -e production` to start the app using your production environment (environment settings are defined in `config/environments/*.rb`) and see what a difference that makes.Jonahhttp://www.blogger.com/profile/12910127474063415275noreply@blogger.com