The twenty-worker illustration and the "thousands of cached hits per second" figure sit close together in the post, and converting them to the same units is where the layer argument gets its edge. [9] [11] Average service time equals concurrency divided by throughput. Twenty PHP-FPM slots at a thousand requests a second gives each plugin-served cache hit 20 ms to complete; at two thousand a second it gets 10 ms. [19] All of that budget is spent before your saved HTML moves: a process spawn, an interpreter boot, then the drop-in itself. [4] Nginx has none of it to do on a hit, because PHP-FPM is never invoked and wp-load.php never runs. [5]
This is also why a single-request timing test is the wrong instrument. The author is explicit that under ordinary traffic the gap barely registers on a stopwatch. [6] A plugin's benchmark table measures a request that gets a worker slot immediately; the ceiling is about the requests that do not. [7] [8]
The Nginx throughput number is the author's, for his hardware, and the post carries no before-and-after measurement from the migration itself. [11] [20] For it to transfer you need the cache store answered from memory rather than off contended storage, response bodies small enough that you are not bandwidth-bound, and nothing upstream doing work on a hit. Treat it as a shape rather than a spec.
The cart exclusion is the part I would budget real time for. A blanket bypass keyed on woocommerce_items_in_cart or the session cookie reads as though it means "this visitor has a cart". [13] WooCommerce often sets that cookie on the first page load, well before any add-to-cart, and it then persists for the session. [14] So the rule is firing on a cookie that mostly records having met the shop. Every later page for that visitor is uncached, sitewide, and uncached TTFB on a WooCommerce store runs into seconds once unindexed postmeta queries or a cold object cache are involved. [15] [16]
The recommended route is to stop treating cart state as a caching signal at all. wc-cart-fragments.js refreshes the mini-cart, the item count and the totals over a light AJAX call after the page loads, through the woocommerce_add_to_cart_fragments filter. [17] That holds when the theme actually uses the mechanism, which the author says to verify rather than assume. [18] The contrapositive is the migration task: any header rendering the item count in PHP makes the HTML vary by cart state, and the cached copy will be wrong for someone. Check the theme before the Nginx config, not after.
What does not disappear is PHP-FPM. Logged-in sessions and checkout still need workers, and the change is that cache hits stop competing with them for slots. [10] You still size the pool, and now you size it for the traffic that takes money.
