How to execute request-specific tasks after page response is returned. Does hook_exit() actaully do this?

Question

I'm trying to figure out if it's possible to "hide" the perceived execution time of some end-of-request logging tasks that are page specific and depend on the availability of the Drupal DB API. Essentially I'd like to run these tasks after the page response is returned in full to the browser. I've always just assumed that hook_exit() was the right choice for this kind of thing but after looking at its invocation within drupal_page_footer() in some detail, I'm not so sure. Here's the notable snippet from drupal_page_footer():

module_invoke_all('exit');

// Commit the user session, if needed.
drupal_session_commit();

if (variable_get('cache', 0) && ($cache = drupal_page_set_cache())) {
drupal_serve_page_from_cache($cache);
}
else {
  ob_flush();
}

So it looks like both cached and un-cached responses are not sent to the browser until after all hook_exit() implementations run (flushing the buffer and executing drupal_serve_page_from_cache() both happen after module_invoke_all('exit')). This seems a bit contrary to the hook_exit() documentation which states that, "This hook MUST NOT print anything because by the time it runs the response is already sent to the browser."

Am I perhaps misinterpreting the way hook_exit() implementations work in relation to the response delivery? If not, is there some alternative way to trigger custom logging logic later in the response (while DB access is still available)? Perhaps by registering a shutdown function or something to that effect?

Answer 1

You're looking for fastcgi_finish_request(). Recommend using it inside of a shutdown function. If you need something else the HTTPRL module should be able to do what you need with threading.

Answer 2

I want to follow-up on this with an answer to my own question. This just expands on the already accepted answer.

For anyone wanting to achieve this in a reusable module, that may be implemented on multiple environments, a simple call to fastcgi_finish_request() will of course not be possible as there is no guarantee that FastCGI is being used. That said, it still looks like fastcgi_finish_request() is the best option for this when available.

To still leverage some advantage when FastCGI is not available, I've found it's useful to at least attempt to flush all content to the client before running the logging task. This would allow the browser to begin displaying content, start fetching any render-blocking js, etc., before the logging happens. It would not allow the connection to be closed, as fastcgi_finish_request() would do (so DOM ready events would still be held up), but it still seems better than not doing anything at all.

Here's what I've been testing in my shutdown function (this would only be applicable in a shutdown function and would not work in any hook implementations):

/**
 * Shutdown function used for logging purposes.
 */
function mymodule_shutdown() {
  // Try to ensure that our logging happens after the page content has been sent
  // to the browser, and ideally after the connection is closed.
  // fastcgi_finish_request() is our best option as it's designed for exactly
  // this purpose, but php may not always be running under FastCGI. As an
  // alternative we just force buffers to be flushed (this will not close the
  // connection but it will at least get the page content pushed out).
  if (function_exists('fastcgi_finish_request')) {
    fastcgi_finish_request();
  }
  else {
    flush();
  }
  run_expensive_logging_task();
}

There is some useful info in this post about all this as well. I can't be too sure if calling flush() alone will always do the job as there are some indications that output buffering must be explicitly killed (ob_end_flush()) as well. However, in the context of a Drupal shutdown function it seems like this is unneeded as wrapping-up all the output buffering stuff was likely handled by core already. Of course if fastcgi_finish_request() is used it takes care of all this in one line.