On Fri, Mar 21, 2008 at 11:49 AM, Kirk Haines <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 21, 2008 at 12:12 PM, Scott Windsor <[EMAIL PROTECTED]> > wrote: > > Sorry, for the re-post, but I'm new to the mailing list and wanted to > bring > > back up and old topic I saw in the archives. > > > > http://rubyforge.org/pipermail/mongrel-users/2008-February/004991.html > > > > I think a patch to delay garbage collection and run it later is pretty > > important for high performance web applications. I do understand the > > In the vast majority of cases you are going to do a worse job of > determining when and how often to run the GC than even MRI Ruby's > simple algorithms. MRI garbage collection stops the world -- nothing > else happens while the GC runs -- so when talking about overall > throughput on an application, you don't want it to run any more than > necessary. > > I don't use Rails, but in the past I have experimented with this quite > a lot under IOWA, and in my normal applications (i.e. not using > RMagick) I could never come up with an algorithm of self-managed > GC.disable/GC.enable/GC.start that gave the same overall level of > throughput that I got by letting Ruby start the GC according to its > own algorithms. That experience makes me skeptical of that approach > in the general case, though there are occasional specific cases where > it can be useful. > > > Kirk Haines I understand that the GC is quite knowledgeable about when to run garbage collection when examining the heap. But, the GC doesn't know anything about my application or it's state. The fact that when the GC runs everything stops is why I'd prefer to limit when the GC will run. I'd rather it run outside of serving a web request rather then when it's right in the middle of serving requests. I know that the ideal situation is to not need to run the GC, but the reality is that I'm using various gems and plugins and not all are well behaved and free of memory leaks. Rails itself may also have regular leaks from time to time and I'd prefer to have my application consistently be slow than randomly (and unexpectedly) be slow. The alternative is to terminate your application after N number of requests and never run the GC, which I'm not a fan of. - scott
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
