running GC outside of request

[milandobrota]

Since Ruby garbage collection blocks the current process in order to
optimize the response time I thought it would make sense to make
garbage collector run outside of a request processing logic. I tried
different things, however In this case I am running GC every X
requests. This is what I have so far in my rails app:

# config/initializers/passenger_oobgc
module PassengerOobGC

def self.install!(interval = 5)
@@oobgc_interval = @@oobgc_requests_to_go = interval
PhusionPassenger::Rack::RequestHandler.send :include, self
end

def self.included(base)

base.send :alias_method_chain, :accept_and_process_next_request, :gc
end

def accept_and_process_next_request_with_gc(socket_wrapper, channel,
buffer)
response =
accept_and_process_next_request_without_gc(socket_wrapper, channel,
buffer)
if (@@oobgc_requests_to_go -= 1) <= 0
@@oobgc_requests_to_go = @@oobgc_interval
GC.start
end
response
end
end

if defined?(PhusionPassenger::Rack::RequestHandler)
PassengerOobGC.install!(10)
end

Now since individual requests do take ~10% less time, when I run them
one after another the worker picks up the new request while still
doing garbage collection. Is this because the TCP socket has been
closed (I was intentionally waiting for the response to get sent back
so the GC happens asynchronously)? Are there any other ways around
this?

[Jay Levitt]

This looks similar to the OobGC posted here:

http://stackoverflow.com/questions/6221942/is-there-an-easy-way-to-run-garbage-collection-outside-of-the-request-cycle-in-pa/7392436#7392436

Is there a meaningful difference between your use of accept_and_process_next_request vs. its use of process_request?