This site is dedicated to further knowledge about creating Ruby on Rails applications professionaly. We discuss Ruby on Rails features from a performance angle, discuss Ruby on Rails performance analysis methods, provide information on Ruby on Rails scaling and benchmark Ruby on Rails performance for each release. We discuss best practices for selecting Ruby on Rails session containers, fragment and page caching and optimizing database queries.

Performance related changes in Rails 1.1

Posted 03 Apr 2006

In addition to being packed with new features and also some forgotten ones, the recently released Rails 1.1 contains a number of performance related changes. For some cases, you will see significant improvements.

The components implementation received a complete refactoring, making it both faster and simpler to use.

  1. inside a controller you can easily determine whether your current action is being run on behalf of an embedding controller by calling component_request?
  2. session and flash information will now be passed on from the embedding controller to the component. As a consequence, it is no longer necessary to save session information to the session container before a component action is invoked by the embedding controller. For pages embedding n components, this saves n session queries and updates, reducing DB load significantly if you use ActiveRecordStore or MysqlSessionStore.
  3. It is also possible to specify the controller as a class constant, bypassing the inflector code to compute the controller class at runtime. So 
    render_component :controller => "greeter",
                 :action => "hello_world"
    becomes 
    render_component :controller => GreeterController,
                 :action => "hello_world"

Due to the component refactoring, it is no longer necessary to save newly created sessions twice. This has the biggest impact for people using ActiveRecodStore.

We have changed the default for ActiveRecord::Base.allow_concurrency from true to false, since almost all apps run in a single threaded request container. In addition, you can now safely set ActiveRecord::Base.allow_concurrency in environment.rb or any other config file.

Connection cache management got a serious overhaul. Previously, the connection cache was emptied after each request, in order to solve problems with dropped database connections. You can now use lazy connection verification by setting ActiveRecord::Base.verification_timeout to a number of seconds timeout interval. It defaults to 0, to be compatible with the previous release. However, I strongly recommend setting it to a higher value, for a simple reason:

Dropped database connections occur mostly on sites not seeing traffic for the database internal connection timeout period. High traffic sites will see them rarely. However, for high traffic sites, reducing the number of database accesses by setting verification_timeout to a value slightly below the database internal value will result in a significant reduction of DB requests. For example, if you use memcached for session management, the DB won't see any hit for action cached pages.

Additionally, the connection cache size was reduced from the number of ActiveRecord classes involved in a query, to the number of active database connections. So for most applications this means that instead of retrieving and verifying n connections, at most 1 retrieval and verification will occur, and only when the timeout interval has passed.

Update: the correct way of determining whether you're in a component request is calling component_request?. In a view you can call controller.component_request?

Posted in performance | Tags performance

Comments

blog comments powered by Disqus