Cache Stats Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for internal observability: This is a narrow, read-only diagnostics tool rather than a product capability. The decision it informs is whether to hand-roll cache introspection (an afternoon of opcache_get_status() / apcu_cache_info() calls) or vendor a maintained wrapper. At MIT license and ~10 stars, the honest framing is "buy the idea, not the dependency" — the value is the opinionated set of metrics and thresholds, not the code volume.
• Performance roadmap prioritization: OPCache hit rate, APCu memory pressure, and realpath cache misses are the three cheapest-to-fix causes of "the app is slow and we don't know why" in PHP-FPM deployments. Surfacing them gives you evidence to sequence performance work (cache tuning → opcode config → framework-level caching) instead of guessing.
• Infrastructure/config change approval: Concrete numbers (e.g., realpath cache full, OPCache restarts, APCu fragmentation) turn "we should tune PHP" into a scoped, verifiable ticket with a before/after. This de-risks changes to production php.ini that otherwise get blocked in review.
• Incident triage and cost control: When p95 latency spikes without application errors, cache stats are a fast disambiguator between "code regression" and "environment drift / cache eviction." Also relevant to horizontal scaling decisions — repeated cold caches after deploys are a capacity and rollout-strategy signal.
• Buy-vs-adapt decision for a Laravel codebase: Because this is a Symfony bundle (DI extension, tagged services, Symfony config tree), it does not drop into Laravel. The real product decision is whether to (a) extract the underlying collector logic into a Laravel service provider plus a /health/cache endpoint or Artisan command, (b) run it in a sidecar/internal Symfony admin app against the same PHP runtime, or (c) skip it and write ~100 lines yourself. Option (c) is frequently correct at this maturity level.
• Scope discipline: This is not a user-facing feature and should not consume a roadmap slot. Classify it as engineering-enablement tooling with an owner and an expiry review date.

When to Consider This Package

Consider it when:

• You run self-managed or containerized PHP-FPM with OPCache/APCu enabled and control php.ini, and you have no APM (Datadog, New Relic, Tideways, Blackfire) already covering opcode cache health.
• You are on Symfony (the bundle's native target) and want a low-effort internal debug toolbar or admin page rather than wiring collectors by hand.
• You need a point-in-time diagnostic during a performance investigation, not continuous production telemetry with retention, alerting, and dashboards.
• The integration is behind an internal-only route with auth, and you are comfortable vendoring or forking under MIT.
• Someone on the team can own a small PHP internals-adjacent component and review it against PHP version upgrades.

Look elsewhere when:

• Your stack is Laravel. The Symfony bundle abstraction is dead weight; you would be reimplementing it. Evaluate only as a reference implementation.
• You need alerting, time-series storage, historical trending, or SLO reporting — that is APM/Prometheus territory, not a stats page.
• You are on managed hosting or serverless where OPCache/APCu tuning is not yours to change; the data is interesting but not actionable.
• You require vendor SLAs, security review provenance, or long-term maintenance guarantees. Ten stars and zero dependents means bus factor of one; treat it as sample code with a nice license, not a dependency with a support contract.
• The package would run in production request paths — cache introspection has non-trivial overhead and should stay on an internal, separately-routed surface.

Mitigations if you adopt: pin the version, vendor the collectors into your own namespace, add a PHP-version compatibility test to CI, and set a review checkpoint (e.g., re-evaluate at the next PHP minor upgrade or in two quarters).

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed diagnostic utility that tells us whether PHP's in-memory caches — the layers that make our app fast before a single line of our code runs — are actually working. Misconfigured caches are a common, invisible cause of slow page loads and unnecessary server spend, and they're cheap to fix once visible. It is internal tooling, not a customer feature: no product risk, no user-facing surface, and the main cost is roughly a day of engineering to adapt it to our stack. The caveat is maturity — it's a small, single-maintainer project, so we should treat it as reference code we own rather than a dependency we rely on. Recommendation: time-box a spike, and if it surfaces actionable misconfiguration, fold the logic into our own health endpoint rather than adopting the bundle long-term.

To engineering: Symfony bundle that exposes OPCache, APCu, and realpath cache statistics. Not Laravel-compatible out of the box — the DI extension and config tree don't apply, so the realistic path is extracting the collectors into a service provider plus an authenticated internal route or Artisan command. Keep it off production request paths; expose behind admin auth. Pin and vendor it. Success criteria for the spike: does it show us a cache misconfiguration we can fix this sprint, and is the collector code clean enough to own? If yes, adopt the logic; if no, close it out and keep the ~100 lines we wrote.