Runs GC after requests, after closing the client socket and before attempting to accept more connections.
This shouldn't hurt overall performance as long as the server cluster is at <50% CPU capacity, and improves the performance of most memory intensive requests. This serves to improve client-visible performance (possibly at the cost of overall performance).
Increasing the number of worker_processes may be necessary to improve average client response times because some of your workers will be busy doing GC and unable to service clients. Think of using more workers with this module as a poor man's concurrent GC.
We'll call GC after each request is been written out to the socket, so the client never sees the extra GC hit it.
This middleware is only effective for applications that use a lot of memory, and will hurt simpler apps/endpoints that can process multiple requests before incurring GC.
This middleware is only designed to work with unicorn, as it harms performance with keepalive-enabled servers.
Example (in config.ru):
require 'unicorn/oob_gc' # GC ever two requests that hit /expensive/foo or /more_expensive/foo # in your app. By default, this will GC once every 5 requests # for all endpoints in your app use Unicorn::OobGC, 2, %r{\A/(?:expensive/foo|more_expensive/foo)}
Feedback from users of early implementations of this module: