Larameter Laravel Package

Getting Started

Larameter is a measurement/instrumentation package for Laravel: you drop it in, wrap the code path you care about (a route, a console command, a queued job), and get numbers back instead of guessing. 1.2.0 is a small, non-breaking release — the changelog entry "Contemplate cache usage" signals that caching of measurements/results has been considered, so read the diff before assuming your existing numbers still come from a live measurement.

Minimal steps:

1. composer require edulazaro/larameter (pin ^1.2 once you've verified the diff from 1.1.1).
2. Publish the package config (php artisan vendor:publish --provider="EduLazaro\Larameter\...") and read it top to bottom — this is where enable/disable, storage and any caching behaviour is toggled.
3. Skim README.md for the public entry point (facade, helper, or middleware) and the changelog link 1.1.1...1.2.0 for the caching change specifically. The release note is one line; the diff is the real documentation here.
4. First use case: take your slowest endpoint or heaviest Artisan command, baseline it, make one optimisation, measure again. Larameter is only useful when you have a "before" number.

Do the first run in local or a dedicated staging environment, not in production.

Implementation Patterns

Middleware for HTTP timings. If the package ships middleware, register it on the routes you actually care about rather than globally:

Route::middleware(['web', 'larameter'])->group(function () {
    Route::get('/reports', ReportController::class);
});

Baseline-then-change workflow. The highest-value pattern day to day is not continuous monitoring — it's A/B measurement around a single change. Record the number, make the change (add an index, eager-load a relation, swap a cache driver), record again, keep the diff in the PR description.

Wrap console commands and jobs. Web requests are the obvious case, but the expensive paths in Laravel apps are usually queue workers and scheduled commands. Measure there with the same API, and use Bus::fake() / Queue::fake() in tests so you aren't measuring test overhead.

Assert on measurements in tests. Convert a measurement into a guardrail so a regression fails CI rather than being noticed in a month:

$this->artisan('reports:build');
$this->assertLessThan(500, /* measurement value */);

Keep thresholds generous — CI machines are noisy.

Gate by environment in config. The package should be a no-op outside local/staging. Wire this from APP_ENV in the config rather than remembering to comment out middleware before a deploy.

Caching (new in 1.2.0). The intended pattern is almost certainly to cache measurement results so you don't recompute an expensive measurement per request — or, conversely, to have the package's own cache interactions accounted for so a warm cache doesn't flatter your numbers. Either way, treat cached measurements like any other cache: give them an explicit TTL, namespace the key by route/command and by tenant if you're multi-tenant, and clear them on deploy so a config or code change isn't masked by a stale entry from the previous release.

Gotchas and Tips

• "Contemplate cache usage" is ambiguous — verify which meaning applies. It could be the package caching its measurements, or the package now recording cache hits/misses as part of what it measures. Read the diff; the two have very different consequences for your numbers.
• The array cache driver won't survive the request. If measurements are cached, the array store is reset on every request, so you'll see a recompute every time and conclude caching "doesn't work". Use file or redis when you want measurements shared across requests.
• Stale numbers after deploy. Cached measurements from 1.1.1 mixed with 1.2.0 code will quietly poison your before/after comparison. Flush the relevant keys as part of your deploy script.
• config:cache freezes your config. If you publish the config and later change the enable flag, run php artisan config:clear — otherwise you'll debug a package that "isn't working" when it's just reading a cached flag.
• Overhead is real. Instrumentation in a hot path costs something. Prefer scoped middleware over global, and sample if you're measuring high-volume production traffic.
• Don't benchmark in php artisan serve. Use the same runtime you deploy (Octane/FPM), or your baseline is measuring the dev server.
• Compare like with like. Cold cache vs warm cache, seeded vs unseeded DB, first request vs subsequent — most "the optimisation made it slower" conclusions are a warm/cold mismatch. Pin the conditions before you measure.
• Extension point: if the built-in storage or caching doesn't fit, check the config for a driver/repository binding you can swap, and bind your own implementation in a service provider rather than editing the package files.
• Version pinning: with a single-line changelog, pin ^1.2 and read the diff on each bump. Do not assume 1.2.x patches are behaviour-neutral until the changelog gets more descriptive.