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/
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
