Posted on: March 13, 2024 12:51 AM

Posted by: Renato

Categories: Laravel laravelphp PHP Dicas query

Views: 245

Como detectar consultas n+1 em PHP

# Qual é o problema de consulta n+1?

O problema de consulta n+1 é um problema comum de desempenho no desenvolvimento de software. Consultas N+1 resultam em muitas chamadas desnecessárias ao banco de dados. Isso pode fazer com que seu aplicativo tenha um desempenho semelhante ao de um caracol, especialmente à medida que os dados aumentam. Portanto, você deve estar ciente e abordar n+1 consultas para garantir que seus aplicativos sejam eficientes, responsivos e escaláveis.

Consultas N+1 ocorrem quando um aplicativo faz uma consulta ao banco de dados para recuperar um objeto e, então, para cada objeto recuperado, faz consultas adicionais para buscar objetos relacionados. Isso resulta em um total de N+1 consultas de banco de dados executadas para N objetos, o que pode reduzir significativamente a eficiência e o desempenho do aplicativo, especialmente ao lidar com grandes conjuntos de dados.

# Consultas N+1 ilustradas:

Vamos considerar um aplicativo de livraria que precisa exibir uma lista de autores e seus livros. O aplicativo pode primeiro consultar o banco de dados para recuperar todos os autores (1 consulta). Depois, para cada autor recuperado, faz outra consulta para buscar seus respectivos livros. Se houver 100 autores, isso resulta em 1 (consulta inicial) + 100 (uma para cada autor) = 101 consultas no total.

Isso é muito ineficiente e pode degradar gravemente o desempenho do aplicativo.

Para evitar o problema da consulta N+1, os desenvolvedores costumam usar técnicas como carregamento antecipado , onde os dados relacionados são carregados na própria consulta inicial do banco de dados, ou busca em lote , onde os dados associados a vários objetos são recuperados em lotes .

# Como você detecta n+1 consultas?

Se você tiver um aplicativo não trivial, provavelmente terá n+1 consultas. Se sua aplicação for construída com um framework web como Laravel ou Symfony e usar um ORM, você certamente terá muitas consultas n+1. Isso ocorre porque a camada ORM de muitas estruturas da web modernas carrega registros lentamente por padrão.

Problemas de consulta N+1 provavelmente passarão despercebidos em seus ambientes de desenvolvimento e teste. Ainda assim, eles podem prejudicar repentinamente o desempenho do aplicativo quando implantado em produção, onde o número de linhas no banco de dados é muito maior.

O sinal claro de que seu aplicativo tem n+1 consultas é um número incomumente alto de consultas ao banco de dados sendo executadas.

As consultas geralmente serão sequenciais e não sobrepostas.

Tudo isso é muito bom, mas você pode estar se perguntando: “Tudo bem, mas como posso saber quantas consultas estão sendo realizadas e se elas são 'sequenciais e não sobrepostas?'” Ótima pergunta! É aí que entram as ferramentas de monitoramento de desempenho de aplicativos (APM).

Usando Debugbar for Laravel ajuda.

This is a package to integrate PHP Debug Bar with Laravel. It includes a ServiceProvider to register the debugbar and attach it to the output. You can publish assets and configure it through Laravel. It bootstraps some Collectors to work with Laravel and implements a couple custom DataCollectors, specific for Laravel. It is configured to display Redirects and (jQuery) Ajax Requests. (Shown in a dropdown) Read the documentation for more configuration options.

This package includes some custom collectors:

• QueryCollector: Show all queries, including binding + timing
• RouteCollector: Show information about the current Route.
• ViewCollector: Show the currently loaded views. (Optionally: display the shared data)
• EventsCollector: Show all events
• LaravelCollector: Show the Laravel version and Environment. (disabled by default)
• SymfonyRequestCollector: replaces the RequestCollector with more information about the request/response
• LogsCollector: Show the latest log entries from the storage logs. (disabled by default)
• FilesCollector: Show the files that are included/required by PHP. (disabled by default)
• ConfigCollector: Display the values from the config files. (disabled by default)
• CacheCollector: Display all cache events. (disabled by default)

Bootstraps the following collectors for Laravel:

• LogCollector: Show all Log messages
• SymfonyMailCollector for Mail

And the default collectors:

• PhpInfoCollector
• MessagesCollector
• TimeDataCollector (With Booting and Application timing)
• MemoryCollector
• ExceptionsCollector

It also provides a facade interface (Debugbar) for easy logging Messages, Exceptions and Time

Require this package with composer. It is recommended to only require the package for development.

composer require barryvdh/laravel-debugbar --dev

Laravel uses Package Auto-Discovery, so doesn't require you to manually add the ServiceProvider.

