> How does Rails do on speed?  I recall a thread here some months ago on 
> this, with doubts on Rails response time.

This thread came about from a guy that had misconfigured his setup and 
where using CGI. It never represented the reality of performance with 
Rails.

> I've been trying out a small app using Rails, and I'm struck by how 
> long to takes to do trivial searches (basically, my app is essentially 
> the Friends/Phones example in the rubyonrails.org site tutorial).

Look in your logs: tail -f log/production.log. It's very easy to spot 
where your bottleneck. Perhaps it's a bad SQL query operating on a 
table with two many rows and no indexes.

But as long as you're just on CGI or WEBrick with cached classes turned 
off, be prepared that getting 1 req/sec is par for course on a 
reasonable modern machine. On old crusty hardware, it'll be even worse.

Rails trade start-up time for productivity big time. The good news is 
that start-up time doesn't matter any where but in production, so it's 
a trade well worth making.

> I've run the Rails code as both CGI and under WEBrick (the two options 
> I have for production), and no have to starting looking how to speed 
> things up.  (Or go back to my initial Madeleine approach.)

WEBrick is pretty capable as a production server for small systems. All 
you need to do is turn on cached classes:

$ ruby public/dispatch.servlet --help
Usage: ruby dispatch.servlet [options]

  -p, --port=port                  Runs Rails on the specified port.
                                   Default: 3000
  -b, --binding=ip                 Binds Rails to the specified ip.
                                   Default: 127.0.0.1
  -i, --index=controller           Specifies an index controller that 
requests for root will go to (instead of congratulations screen).
  -d, --daemon                     Make Rails run as a Daemon (only 
works if fork is available -- meaning on *nix).
  -c, --cache-classes              Caches class compilation which will 
speed up the serving of requests, but require a server restart on 
source changes.

  -h, --help                       Show this help message.

So starting the WEBrick dispatcher with "ruby public/dispatch.servlet 
-c" should give you very comfortable performance. Of course, you'll 
then need to restart the WEBrick server on code changes. But you have 
to do that in any of the production environments anyway.

> If someone is heading off to write a speed-critical app on Rails, what 
> are some things to do right off the top to avoid false impressions 
> about speed?

Any of the three production environments will give you plenty of 
performance to handle the majority of applications (at 30 req/sec, you 
can handle 2.6 million requests per day).

So in the production environments, it's unlike that the framework is 
holding you back. It's much more likely that you'll construct your 
application in ways that aren't very friendly to performance.

These concerns doesn't have much to do with Rails. They apply to all 
applications (especially ones interfacing with the database). One of 
the most common mistakes is to do n*m queries. Fetching 30 records that 
each need to fetch 3 of their own, so you get 30*3 = 90 SQL statements 
for a single request.

Active Record gives you a very convenient way of routing around that 
problem called "piggy-back queries". I discuss their usage in detail on 
http://www.rubyonrails.org/show/PiggyBackQuery

At the end of the day, there's only one thing that's going to help you 
deal with performance problems: benchmarking and profiling! Rails give 
you a rough estimation at the first part with the automatically 
configured logs and Ruby makes the second part fairly easy as well.

Performance is one of those areas where intuition is most badly 
applied. I can't count the number of times I was sure that the 
bottleneck was in one part of the code and then benchmarking/profiling 
proved me silly wrong.

Never make decisions about optimizations based on intuition. It's 
considered harmful.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain