Home/ Questions/Q 585893
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:03:01+00:00

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

  • 0

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?)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0