Read on Twitter
How I managed to reduce one request from 108 queries, 9MB, 450ms response to 3 queries, 6MB and 80ms. Thanks for @reinink's Eloquent Performance Patterns. I will walk you through how simple informed changes to your code can make huge difference.
A
thread 
A
thread
I had few problems with this request, I was aware of them, but I purchased @reinink course specifically to help me find the best approach to achieve the optimization I am looking for. You should purchase the course by the way. https://eloquent-course.reinink.ca/#buy
The query was mainly listing models created by a user when they login to their dashboard. The original version was basically doing that
Two things to note here:
1. I am pulling in all information from the Lead model, even if I do not need it.
2. I am using API Resources to process the response before sending to client (more on that in a minute)
1. I am pulling in all information from the Lead model, even if I do not need it.
2. I am using API Resources to process the response before sending to client (more on that in a minute)
Then I decided to optimize what I am pulling from the DB, so I started with that:
As you can see, I am only getting the values that I will use in the data table in the dashboard. This reduced the memory consumption greatly, let's see why.
The Lead model is basically a collection of relationships with other models. Most of those models are static lists that do not change.
Hence, I cache them and retrieve from cache instead of querying the DB.
Hence, I cache them and retrieve from cache instead of querying the DB.
By retrieving the needed values only, any related model with a key not retrieved, will not be hydrated. Memory consumption dropped to 7MB 
However, the request was still slow, and loads a lot of User models, there must be something leading to that. Here comes the optimization to the HTTP Resource class.
This is the original code for the Lead API Resource
Two problems:
1. The user model is always loaded, so in our case, there is no need for it, because we know who the owner is - i.e. the authenticated user.
1. The user model is always loaded, so in our case, there is no need for it, because we know who the owner is - i.e. the authenticated user.
So optimization #1 is pretty straightforward, just include the user only when loaded:
After this change, nothing happened, the same number of models are loaded, and same number of queries. This was the second problem.
2. The problem was mainly this statement, the statement was hydrating a user model to check the subscription with each Lead model. This would be required when loading leads of different users, but for our case, we need to change the order of the logical check.
So this is the final state of the code is as shown here. Now achieved the same results with 3 queries and 6MB only.
Amazing
isn't it!
Amazing
isn't it!
Reach out if you have questions or share similar performance enhancements.
