[racket] garbage collection and process idling

Er, and maybe add to that scheduled GC strategy a sense of how 
worthwhile we think a GC might be at that time, so that we're not just 
doing, e.g., a GC 1 second after each request in a lightly-loaded 
system, potentially delay service to the next request when GC wasn't needed.

Neil Van Dyke wrote at 10/17/2010 07:00 AM:
> Thanks for the info and ideas.
>
> Since my app is Web server-like, I suspect that the thing to do in the 
> app for now to try to avoid GC delays when the app is non-idle (i.e., 
> is servicing one or more requests) is to trigger a GC at the point 
> that an app has been idle for N seconds.
>
> N might be 1 second, or it might vary, such as based on recent traffic 
> levels or on learned info of whether  new requests were backed up 
> after previous scheduled GCs were performed.  I would probably start 
> with a simple 1-second N and see how that went, until I had more info 
> about whether and when GCs were happening when we didn't schedule 
> them, and an idea of whether we could improve upon that by scheduling.
>
> Also, if GC was the cause of the 0.2 second difference I saw in median 
> request time between the automated pounding testing and manual 
> interactive testing, then I suspect that the difference is in *number* 
> of requests: the manual testing simply didn't achieve the quantity of 
> requests that would be triggering GCs.  0.2 second is not a big deal 
> occasionally, but I suspect that when the GCs do hit, the delays are 
> more in the neighborhood of 1 second, which would be noticeable when 
> requests are normally handled in less than a second.
>

-- 
http://www.neilvandyke.org/