On Sep 1, 2006, at 8:58 AM, Ezra Zygmuntowicz wrote: > HI~ > > On Sep 1, 2006, at 7:07 AM, Kirk Haines wrote: > >> On 9/1/06, Tim Perrett <[EMAIL PROTECTED]> 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].
Gah! Sorry forgot to include a link in the last email: [1] http://railsexpress.de/blog/articles/2006/08/15/rails-template- optimizer-beta-test#comments -Ezra _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
