Last night we released our preview site, which was built using Ruby on 
Rails (http://twinkler.43things.com).  We are continuing to look into 
improving performance, but the site feels pretty responsive as it is.  
The time spent generating the home page is currently split about 60% on 
database queries and 40% on rendering.

The two most critical things we did to improve performance were:

1) Run as FastCGI with the C fcgi extension.  The startup time for 
Rails isn't trivial, and the database introspection used by 
ActiveRecord requires an additional query to the database per table to 
get column metadata.  With FastCGI you don't incur these costs on every 
page serve.

2) Use the C mysql extension.  This doubled the speed of processing the 
database queries.

Developing in CGI mode using the default pure Ruby mysql driver will 
feel very sluggish.  Don't let that fool you into believing that's how 
the production application will perform.

In the end, however, good design will be more important than the 
framework in determining how your application will perform.  Think 
carefully about the database design and how the tables are indexed.  
Analyze the data access patterns and consider some strategic 
denormalization of data.  Look for opportunities to cache preprocessed 
data.

Rails has a lot of powerful features to make it easy to quickly 
prototype and develop applications, which will leave more time to think 
about the application's feature set and how to tune it for performance.

-Bob.


On Nov 19, 2004, at 7:25 AM, James Britt wrote:

> Curt Hibbs wrote:
>
>> Mark VanOrman wrote:
>> ...
>>> 1- can Ruby handle such a mission critical applications as far as
>>> reliability and speed?
>>>
>>> 2- Are there any benchmarks out there that compare PHP to Ruby?
>>>
>>> 3- From your experiance, would you think it's better to develop an
>>> application like this as a cgi(people would post transes to
>>> apache) or as a
>>> standalone server(post directly to ruby)?
>> If you use Ruby on Rails (http://rubyonrails.org/), you can prototype 
>> the
>> critical pieces of your application *very* quickly. This would allow 
>> you to
>> measure the performance directly and quickly determine whether or not 
>> your
>> critical issues are going to be a problem. Its better to know than to 
>> guess
>> (especially when you can do so with very little investment of time).
>
>
> How does Rails do on speed?  I recall a thread here some months ago on 
> this, with doubts on Rails response time.  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).
>
> Now, I've been largely following the tutorial, cutting and pasting 
> code, and tweaking things around to get a better sense of how Rails 
> works. There may be any number of parameters or settings I can change 
> to improve things, and I've not written a non-Rails MySQL version for 
> comparison, so all of my benchmarks are, um, vague and based largely 
> on intuition.  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.)
>
> 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?
>
> Thanks,
>
> James
>