Performance & Caching

OPcache stores the compiled opcodes of your PHP files, so a script is not re-parsed and re-compiled on every request; it never holds your data. Redis or Memcached is an application cache — it stores results your code computed, such as a query result, and is shared across every worker.

Images, CSS and JS still consume connections and bandwidth on your origin. A CDN serves them from an edge node near the user, so latency drops and the origin handles only dynamic requests. You version the file names so a new deploy is never served from a stale edge cache.

Cache-Control: max-age lets the client reuse the response without asking, so no request reaches PHP until it expires. An ETag is a content fingerprint the client resends as If-None-Match; if it still matches you answer 304 Not Modified with no body, saving the render and the transfer.

Doing it inline holds an FPM worker for the whole call, so the user waits and that slot serves nobody else; a third-party failure fails the request too. Queueing a job returns the response immediately, and a separate long-running worker does the work, retrying on failure.

Vertical scaling buys a bigger box — more cores and RAM let you raise pm.max_children. Horizontal scaling adds servers behind a load balancer. PHP's shared-nothing model makes that natural, provided sessions, uploads and caches live in shared storage such as Redis, not on local disk.

xdebug.mode=debug gives step debugging — breakpoints, stepping and variable inspection driven from the IDE. xdebug.mode=profile records where the time goes and writes a cachegrind file you read in KCachegrind. Both add heavy overhead, so neither belongs on a production box.

Laravel dispatches a serialized Job object to a connection (Redis, database, SQS) and queue:work consumes it; retries, backoff and a failed_jobs table come built in. Messenger dispatches a plain message onto a bus, middleware routes it to a transport, and a separate handler consumes it — so the same message can also be handled synchronously.

Key the entry by everything that changes the result — filters, page, sort, locale — and give it a TTL as a safety net. The real work is invalidation: a product write must delete or rewrite the affected keys, usually via a tag or a version prefix bumped on write, since you cannot enumerate keys cheaply. Guard the empty-cache case with a lock, or a burst stampedes the database.

Profile the actual request — Xdebug's profiler locally, or Blackfire against real traffic — and read the call graph by inclusive wall time, not by call count. It almost always shows one of three things: a query repeated hundreds of times, one slow query, or a blocking third-party call. Fix what the profile shows; caching a 2 ms function changes nothing.

Split the send into small jobs — one per recipient or per chunk — dispatched as a batch, never one giant job. Persist per-recipient state so a retry is idempotent: a worker claims a row and skips one already marked sent. Throttle workers to the provider's rate limit, cap retries with backoff, and expose batch progress and failures so the run can be paused and resumed.

The pool is saturated, not slow: 20 of 20 children are active and 312 requests sit in the listen backlog, so most of the 8 s is spent waiting for a worker. The slow log names the culprit — a blocking curl_exec() to the warehouse service holds a worker for seconds. Raising pm.max_children only moves the queue; add a timeout and take that call out of the request.

Measure, do not guess. Take an average worker's resident memory under real traffic and divide the RAM you can spare by it — that is the ceiling. Then load-test with k6 at rising concurrency against a production-like box, watching p95 latency, the FPM listen queue and memory. The right value is the largest one where latency stays flat and the box never swaps.

Layer it: HTTP validators at the edge for the public GETs, a shared Redis tier for computed responses, the database behind both. Writes invalidate explicitly — delete or version the affected keys rather than waiting for a TTL. Redis must stay a cache, not a dependency: on failure fall through to the database behind a circuit breaker. Guard cold keys with a lock or stale-while-revalidate, and never cache per-user or authorised data in a shared tier.