Nginx Microcache on drupal commerce product display

We have a giant global.inc file in BOA to handle all exceptions like this.

Not sure if we should incorporate some of them in Aegir directly, if Nginx with microcaching is used?

Note that you could also add in your affected site's local.settings.php this snippet:

/**
 * Custom Speed Booster TTL override, for example to force no-cache
 * on some selected URLs which need to be excluded to always provide
 * dynamic results.
 */
 if (preg_match("/^\/(?:foo|bar)/", $_SERVER['REQUEST_URI'])) {
   header('X-Accel-Expires: 1'); // This disables Speed Booster
   $conf['cache'] = 0; // This disables page caching on the fly
 }

You could do the same for all POST and AJAX requests, and in BOA we even set special cookie when visitor submits a form, adds an item to the cart, etc, to prevent Nginx from displaying a cached page.

I've actually seen microcaching cause more issues than it's intended to solve.

Here are some pros and cons of microcaching:

Pro:
Prevent anonymous users/bots from crushing your server by accessing the same page thousands of times.

Con:
Caches pages for anonymous and non-anonymous users that Drupal doesn't want cached. "fastcgi_ignore_headers Cache-Control Expires;", I'm looking at you.

Con:
Does NOTHING about bots hitting thousands of unique pages across your site. Each unique path will be faithfully served, cached, uncached after 10 seconds, while your server load spikes.

Con:
Does nothing about authenticated users or users that have submitted a form (w/ cookie_cache_bypass) hitting the site thousands of times. We have actually had the server load driven into the 100+ range because a site admin held down the F5 key after logging in. A cat could take your server down.

Con:
Overrides Drupal cache lifetimes - if you want pages cached for a day, you still only get 10 seconds.

Partial solutions and caveats:

• Something like cookie_cache_bypass, that sets a NO_CACHE cookie, but that prevents ANY AND ALL pages being cached, even when we want them cached.
• Adding specific paths to exclude from microcaching (/batch/, /ajax/, /js/, etc...) - this is laborious, and there's no good way to customize the nginx configs to add more cache exclude paths without aegir rewriting them whenever it is upgraded. This also prevents microcaching for these paths, even for DDOS.

Should we explore some new concepts for caching and configuration?

• nginx rate limiting.
• ability to turn off microcaching altogether, or on specific sites.
• allow simpler configuration by including nginx configs from more paths (like how pre.d picks up site configs, but to allow additional map {}, location {}, blocks. This would make something like letsencrypt support as simple as adding a config file into a specific directory.

I agree that the way it's implemented in a vanilla Aegir currently is problematic. I think it was added in the past without fully realizing that it needs more complete approach to be actually useful, as we do it in BOA for years.

BOA fixes all cons you have listed, and comes with far more advanced capabilities, like ability to configure custom settings and/or overrides per site or per platform, on the fly, via site and platform INI files, which are interpreted in the logic we have in the global.inc

BOA also supports extra Nginx overrides/includes, if needed. Note that you can't use the map directive there, because it's accepted only in the higher http config context.

We could perhaps look into possibility to backport some BOA solutions, although not everything could be directly backported. For example, we are using a custom Perl and Bash monitoring scripts integrated with CSF firewall for automatic DoS and system load protection, on the Nginx level.