tags:

views:

788

answers:

2

Hi,

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

+1  A: 

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

Trevor
The sinatra version I get from gem is 0.9.4; should I be getting some other, more recent version as well?
mmr
I got version 0.10.1 from github. gem install sinatra-sinatra --source=http://gems.github.com
Trevor
just as a side note, thin does not work on windows without nmake (ie, no windows 64-bit version, apparently). Mongrel should work just fine.
mmr
+3  A: 

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.

dbrown0708
Thanks for the thorough response! You lost me at 'far forward Expires header', after that, I learn the depths of my ignorance. I have a lot of catching up to do, I think.
mmr
It's a term I picked up from the Yahoo! YSlow site. http://developer.yahoo.com/performance/rules.html. It just means to set the Expires header to some point far in the future. Like 20 years, say.
dbrown0708
I'm choosing this as the answer purely because it lead to learning a lot about optimization once I got past Hello World. The fix, in this case, was to turn of debugging in webrick.
mmr
"I'll set aside any opinions on when you should optimize your web application." - pffft, he was getting 0.14 request/second for a trivial implementation, of course he should investigate it now.
MegaHAL