A Laravel page once started feeling unusually heavy.
The server was running, the page was loading, and there was no obvious error. But one question kept coming up:
How much memory is this page actually using?
Tools like htop were useful for checking the server, but they did not give me a simple answer for one specific Laravel request.
The easiest solution was already available in PHP:
memory_get_peak_usage(true)
With one small log entry, I could see the peak memory usage of each Laravel request.
The Quick Solution
Open:
public/index.php
After Laravel handles the request, add:
logger(
'Peak Memory Usage: ' .
round(memory_get_peak_usage(true) / 1024 / 1024, 2) .
' MB'
);
For example:
$app->handleRequest(Request::capture());
logger(
'Peak Memory Usage: ' .
round(memory_get_peak_usage(true) / 1024 / 1024, 2) .
' MB'
);
Now open the Laravel page you want to test.
Then watch the log:
tail -f storage/logs/laravel.log
Refresh the page.
You should see something like:
Peak Memory Usage: 74.38 MB
That is the peak amount of memory PHP allocated while processing that request.
Why This Is Useful
Imagine checking several pages:
Home → 42 MB
Dashboard → 55 MB
Users → 63 MB
Reports → 210 MB
The reports page immediately stands out.
Instead of saying:
“This page feels heavy.”
you now have something measurable:
“This page reaches around 210 MB while the others stay below 70 MB.”
That gives you a much better place to start debugging.
A Real Laravel Example
Suppose the reports page contains:
$users = User::all();
If your database has 100,000 users, Laravel may load all of them into memory.
If the page only needs 50 users, use:
$users = User::paginate(50);
For large background processing, you might use:
User::chunk(1000, function ($users) {
foreach ($users as $user) {
// Process user
}
});
After changing the code, test the page again.
You may get:
Before → 210 MB
After → 68 MB
Now you can clearly see whether the optimization helped.
What Does memory_get_peak_usage(true) Mean?
This function:
memory_get_peak_usage(true)
returns the highest amount of memory allocated during the current PHP request.
PHP returns the value in bytes.
So we convert it to megabytes:
memory_get_peak_usage(true) / 1024 / 1024
And round it:
round(memory_get_peak_usage(true) / 1024 / 1024, 2)
That gives us an easy-to-read result like:
74.38 MB
Why Not Just Use htop?
htop is still very useful.
Use it when you want to understand:
- total server memory
- CPU usage
- PHP-FPM workers
- MySQL usage
- overall server health
But if your question is:
How much peak memory did this Laravel request use?
then memory_get_peak_usage(true) is much more direct.
They solve different problems.
What to Check If Memory Is Too High
If one page uses much more memory than others, start by checking:
- large
Model::all()queries - unnecessary Eloquent relationships
- huge collections
- large file or image processing
- PDF or Excel generation
- reports loading too much data
- loops that keep large amounts of data in memory
The main rule is simple:
Do not load everything into memory if you only need a small part of it.
Test More Than Once
Do not rely on one request.
Refresh the same page a few times:
Request 1 → 71.8 MB
Request 2 → 69.9 MB
Request 3 → 70.2 MB
Small differences are normal.
What matters is the general pattern.
If one page consistently stays around 70 MB and another stays around 200 MB, that difference is worth investigating.
Important: Remove the Logger After Testing
This code is for debugging:
logger(...)
Do not leave it running forever on a busy production site.
Otherwise every page request will create another log entry.
A simple workflow is:
Measure
↓
Find the expensive page
↓
Optimize
↓
Measure again
↓
Remove the logger
Final Thoughts
Laravel performance debugging becomes much easier when you stop guessing and start measuring.
If you only want to know how much peak memory a Laravel request uses, you do not need a complicated monitoring setup.
Add:
memory_get_peak_usage(true)
log the result, refresh the page, and check:
storage/logs/laravel.log
A small measurement can quickly tell you which page deserves your attention.
Measure first. Optimize second.

Top comments (0)