使用NGINX微型caching我已经有了非常好的性能结果。
但是，我仍然不确定如何最好地处理具有Set-Cookie头的服务器响应。
Set-Cookie头的响应吗？ 如果答案是否定的， Set-Cookie响应应该总是绕过caching层，这会对性能产生负面影响。
例如，当您访问运行WooCommerce的avarege电子商务网站时，这些cookie将在您的第一个visti上设置：
设置Cookie：PHPSESSID = XXYY
设置Cookie：wp_woocommerce_session_xx = YY
如果Set-Cookie响应被排除在caching之外，这意味着caching的内容永远不会在任何电子商店中首次访问。
另外，在WooCommerce商店上浏览产品时，插件会设置woocommerce_recently_viewed=xxxx cookie。 woocommerce_recently_viewed cookie将在每个产品视图上更新，以便随后对其他产品的请求将导致服务器包含Set-Cookie标头。
我在NGINX中使用的一些默认cachingconfiguration包括：
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $skip_cache 1; }
如果我在列表中包含woocommerce_recently_viewed cookie，则大部分时间内caching将被woocommerce_recently_viewed 。
一般而言，caching对dynamic内容效果不佳， 特别是对于包含“最近浏览过的内容”的内容，这些内容会改变每个单页的加载。 如果你真的想要使用caching，那么第一步就是禁用这个插件，这样就有理论上有人可能会被同一个页面服务两次。 第二步是只有在有人做某事需要一个时才开始一个会话：login，将一个物品放入购物车等等。从这一点开始，一旦创build了会话cookie，就必须停止caching（否则，如果客户只访问caching一段时间，会话将在客户端和服务器端都到期）。
我认为像这样的caching最好是在应用程序本身完成。 应用程序应该了解网页的哪些部分是dynamic的，需要在每次页面加载时重新生成，并且可以将网页从新部件和使用过的部件组装起来，以便为用户提供正确的响应。
DerfK对于整个页面级别的dynamic内容是正确的，你绝对不希望发生cookie泄漏。
不过，你可以在上游层做更多的caching – 特别是WordPress，它有一个体面的可插入对象caching。 这意味着，虽然页面本身不会被caching，但是可以将大部分数据库负载存储在临时存储中，例如memcached（batcache）或redis。 这些KV商店比MySQL快得多，并且因为它们在对象和应用程序级别上工作，所以它们不直接受到WooCommerce发送的Cookie的影响。