- How do I install bvanhoekelen/performance in a Laravel application?
- Run composer require bvanhoekelen/performance; the package ships a service provider and facade with Laravel auto-discovery, so manual registration is normally unnecessary. Publish the config with php artisan vendor:publish, then either register the middleware or call the facade at your start and end points. A first working spike is measured in hours, not sprints.
- Which Laravel and PHP versions does bvanhoekelen/performance support?
- The package is a single-purpose in-process tool installed via standard Composer, but the exact laravel/framework and php constraints in its composer.json must be confirmed before adoption. Verify Laravel 11 and 12 support and PHP 8.2 through 8.4 explicitly during a half-day spike. Do not assume compatibility from the README alone.
- How does this package capture database queries?
- The overview states it measures db query counts, but the collection mechanics are not confirmed: it may use a global DB::listen registration, enableQueryLog(), or a scoped listener. This matters because a global listener can duplicate what Debugbar or Telescope already registers, double-counting queries and adding overhead. Inspect the source during your spike.
- Can I safely enable bvanhoekelen/performance in production?
- No. Any tool that renders timings, memory, and executed SQL into a response is an information-disclosure vector. Gate it structurally with conditional provider registration or an env-gated config default rather than relying on developer discipline. Treat it as a developer-facing diagnostic and do not deploy it to production runtimes.
- Is bvanhoekelen/performance safe under Laravel Octane, Swoole, or queue workers?
- Unbounded query accumulation is a real risk in long-lived processes: if capture relies on Laravel's query log, memory grows with the number of queries per worker lifecycle. Confirm whether the listener is request-scoped and whether state resets between requests. Until that is verified, avoid it under Octane, Swoole, or queue workers.
- How is it different from Laravel Debugbar, Telescope, or Clockwork?
- It is a narrow, point-in-time diagnostic snapshot of elapsed time, peak memory, and DB query count, not an APM, tracing system, or continuous profiler. It complements Debugbar and Telescope but overlaps with them on the DB-query dimension. Manage that overlap to avoid duplicate listeners and additive overhead.
- Can I scope measurement to specific routes or Artisan commands instead of globally?
- The package supports start and end points plus checkpoints and works across web requests, web console, and CLI, so you can instrument only the code paths you care about. Whether the middleware can be attached to specific route groups rather than globally is a detail to verify. Scoped use is preferable to global enablement.
- What is the per-request overhead of this performance tool?
- Overhead depends on the collection mechanics and how many checkpoints and queries you capture. Measure p50 and p99 latency on a representative endpoint during your spike rather than trusting the README. Keep it out of production paths so overhead never affects real traffic.
- How do I configure the enable flag and output rendering?
- Publish the config with vendor:publish and set the enable option, but beware that a flag defaulting to false gives false confidence: teams may believe they are measuring when they are not. Response-injecting middleware can also break JSON and API consumers and conflict with CSP headers depending on middleware ordering. Prefer explicit facade calls in local and debug environments.
- Is bvanhoekelen/performance actively maintained, and what are the alternatives?
- It is a small-author package with no commercial backing or SLA, though the Apache-2.0 license makes it fork-friendly. Assign a named internal owner before adopting it. If you need maintained, production-grade observability, Laravel Telescope, Debugbar, Clockwork, or OpenTelemetry are the stronger alternatives.