[Mongrel] Application performance

Ezra Zygmuntowicz ezmobius at gmail.com
Fri Sep 1 11:58:09 EDT 2006


HI~

On Sep 1, 2006, at 7:07 AM, Kirk Haines wrote:

> On 9/1/06, Tim Perrett <tperrett at butlerandtanner.com> wrote:
>
>> If im needing to boost performance how might one go about doing it?
>
> 35-38/second can move a lot of traffic, as has been mentioned, so long
> as it's 35-38/second for your dynamic traffic, and your static files
> are much, much faster.
>
> However, when you benchmark 35-38 requests per second, how many
> concurrent requests are you handing?  Can you get 35-38/second with
> one request at a time, or do you need several concurrent requests to
> get that speed?  How long does it take to actually render a page from
> your application, from the time the request goes into Rails to the
> time that it comes out?
>
> That latency can make a big difference in the apparent speed of your
> application, even if your total throughput is good.
>
> As for how to speed up page rendering, is there anything that you
> query from the database that you can cache to avoid db traffic during
> a hit?  That can make a very significant difference.  It doesn't
> matter if you can render 300 pages per second of plain text if, when
> you do the required db activity, the db bottlenecks you down to 10% of
> that.
>
> Within your Ruby itself there are some easy things that can make  
> differences.
>
> If you use inject() anywhere, benchmark that usage.  inject() can be
> elegant as heck, but it's also often as slow as it is elegant, and it
> tends to create a lot of junk objects that have to be garbage
> collected.  It can sometimes be phenomenally slow compared to a
> solution that doesn't use it.
>
> Do you do any string creation, aggregating from smaller pieces?  Use
> << instead of +.
>
> In hash lookups with strings, hash dups the key.  If you give it a
> frozen string it's faster.  If you do a lot of hash lookups this can
> add up.
>
> In general, try to be aware of your frivolous object creation.  Ruby
> isn't terribly slow with object creation, but it's still more
> expensive to use a new object than to reuse an old one, especially
> when garbage collection is taken into account.
>
> But before you spend too much time on any of that, take a look at what
> you can do to cache your database transactions in order to minimize
> them.  If that is the bottleneck, everything else is a meager drop in
> the bucket.
>
>
> Kirk Haines


	Very good stuff Kirk. I'll mention a few things from my attempts to  
speed up rails applications. When you look at a rails app like the  
one being discussed you need to realize that the view templates are  
getting rendered every hit if there is no caching. How heavy are your  
views? Using a ton of link_to and all the other helpers is very nice  
to work with but can kill your performance. I am workign on an app  
with almost no caching and tons of ajax. After benchmarking it turned  
out that rendering the view templates was actually taking around 60%  
of the total time rails spent servicing a request. By switching a  
number of link_to's into <a href>'s and replacing a few other heavy  
helpers with there normal html equivalents and writing some actual  
javascript instead of using too many js helpers really cut down on  
render time. This is one of the most important things to look at in a  
rails app that cannot use caching. I have also had some great  
template speed ups from using Stephan Kaes excellent Template  
Optimizer[1].

	Also if you have controller or view helper, or model methods that  
will get called more then once *during the same request* then use the  
||= operator to cache the results like this:

def get_something
    @something ||= big_calculation_to_get_something
end

	This way only the first call to the method will actually do the  
computation and all the other calls withint the same request will use  
the cached data in the instance var.

	Of course you must look at the db too if you are using heavy  
queries. The development logs can help you see how chatty you are  
being with the database. Sometimes your view need to render every hit  
but if you can cache heavy db queries in memory even every 5 or 10  
minutes can make a huge difference. Look into memcached or a custom  
drb caching solution for this depending on how heavily it will be  
used. Favor memcached if it will play a big role in your app.


-Ezra






More information about the Mongrel-users mailing list