When using the simplest route, what core scripts are usually run?

@Sinnbeck Is debugbar something I need to install with composer, or it's built in with Laravel 6? Because if it's not built-in, I think you know where it goes😭😭.

I am still waiting for approval of Satis...

Also, It's not necessarily just DB. Because the developer from some reason used permission system in the Middleware.. so the Middleware folder is bloated with dozens of files that just "check for permissions" . . I don't think it's the right place to put it

@Ligonsker Ah. Yes its a package. But you can do it manually in laravel 6 https://laravel.com/docs/6.x/database#listening-for-query-events

@Sinnbeck There is actually a DB::connection() already in AppServiceProvider. I noticed that when TTFB is high, then this db connection script takes also longer than its usual. I measure it with microtime() and dd the result.

But, sometimes when the TTFB is higher then this script is running at its normal time. So it looks like it's more than just DB connection causing these random peaks. Some folders that shouldn't be bloated are bloated. So I guess it's not just checking for db connection alone. It could actually be some scripts in Middleware or Providers. But are there other places I should look for instead of these two for the basic route request?

Update: I managed to narrow down to this part of index.php:

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

Any idea what are the major things that happen there? Which parts does it load here?

@Ligonsker it calls laravel. That's the entry point. So it's narrowed down to "all of laravel (minus cli)

@Sinnbeck 😂🤣Time to look further then (I mean there is also $app->make so I thought it takes care of other things which will narrow down to look in less folders) I guess I'll have to check each script in Middleware and Providers now. Any where else to look for?

@Ligonsker yeah make just creates the container :) but try setting up a queue listener to see if queries are made. You can perhaps log them

@Sinnbeck Will do it

But the docs only provide the following example:

        DB::listen(function ($query) {
            // $query->sql
            // $query->bindings
            // $query->time
        });

Which one should I log? just the sql? For example:

        DB::listen(function ($query) {
           Log::debug($query->sql);
        });

Or it's not the correct way?

@Ligonsker yeah that should be fine 👍

@Sinnbeck Thanks, I output all the options: sql, bindings and time. Doesn't seem like that's the one causing it.

sql: select top 1 from users where id = ? // I assume that's to get the authenticated user
bindings: 264 //  264 bindings? why? but anyway the time is not affected too much
time: 12.19

And even when the page randomly loads slower, the above output remains about the same

I wonder what else that causes this 1 second (and sometimes close to 2 seconds) random jumps. Need to look more

I still suspect the bloated Middleware. Imagine that they built the app in such way that for every different part in the app you want some permisson to some user or group of users, there's a Middleware for that.

For example.. permission for group X <-- put the DB check as a Middleware, say GroupXMiddleware (So it registers it on every page load, even when not needed?). And there are dozens. Even for specific users:

User with id Y? Register it as a middleware in Kernel. What the middleware does? Simply check with DB if the user has the corresponding permission in the permission table. But why it was put in the Middleware? That doesn't even look like what's a Middleware is for. And why not using Laravel's built-in permission check? Or Spatie? it just doesn't seem right

Update: I just logged the entire Kernel.php, and it doesn't seem like the thing that causes the high TTFB, because even when the TTBF is high, Kernel.php only executed at very low times, like 0.00061607.

Now because the Log Facade is not registered yet in the Kernel.php file, I had to echo the microtime() inside <script></script> tags so it will show in the browser console

So no idea where to look for now what causes these peaks