I could use your help gathering some data for my upcoming Laracon EU talk.
If you ever had a slow Laravel application/slow request/slow command/etc. - what was the reason for it?
Would be great to get as many replies as possible. Please share for reach 🙂
If you ever had a slow Laravel application/slow request/slow command/etc. - what was the reason for it?
Would be great to get as many replies as possible. Please share for reach 🙂
Comments
If you take it out all at once the clients might start questioning all those "performance improvement" invoices!
- n+1 queries in JSON resources
- unavoidable n+1 queries in a datatables package due to multiple deeply-nested relationships
- thousands of queue jobs to import and update model data getting rate-limited by external services
If you have one that has to process thousands or millions or DB entries, anything that listen for the `QueryExecuted` event can cause a lot of overhead.
In that case, you can add these two lines:
DB::disableQueryLog();
Event::forget(QueryExecuted::class);
2. PDF generation
3. calling external APIs that sometime take a while to respond
a) Slow database query due to missing index
b) Loop in a loop in a loop with many conditionals in between. (eg. rendering a matrix-table with dynamic number of rows and columns)
I know how to solve a) but never found a really good solution for b) besides trying to cache stuff.
2. Forgetting to cache blade icons
3. Missing a DB index
An observer which hits an external, slow API.
Also, a plugin that made database calls for every one of 10,000+ images, on every page load, "to check if they were cached".
Nope, Wordpress again.
- Calls to external APIs synchronously on page load — especially when there’s a long or no timeout set
- Middleware that should have been terminable
- “Thundering herd” effect after a cache reset or cache key change
Those are all real life examples for me 😀
Data manipulation in migration/command on large model collections ended with model hydration increasing execution time and memory by a ton (this was back in laravel 5 i think)
- consider raw SQL when possible for updates on large datasets
- If eloquent/models then be mindful of loaded fields, relations, default $with, events etc
- reach for jobs more
Almost always it's between the path of eloquent to blade.
Bad db indexing strategies / no use of search indexes.
I could go on all day 😅
https://github.com/stillat/dagger
- separate livewire CRUD modals for each datatable row & show 500 rows per page
- accordions with 10k+ nested divs
- N+1 issue, but the database is external and throws 429 too
- sending emails during request
- forgot to rerun artisan optimise after clearing it
- inefficient queries
- n+1 queries
- plain inefficient database design
- application preparing tons of data for trace logging despite it being disabled
- a call to sleep(5) that was inserted for „debugging“
Plus a ton more to do my own talk on the subject 😅
* DB stuff (n+1 or bad indexes)
* Hydrating models/parts of models
* Serialising complex models
* Authorisation checks (policy acquisition and re-triggering the same policy in a loop)
* Blade/component rendering soup.