A Note on What This Is

Details of the businesses involved are withheld: this work was delivered under employment, and the systems and clients are not ZaidanLab's to claim. What follows describes a real pattern of engineering work, with names, data and internal details left out.

The Problem Pattern

A commerce platform runs on several application nodes with the code on shared network storage. Pages feel slow, but CPU and memory look healthy, so the cause is easy to misread as a need for bigger servers.

Measure Per Node First

Before changing anything, compare response times per node from the web server logs. If one node is consistently slower, the cause is local to that node. If all are slow, look at what they share. Without this, tuning is guesswork.

Opcache Settings on Network Storage

PHP opcache normally avoids reading files on every request. If its settings force frequent file checks, or its memory is too small for a large codebase, every request pays the network-storage latency again. Raising memory and relaxing revalidation, with a deploy step that resets the cache, often removes most of the delay.

Where the Cache Lives

A default cache backend on slow disk can quietly dominate request time. Moving the default cache and sessions to an in-memory store removes a large amount of small reads and writes. It also fixes a quieter problem: operating-system cleanup jobs that purge session files by a global lifetime and ignore the application's own session setting.

Verify, Do Not Assume

After each change, compare the same per-node figures again. A tuning change that cannot be shown to help should be reverted, because every extra setting is something the next engineer has to understand.

Why This Matters

Slowness is a conversion and trust problem, and the cheapest fixes are often configuration, not hardware. Knowing where to look first is the difference between an afternoon and a month.