The Debugbar will be enabled when APP_DEBUG is true.

If you use a catch-all/fallback route, make sure you load the Debugbar ServiceProvider before your own App ServiceProviders.

If you don't use auto-discovery, add the ServiceProvider to the providers array in config/app.php

Barryvdh\Debugbar\ServiceProvider::class,

If you want to use the facade to log messages, add this to your facades in app.php:

'Debugbar' => Barryvdh\Debugbar\Facades\Debugbar::class,

The profiler is enabled by default, if you have APP_DEBUG=true. You can override that in the config (debugbar.enabled) or by setting DEBUGBAR_ENABLED in your .env. See more options in config/debugbar.php You can also set in your config if you want to include/exclude the vendor files also (FontAwesome, Highlight.js and jQuery). If you already use them in your site, set it to false. You can also only display the js or css vendors, by setting it to 'js' or 'css'. (Highlight.js requires both css + js, so set to true for syntax highlighting)

php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider"

Make sure to add LaravelDebugbar to your flush list in config/octane.php.

    'flush' => [
        \Barryvdh\Debugbar\LaravelDebugbar::class,
    ],

For Lumen, register a different Provider in bootstrap/app.php:

if (env('APP_DEBUG')) {
 $app->register(Barryvdh\Debugbar\LumenServiceProvider::class);
}

To change the configuration, copy the file to your config folder and enable it:

$app->configure('debugbar');

You can now add messages using the Facade (when added), using the PSR-3 levels (debug, info, notice, warning, error, critical, alert, emergency):

Debugbar::info($object);
Debugbar::error('Error!');
Debugbar::warning('Watch out…');
Debugbar::addMessage('Another message', 'mylabel');

And start/stop timing:

Debugbar::startMeasure('render','Time for rendering');
Debugbar::stopMeasure('render');
Debugbar::addMeasure('now', LARAVEL_START, microtime(true));
Debugbar::measure('My long operation', function() {
    // Do something…
});

Or log exceptions:

try {
    throw new Exception('foobar');
} catch (Exception $e) {
    Debugbar::addThrowable($e);
}

There are also helper functions available for the most common calls:

// All arguments will be dumped as a debug message
debug($var1, $someString, $intValue, $object);

// `$collection->debug()` will return the collection and dump it as a debug message. Like `$collection->dump()`
collect([$var1, $someString])->debug();

start_measure('render','Time for rendering');
stop_measure('render');
add_measure('now', LARAVEL_START, microtime(true));
measure('My long operation', function() {
    // Do something…
});

If you want you can add your own DataCollectors, through the Container or the Facade:

Debugbar::addCollector(new DebugBar\DataCollector\MessagesCollector('my_messages'));
//Or via the App container:
$debugbar = App::make('debugbar');
$debugbar->addCollector(new DebugBar\DataCollector\MessagesCollector('my_messages'));

By default, the Debugbar is injected just before </body>. If you want to inject the Debugbar yourself, set the config option 'inject' to false and use the renderer yourself and follow http://phpdebugbar.com/docs/rendering.html

$renderer = Debugbar::getJavascriptRenderer();

Note: Not using the auto-inject, will disable the Request information, because that is added After the response. You can add the default_request datacollector in the config as alternative.

You can enable or disable the debugbar during run time.

\Debugbar::enable();
\Debugbar::disable();

NB. Once enabled, the collectors are added (and could produce extra overhead), so if you want to use the debugbar in production, disable in the config and only enable when needed.

Debugbar remembers previous requests, which you can view using the Browse button on the right. This will only work if you enable debugbar.storage.open in the config. Make sure you only do this on local development, because otherwise other people will be able to view previous requests. In general, Debugbar should only be used locally or at least restricted by IP. It's possible to pass a callback, which will receive the Request object, so you can determine access to the OpenHandler storage.

Laravel Debugbar comes with two Twig Extensions. These are tested with rcrowe/TwigBridge 0.6.x

Add the following extensions to your TwigBridge config/extensions.php (or register the extensions manually)

'Barryvdh\Debugbar\Twig\Extension\Debug',
'Barryvdh\Debugbar\Twig\Extension\Dump',
'Barryvdh\Debugbar\Twig\Extension\Stopwatch',

The Dump extension will replace the dump function to output variables using the DataFormatter. The Debug extension adds a debug() function which passes variables to the Message Collector, instead of showing it directly in the template. It dumps the arguments, or when empty; all context variables.

{{ debug() }}
{{ debug(user, categories) }}

The Stopwatch extension adds a stopwatch tag similar to the one in Symfony/Silex Twigbridge.

{% stopwatch "foo" %}
    …some things that gets timed
{% endstopwatch %}