Mysqlnd Analytics Laravel Package

Technical Evaluation

Architecture fit — conditional, and the first thing a TPM must resolve is what the artifact actually is. The supplied materials conflict: the package description and vendor prefix (js/) imply a JavaScript library, while the prior technical assessment characterizes it as a standalone PHP library that consumes the mysqlnd statistics array. That discrepancy is not pedantry — it determines whether this is a composer require away from a spike or requires a Node process bolted onto a PHP deployment. Treat the PHP-library reading as the working assumption (mysqlnd statistics are a PHP-runtime artifact; a JS library would have nothing native to read), but require the team to verify against the repository before any estimate is trusted.

Structurally, the package is an analyser, not a runtime component. It takes counters that PHP's MySQL Native Driver already produces and applies heuristics to produce tuning guidance. There is no service provider, facade, config, or framework coupling — "Laravel-friendly setup" in the description is marketing rather than an integration surface. For a TPM this is actually a favourable shape: it means zero request-path footprint and no lock-in, provided the team wraps it behind an internal boundary.

Integration feasibility — mechanically high, analytically low. Getting the library to execute is a half-day task. Getting trustworthy output from it in a Laravel estate is the real work: mysqlnd counters are per-process and accumulate over a worker's lifetime, so under PHP-FPM each of 50 workers holds a differently-aged sample of a different slice of traffic. The package provides no collection, aggregation, delta management, or reset mechanism. Whatever signal you want, you build the collection layer yourself. Under Octane the counters become more meaningful (long-lived workers, many requests per window), but attribution gets harder because the window is heterogeneous.

Technical risk — concentrated in maintenance and semantic drift, not supply chain.

• Maintenance: 33 stars, zero dependents, single maintainer, and a codebase apparently written for the PHP 5.x/7.x era with no evidence of PHP 8.x verification. Dynamic-property deprecations and untyped signatures are plausible and will surface as warnings — or fatals — under Laravel's error handler.
• Semantic drift: much of the classic mysqlnd guidance concerns the MySQL query cache, removed in MySQL 8.0. On a modern MySQL target, some recommendations will be actively wrong. On MariaDB they may still hold.
• Fidelity: the output is heuristic advice, not measurement. It will not identify the slow query; it will suggest whether connection churn, result-set buffering, or protocol overhead look inefficient. It complements Pulse, Telescope, and performance_schema; it does not replace them.
• Supply chain: low. Small, dependency-light, BSD-3-Clause. Forking and vendoring is cheap and legally clean.

Key questions before committing engineering time.

1. What is the artifact, concretely — PHP library, JS library, or both? Has anyone run it on our target PHP minor?
2. Which MySQL/MariaDB version and driver does the estate run, and is ext-mysqli present in production images (it frequently is not, when only pdo_mysql is installed)?
3. Are we FPM with short worker lifetimes, or Octane? This determines whether per-process counters are usable at all.
4. What decision would this output change that Pulse, Telescope, the slow query log, or performance_schema cannot already answer? If the answer is "none," this is a science project and should be closed out.
5. Is the intended use a one-off diagnostic (staging, load test) or continuous telemetry? The package only genuinely suits the former.

Integration Approach

Stack fit — development/diagnostic tool only, never a production dependency. The right shape is a thin in-house adapter package that depends on this library, wraps it behind a service provider, and exposes it exclusively through an artisan command and a non-production-gated route. Put it in require-dev of the application. The adapter exists specifically so third-party types never leak into application code — that insulation is the single most important design decision given the maintenance profile, and it makes removal a one-line composer change.

Proposed wiring.

• Collector — guards on extension_loaded('mysqli'), calls mysqli_get_client_stats(), optionally subtracts a stored baseline to produce deltas rather than lifetime totals.
• Analyser adapter — normalizes the library's output into a stable internal DTO so the heuristics can be replaced, forked, or partially reimplemented without touching call sites.
• Artisan command — mysqlnd:report, CLI-only, printing guidance plus raw counters, and refusing to report when the process has served fewer than N requests (below which the numbers are noise).
• Optional persistence — a log/cache channel for per-worker deltas, only if continuous collection is genuinely funded.

