Hi Luis, I wasn't blaming mongrel for the performance problems in general. I realize that we need to look at the Rails application as well.
My question was more along the lines of whether we would see any _additional_ gains in using a newer version of mongrel. Thanks for all your points. Matthew On 25.02.2008, at 17:22, Luis Lavena wrote: > On Mon, Feb 25, 2008 at 6:57 AM, Matthew Langham > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> we have a project where mongrel 1.0.1 has been in use in production >> for a few months now. Everything works fine except we run into marked >> performance problems if the setup has been running a couple of weeks >> without a restart. The general performance slows down quite a bit but >> restarting everything brings it back to normal. >> >> So we are looking at areas that could be relevant and therefore >> considering upgrading mongrel to 1.0.5. >> >> Can anyone provide insight on whether this could help our performance >> issues? >> > > Maybe no-one will comment this, but most of the "long running process" > problems are not (directly) Mongrel related, but Rails related. > > It seems quite common blame Mongrel because it hides behind a simple > "mongrel_rails" script or a cluster of mongrels. But after all, > mongrel is running your Rails application. period. > > Mongrel offers to Rails a layer to process the HTTP protocol and serve > the CGI-like information to the Rails Dispatcher, nothing more, > nothing less. > > If you don't provide/create custom handlers (in mongrel) that's the > most Mongrel do for Rails. > > I've seen several memory leaks from Rails, and tried to pinpoint some > of them, ended repeating the work done in the past by others but that > never got integrated into Ruby or Rails core. > > Like, for example, the Benchmark::realtime "abuse" that Rails do and > the huge amount of memory it allocated in the past (now fixed in Ruby > trunk and 1_8 branch). > > Migrating to Mongrel 1.0.5 wouldn't fix that, and you will keep > blaming Mongrel for the problem. > > I'll suggest you plan a monit/god sweep and respawn strategy for your > rails processes. > > Besides that, guess is time for you to start looking at things your > application is using to became slower with the time: > > - Use of image processing plugins/extensions/gems like RMagick > - Files opened without proper closing (File.open without a block or > file#close after use of it). > - String concatenation using += instead of << > - Misused queries over associations in your ActiveRecord models (use > of length to determine the size of a associated array instead of > .size). > > Those are the more common mistakes. > > HTH, > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-users mailing list > Mongrel-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > ---- Matthew Langham Geschäftsführer / Managing Director Tel: +49 (0) 5251 6948 293 Mobile: +49 (0)172 5749305 Indiginox GmbH Frankfurter Weg 6, 33106 Paderborn, Germany HRB Paderborn 8130 Geschäftsführer / Managing Directors: Matthew Langham / Ashley Steele _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
