Why is my sinatra website so slow?

Question

After asking this question, I started using Sinatra as a way to serve web pages.

This evening, a friend of mine and I started to test the speed of the server.

The file to log in looks like:

require 'rubygems'
require 'sinatra'
require 'haml'

enable :sessions #for cookies!

get '/' do 
  haml :index 
end

And the index.haml looks like:

%title
  First Page

%header 
  %h2 First Page

He's sitting on a recent laptop, as am I, with an Apple 802.11n router between the two of us. We're both running Windows 7. I've also tried these same files on a laptop running Ubuntu 9.10 x64 with Sinatra and all relevant files installed from apt-get.

Sinatra is taking 7 seconds to serve up a single page request, no matter the server OS, Windows or Linux. I see that here the author managed to get over 400 requests/second processed. What gives? (or should this be on SuperUser or the like?)

Answer 1

I'll set aside any opinions on when you should optimize your web application.

Set up different configurations in your Sinatra app for development and production because some of these suggestions, you won't always want to use. In fact, you should probably go ahead and setup and environment similar to how you would deploy in production. You would not deploy by simply running ruby app.rb. You'd want to put apache or nginx in front of your Mongrel. Mongrel will serve up your static files, but that's really only advisable for development mode. In deployment, a web server is going to do a lot better job for that. In short, your deployed environment will be faster than your standalone development environment.

At this point, I wouldn't worry about Mongrel vs. Thin. If Thin is twice as fast - it isn't - then your 7 seconds becomes 3.5. Will that be good enough?

Some things to try ...

I know I just told you to set up a deployment environment, but maybe it's not the server side. Have you tried running YSlow or PageSpeed on your pages? I/O is going to take up more of those 7 seconds (Disclaimer: I'm assuming that there's nothing wrong with your network set up) than the server. YSlow - Firebug actually - will tell you how long each part of your page takes to get to the browser.

One of the things that YSlow told me to do was to put a far forward Expires header on my static assets, which I knew but I was leaving optimization until the end. That's when I realized that there were at least 3 different places that I could specify that header. I'm convincing myself that doing it in nginx is the right place to put it.

If you're happy with those results, then you can look at the server. Off the top of my head, so not exhaustive

1. Turn on gzip responses.
2. Combine your stylesheets so there's only one per page request. There may be some Rack Middleware for this, if you don't do it manually.
3. Cache. I'm trying Rack::Cache.
4. Use sprites to decrease the number of image downloads you use.
5. Minify your Javascript. Again, maybe via Rack Middleware.

Rack Middleware is neat, but it uses CPU. So, manually minifying your Javascript adds a new step to your workflow, but on the server, it's faster than Middleware. It's a tradeoff.

Sorry if this was rambly.

Answer 2

I had this problem when running Sinatra with shotgun but not when running my app directly (i.e., ruby -rubygems app.rb). This is because shotgun forks and reloads the application for each request.

I found a thread in Sinatra's mailing list which discussed this issue and people there advised using rerun instead of shotgun. I'm happy to say it solved this issue for me.

Answer 3

Try using Thin as the server. I noticed an increase in performance compared with WEBrick and Mongrel.

gem install thin

When you run your app using ruby TestServer.rb you'll see the following:

Sinatra/0.10.1 has taken the stage on 4567 for development with backup from Thin

Answer 4

I'm running Sinatra inside VMWare Fusion with Vagrant. My app was running slowly (about ten seconds to service a request). Then I found this gem:

Webrick is very slow to respond. How to speed it up?

It seems that WEBrick was (by default) configured to reverse dns lookup on every request, and that was slowing it down.