Migration path — additive only. There is nothing to migrate from except ad-hoc SHOW STATUS checks and manual stats dumps. Introduce alongside existing observability, never as a replacement.

Compatibility. PHP version is unverified; validate on the exact production minor in a throwaway branch first. Laravel imposes no constraint because the library has no framework coupling — the constraint is entirely ours. Gate guidance by server flavour: suppress query-cache advice on MySQL 8.0+, retain on MariaDB. If the platform team wants separation, add mysqli only to the diagnostic image, not the runtime image.

Sequencing.

1. Spike (1–2 days). Execute against a captured stats array; confirm it runs on target PHP and that the guidance is legible and non-trivial for a real workload.
2. Compatibility proof. Install into a Laravel skeleton, exercise through the adapter, capture deprecations and warnings.
3. Adapter build. Collector, analyser, command, feature-flagged to non-production.
4. Ground-truth validation — the go/no-go gate. Run a load test with a planted inefficiency (non-persistent connections, unbuffered result sets) and confirm the library flags it. If it does not detect a problem you deliberately created, stop; do not proceed to aggregation.
5. Optional aggregation. Only if step 4 passes and a stakeholder wants ongoing signal.
6. Document and park. Record the verdict, the supported PHP/MySQL envelope, and the fork policy.

Operational Impact

Maintenance — the dominant cost, and it is not optional. The package is effectively unmaintained. Owning it means owning a fork the moment a PHP minor turns a deprecation into an error under Laravel's handler. Budget an annual compatibility review, a vendored fork under our namespace with a documented patch list, and a standing upstream-or-diverge decision. Because the library is small, forking is cheap; because it is unmaintained, forking is likely inevitable rather than discretionary.

Support. Community-only: no SLA, no security response process. Mitigating factor — near-zero attack surface. The library does no I/O, opens no connections, and parses no untrusted input. The realistic risk is correctness, not compromise. Exposure should still be constrained: never expose the analysis endpoint publicly, since its output enumerates server behaviour and connection topology — useful reconnaissance even absent a CVE.

Scaling. The per-process, per-worker-lifetime property is the scaling story and it is poor. In a 50-worker FPM pool, summing counters produces a lifetime aggregate of differently-aged samples — meaningless. Meaningful analysis requires per-worker deltas shipped to a time-series store, which is a build project in its own right and roughly the cost of standing up Pulse. Under Octane the counters behave better but the interpretation problem gets harder. Note also that mysqlnd counters cannot see fleet-wide behaviour — where capacity questions actually live — so this tool informs application-level inefficiency, not infrastructure sizing.

Failure modes to plan for.

• Silent no-op: ext-mysqli absent, so the collector returns nothing. Guard and alert; do not let a diagnostic fail open into "all clear."
• Misleading guidance: query-cache advice on MySQL 8.0. Version-gate it.
• Stale-window analysis: reporting on a worker with a 30-second lifetime and 4 requests. Enforce the minimum-sample threshold.
• Error-handler escalation: deprecations promoted to exceptions, breaking the command in CI. Pin the PHP version in the diagnostic image.
• False confidence: stakeholders reading heuristic output as measurement. Label the report explicitly as advisory.

Ramp-up. Low for a competent PHP engineer — the adapter is days, not weeks, and the heuristic ruleset is readable. The learning cost sits with whoever must interpret the output: they need enough MySQL internals fluency to know when the advice does not apply to the estate (query cache, buffered result sets, SSL overhead). Assign one named owner rather than treating it as everyone's tool; the failure mode for lightly-owned diagnostics is that they get run once, misread, and quietly distrusted.

TPM-level verdict. Leverage this as a research input and decision aid, not infrastructure. Its value is the rule set — a cheap lens on whether the next database investment should be query caching, N+1 elimination, connection pooling, or a proxy, and a quantified before/after signal for driver and PHP upgrades. Fund a timeboxed spike if database-layer performance is an open roadmap question; harvest the heuristics into a small internal PHP diagnostic; otherwise close it out and standardize on the observability tooling already in place. Do not add it to the dependency inventory, and do not let it appear on a supported-tier or self-hosted health-check commitment without a named owner and a fork policy.