Hello, everyone. My name is Jonathan Rennink. Welcome to my Eloquent Performance Patterns course. I really hope you enjoy it. To get things started, I want to talk to you about measuring your database's performance. One of the most important things you can do to speed up your Laravel applications is to measure your database's performance. Without doing this, you're essentially flying blind. You don't know how many queries you're running, you don't know how long those queries are taking, and you don't know how much data is actually coming back from the database. That's why on all of my Laravel projects, I like to use a tool called the Laravel Debug Bar. The Laravel Debug Bar is a profiling tool designed specifically for Laravel that gives you insights into the various metrics of your application. To illustrate this, I've set up a demo application that has a users page. It lists all the users in the database, including what company they belong

into the various metrics of your application. To illustrate this, I've set up a demo application that has a users page. It lists all the users in the database, including what company they belong to. I've seeded the database with a thousand companies, and each company has 50 users for a total of 50,000 users. The first thing we'll do is install the Laravel Debug Bar. We'll install it using Composer as a dev dependency because we only need this locally and because we never want it running in production as it would expose sensitive information. Now that it's installed, let's go back to the browser and hit refresh. As you can see, we've successfully installed it, and it's been automatically added to the bottom of our page. The first thing I always like to look at is the request duration. How long is this page taking to load? Ideally, I want this to be less than 200 milliseconds or even 100 milliseconds if at all possible. The next thing I like to keep

look at is the request duration. How long is this page taking to load? Ideally, I want this to be less than 200 milliseconds or even 100 milliseconds if at all possible. The next thing I like to keep a close eye on is the queries tab. The primary thing I'm looking for here is how many queries are being run. This is often a great way to identify n plus one issues. For example, let's go to the UsersController and disable the company relationship eager load. And now if we hit refresh in the browser, we can see that we've gone from two database queries to 16 database queries. And that makes sense since Laravel is now having to load the company one by one for each user. It's super important that you're able to catch these kinds of issues in local development as they often become much worse in production since you tend to have a lot more data there. Okay, let's undo this change. The next thing I like to look at is how long each query is taking

as they often become much worse in production since you tend to have a lot more data there. Okay, let's undo this change. The next thing I like to look at is how long each query is taking to run. You might only have one database query, but if it's slow, you still have a problem. For example, let's say we wanted to order our users by their name. We can easily do this by adding an orderBy name statement to our query. And if we go back to the browser and hit refresh, we can see that our users have been ordered. However, if we look at the Laravel debug bar, we can see that our combined query time has increased significantly. Previously, it was running at less than five milliseconds. Now it's taking roughly 30 milliseconds. This might be an indication that we need an index on our users name column. Let's try adding that. We'll start by running a command to create a new migration for this index.

This might be an indication that we need an index on our User's name column. Let's try adding that. We'll start by running a command to create a new migration for this index. And now let's go to that migration file and add our new name index. Now let's run our migrations. Now let's go back to the browser. Remembering that we're currently at a combined query time of 30 milliseconds and hit refresh, we're back down to less than five milliseconds. Much, much better. Finally, the last thing I want to review is the memory usage. What you may not realize is the amount of memory your application uses is almost directly correlated to the performance of your application. But the problem with the memory usage metric is it's really hard to tell if something's actually wrong. For example, if your memory usage goes from 4 megabytes to 6 megabytes, that probably won't sound any alarm bells for you,

really hard to tell if something's actually wrong. For example, if your memory usage goes from four megabytes to six megabytes, that probably won't sound any alarm bells for you, but something might still be wrong. That's why I much prefer the models tab. This metric provides the same kind of feedback as the memory usage, except in a much more understandable way. The models metric keeps track of all the models that Laravel has retrieved from the database. Right now, we can see that we've currently loaded 16 companies from the database and 16 users. Let me show you how this can be useful. Let's go to the Company model and add a new with eager load property for the users relationship. And what this does is tell Laravel to automatically load the users relationship anytime a Company is loaded. I'm not a big fan of this feature because I think it tends to create more problems than it solves.

Laravel to automatically load the users relationship anytime a Company is loaded. I'm not a big fan of this feature because I think it tends to create more problems than it solves. And our users page is a good example of this. If we refresh the page, keeping an eye on our models tab, we'll see that we go from 16 users to 816 users. That's a huge increase. But if we look at our memory usage, it's only gone up to six megabytes from the previous four megabytes. So that's what I mean when I say that the memory usage metric isn't that useful. It doesn't really give a great indication that something's wrong here. But looking at our models tab, we can see that something is definitely wrong. We're now loading 832 models from the database, even though we're only showing 16 users on the page and 16 companies. It's clear that adding the withUsers property to the Company model.

We're now loading 832 models from the database, even though we're only showing 16 users on the page and 16 companies. It's clear that adding the with users property to the Company model has had a negative impact on the performance of our page. So there you have it. If you're not using the Laravel debugbar yet on your projects, be sure to install it and keep a special eye on these database metrics.