Memory Scanner Laravel Package

Technical Evaluation

Architecture fit. shipmonk/memory-scanner is an additive, in-process instrumentation library rather than a framework extension. It does not ship a Laravel service provider, facade, or config stub, which is actually a reasonable fit for a diagnostics tool: it slots into specific execution contexts (queue workers, artisan commands, Octane workers, scheduled jobs) without touching application architecture. It is not a general APM or observability platform, so it should be evaluated as a targeted debug aid for long-running PHP processes, where Laravel's most common memory-leak surfaces live: Horizon workers, queue jobs, and Octane's persistent worker loop.

Integration feasibility. Low ceiling, low floor. A TPM can realistically scope a spike to wrap a queue job or command in the scanner's measurement calls and compare resident memory before/after. Because the library is standalone, integration cost is mostly glue code and output plumbing (writing findings to logs or a CI artifact) rather than architectural change. No dependency graph risk — the package has zero dependents, which cuts both ways: nothing will break underneath it, but there is also no ecosystem proof of it working in production Laravel fleets.

Technical risk. The dominant risks are maturity and bus-factor, not technical incompatibility: 18 stars, 0 dependents, MIT license, and a single organizational maintainer (ShipMonk's R&D org). That is fine for a dev-only tool but unacceptable as a runtime dependency in production without a vendoring or fork contingency. Secondary risks: verify the PHP version constraint against your minimum (Laravel 10/11 stacks are typically PHP 8.1+), confirm whether it relies on memory_get_usage() alone or hooks like gc_status()/Xdebug for leak attribution — the latter materially changes the CI story. Also confirm the measurement overhead per call, since a scanner that perturbs the heap can mask the leak it is trying to find.

Key questions to resolve in the spike.

• Which PHP versions and extensions are hard requirements (Xdebug? pcntl? posix?)?
• Does it support async/parallel contexts, or only single-process measurement?
• Is the output machine-readable (structured deltas) or human-oriented (echo/dump)?
• What is per-call and per-process memory overhead of the scanner itself?
• Is there a maintained release cadence, and does ShipMonk respond to issues?
• Does it distinguish genuine leaks from legitimate framework caches (container singletons, Eloquent model caches, config/route caches)?

Integration Approach

Stack fit. The natural home is Laravel's long-running execution surfaces: Horizon/queue workers, octane workers, scheduler invocations, and custom artisan commands that batch-process records. It is a poor fit for request-scoped FPM traffic, where the process lifecycle already reclaims memory and the signal-to-noise ratio collapses.

Migration path. Follow an additive, reversible path — there is nothing to migrate away from.

1. Install as require-dev and prototype inside a single disposable queue job or command.
2. Wrap the measurement in a small internal helper (trait or decorator) so application code never calls the vendor API directly. This is the single most valuable engineering investment: it makes the tool swappable if the package stalls.
3. Promote to a CI check (memory regression gate) for the highest-risk job classes before considering any production use.
4. Only if CI proves stable, gate production sampling behind a config flag, defaulting off, with output routed to existing logging/APM rather than stdout.

Compatibility. Confirm PSR-4 autoloading and the PHP constraint resolve cleanly against composer.lock. Because there is no Laravel auto-discovery, plan for manual instantiation — this is a feature, since it means zero boot-time surface in production when the tool is disabled.

Sequencing. Do the spike (1–2 days) before committing to a rollout plan. The decision gate should be: does the scanner identify a real, previously-unknown leak in a representative Horizon job? If it only reports heap growth without attribution, its marginal value over memory_get_usage() logging is low and the effort is better spent on existing tooling.

Operational Impact

Maintenance. Minimal maintenance burden in the near term — small codebase, permissive license, no transitive dependencies — but the low star count and zero dependents mean upstream abandonment is a realistic scenario. Mitigate by keeping the internal wrapper thin and, if adopted beyond a spike, vendoring a pinned version into a private fork with a quarterly upstream check. Budget owner time for that review, not for active development.

Support. Community support only, via GitHub issues, with no SLA. The ShipMonk R&D org has a credible PHP track record, but this specific project is peripheral to their commercial product. Do not put it on a critical path without an internal owner who can read the source.

Scaling. The tool is per-process and per-invocation; it does not aggregate across a worker fleet. At scale, the operational model is "sample a percentage of workers, emit structured deltas to your existing log pipeline, alert on trends." That means the real scaling cost lands on your observability stack, not on this package. Estimate accordingly.

Failure modes to plan for. (a) False positives from legitimate caches and framework singletons, which will erode trust in the signal; (b) observer effect — scanner overhead inflating or masking heap behavior; (c) silent misconfiguration where the scanner runs but output is never captured, giving false confidence; (d) upstream stagnation leaving the package incompatible with a future PHP major.

Ramp-up. Low for senior PHP engineers already comfortable with memory_get_usage() and gc_collect_cycles(); moderate for mid-level engineers because documentation is likely sparse and the leak-attribution mental model (baseline vs. delta vs. retained set) is not obvious. Budget half a day of documentation and a worked example in your internal wiki — that artifact, not the library, is what makes the adoption durable.