[racket] garbage collection and process idling

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/