Occupancy is arrival rate times service time. The throughput formula in the dev.to post is a rearrangement of that, and the pool size on the top of the fraction is itself a memory budget [5]. Check the stated range: 60 workers at 70MB is 4.2GB, 100 at 40MB is 4.0GB [16]. Both ends reserve about half of an 8GB box for PHP and leave the rest to Nginx, the database and the kernel [4]. The directive is where you type the number. The RAM is where it comes from.
Now run the mixed case the post skips. Suppose the 1,500 req/sec spike [6] is 90% cacheable reads answered in 20ms [8] and 10% writes and uncacheable endpoints at 200ms [5]. Concurrency is 1,350 x 0.02 = 27 workers for the reads and 150 x 0.2 = 30 workers for the rest, so 57 of 100 are busy [15]. By the post's own arithmetic the in-controller Redis path has 3.3x headroom over the spike it is presented as failing to survive [17]. The narrower claim is the true one: the uncacheable tenth costs more worker-time than the cached ninety percent, and a mean occupancy of 57 is not a safe operating point when service times vary, because queueing starts long before the last worker is taken.
Read the controller code and a second problem shows up. It does a Redis get, and on a miss runs an eager-loaded findOrFail and a setex with a one-hour TTL [9]. There is no lock. Every concurrent request that arrives after that key expires misses, and every one of them runs the query. Request coalescing at the edge is the genuinely good part of the design [11], and it is the same primitive you would otherwise build in PHP with a mutex, which is a duller ticket than a proxy deployment.
The two marquee numbers are claims about someone else's traffic. The 12ms figure [1] holds for a cache hit served from a nearby POP [14]; the bypass path for writes still allocates a worker at full service time [10]. The 95% offload figure [1] requires 95% of requests to be GETs whose responses repeat inside the TTL. For a product catalog that is credible. For an authenticated dashboard, per-user responses fragment the key space and your offload is whatever your cardinality allows. The source measures neither.
Then the adoption cost. The recommended headers are max-age=86400 with stale-while-revalidate=300, plus a vendor-specific X-ApexCache-Tags list emitted by the controller [12]. That moves freshness out of the worker and into your purge path: the tag write on admin update [13] becomes a correctness dependency, and if it fails, a wrong price stays live at the edge for up to a day while origin logs show nothing at all. You are trading a cache lookup you can read in a stack trace for an invalidation contract you have to monitor separately. In a read-heavy catalog with a reliable purge hook, that is the right trade. In an app where most responses are per-user, you are paying the coupling and getting back the fraction of traffic that is actually shared.
