Performance shows what makes a site slow and how to fix it: a scored checkup of its settings, the slowest pages, N+1 and slow queries, the packages that cost the most time, and a load test that tells you how many users a page can take.
The checkup
A score out of 100 from what LaraMonster can see in the project and its PHP, grouped with why it matters for each item:
- Config, route, view and event caches
- Composer's optimised autoloader
- OPcache, read for the project's folder
- Xdebug, Debugbar and Telescope left on
- Queue and cache drivers
Most items have a one-click fix. Fixes apply to this computer only; nothing is committed to your project.
Requests & queries
With recording on, LaraMonster measures every request (the newest 1,000 are kept) and shows:
| Section | What you learn |
|---|---|
| Overview | Typical response, the 95th percentile (the slow tail) and queries per request |
| N+1 queries | A query repeated 5 or more times from one line in one request, the relation to eager-load and the fix to copy |
| Slowest pages | By average time, with the 95th percentile, slowest request and query count |
| Slow queries | Queries of 100 ms or more, with Explain & time it |
| Third-party code | Time packages spend in their own queries and listeners, as a share of request time |
Fixing an N+1
LaraMonster shows the line that runs the repeated query and the relation to load. For example, a list of posts that shows each author:
$posts = Post::latest()->paginate(20);
// in the view: $post->author->name runs one query per post$posts = Post::with('author')->latest()->paginate(20);Explain & time it
For a slow SELECT, Explain & time it runs it 5 times inside a transaction that is rolled back and shows the database's plan in words. “Reads every row” means an index would help:
Schema::table('orders', function (Blueprint $table) {
$table->index(['status', 'created_at']);
});Load tests
How many users can this page take? Pick a page from the app's routes (replace {parameters} with real values, like /posts/1), a number of users at once, and a duration (10 seconds to 1 minute). LaraMonster sends their requests and watches the site's PHP while they browse, then reports:
- Requests per second, typical response and the 95th/99th percentile
- Errors, with the most common one
- PHP workers busy, CPU and memory, and whether PHP ran out of workers
- The numbers every half second, to see when it started to struggle
Testing as a signed-in user
Most interesting pages need a login. Choose Signed-in user and pick the user by User ID, Email, Role or Permission (spatie/laravel-permission), or Email and password, for any guard: sessions or Sanctum tokens. Check who this is confirms the user first.
LaraMonster signs that user in for the test without the login form, then removes the session or token afterwards. A password is only used to sign in and isn't saved.