On Tue, Mar 25, 2008 at 11:53 AM, Zed A. Shaw <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Mar 2008 08:21:52 -0700 > "Scott Windsor" <[EMAIL PROTECTED]> wrote: > > > Right now, my processes aren't gigantic... I'm preparing for a 'worst > case' > > scenario when I have a extremely large processes or memory usage. This > can > > easily happen on specific applications such as an image server (using > image > > magick) or parsing/creating large xml payloads (a large REST server). > For > > those applications, I may have a large amount of memory used for each > > request, which will increase until the GC is run. > > Well, does that mean you DO have this problem or DO NOT have this > problem? If you aren't actually facing a real problem that could be > solved by this change then you most likely won't get very far. Any > imagined scenario you come up with could easily just be avoided. Right now my current deployment configuration for all my rails applications is using apache + fastcgi. With this deployment strategy, if I don't set the garbage collection in my dispatch.fcgi, any rails application I use that uses image magick (for resizing/effects/etc) eats memory like a hog. In my dispatch... http://dev.rubyonrails.org/browser/trunk/railties/dispatches/dispatch.fcgi I usually set this to around 50 executions per gc run and my rails apps seem pretty happy. This has been working great for me thus far, but using mod_fastcgi leaves zombies processes occasionally during restart. Checking in with the docs, mod_fastcgi is more or less deprecated, and mod_fcgid is prefered. mod_fcgid has all sorts of issues (random 500s and the like), and to boot the documentation is quite poor. So, I've decieded to move my apps over to using nginx with proxy with mongrel. The decsion to move the nginx is pretty minor (it's lighter weight and easier to configure), but my decision to move to mongrel warrented a bit of research. I do want to ensure that all of my applications behave properly in terms of memory consumption and the first thing I've noticed is that mongrel doesn't have the same options available for customizing when the GC runs. This leads me to believe that either there's something specific to rails running under FastCGI that requires the GC to disabled/enabled during processes execution or mongrel hasn't implemented the feature yet. > > If you want to do this then you'll have to write code and you'll have > to learn how to make a Mongrel handler that is registered before and > after the regular rails handler. All you do is have this before handler > analyze the request and disable the GC on the way in. In the after > handler you just have to renable the GC and make it do the work. > > It's pretty simple, but *you* will have to go read Mongrel code and > understand it first. Otherwise you're just wasting your time really. -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > Sounds good to me - I don't mind writing code, I just want to see if I do spend the time if it's something the mongrel community would accept... Quick question about the code change.... Counting the number of processes served and determining the GC behavior should be done inside a mutex (or we start to run the risk of running the GC twice or mis-counting the number of requests processed). I don't see any common mutex used for all mongrel dispatchers, but the logic is specific within each type of http handler (rails, camping, etc). Would it make sense then to put the optional GC run check (and GC run, if applicable) within the syncronize block for each http handler or is the something that should live in the base HTTPHandler class? - scott
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
