Foi liberado em 28/09 o release 9.32 do Laravel.
A grande novidade deste release é a inclusão do helper Benchmark.
Com ele é possível medir o tempo de execução de qualquer processo dentro da aplicação de forma isolada, bastando para isso adicionar a referência use Illuminate\Support\Benchmark; na classe onde a análise será feita.
A classe Benchmark possui apenas dois métodos estáticos a saber:
public static function measure(Closure|array $benchmarkables, int $iterations = 1): array|float
public static function dd(Closure|array $benchmarkables, int $iterations = 1): void
Ambos recebem dois parâmetros:
$benchmarkables: array de funções para análise do tempo de processamento$iterations: inteiro que indica a quantidade de iterações que serão aplicadas às funções do parâmetro anterior. Este parâmetro é opcional.
O método measure retorna um array com o tempo de cada função executada. Já o método dd, como o próprio nome diz, executa um dd (dump and die) comando bem comum em PHP geralmente utilizado para mostrar o valor de uma variável na camada de apresentação.
Testando
Para efeitos didáticos, vamos montar um exemplo simples onde consultaremos um cliente através do seu ID, utilizando 5 abordagens distintas.
⚠️ Conhecimento prévio sobre aplicações Laravel (criação, configuração e execução) é requerido.
As consultas serão feitas em uma tabela que possui 1037 registros, através de uma contoller chamada CustomerController. Apesar do pouco volume de informações, ressalto que a máquina onde os testes serão executados não possui uma performance elevada, equilibrando os resultados.
Migração
O arquivo de migração abaixo dará uma noção da estrutura da tabela de clientes, ajudando a compreender melhor o ambiente utilizado nos testes.
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('customers', function (Blueprint $table) {
$table->id();
$table->foreignId('user_id')->constrained();
$table->string('last_name');
$table->string('first_name');
$table->string('email')->nullable();
$table->string('phone', 30)->nullable();
$table->string('street');
$table->string('city');
$table->string('building_number', 30);
$table->string('country');
$table->string('post_code');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('customers');
}
};
Rota
Vamos editar o arquivo de rotas de api (\routes\api.php) criando uma nova rota e adicionando a referência para a controller CustomerController que criaremos em breve:
Route::get('/{id}/show', [CustomerController::class, 'show']);
E a referência para a controller:
use App\Http\Controllers\CustomerController;
Controller
Nossa controller terá apenas um método responsável por consultar o cliente de acordo com o ID informado.
Abaixo como a classe deve se parecer:
<?php
namespace App\Http\Controllers;
use App\Models\Customer;
use Illuminate\Database\Eloquent\Relations\BelongsTo;
use Illuminate\Http\Request;
use Illuminate\Support\Benchmark;
use Illuminate\Support\Facades\DB;
class CustomerController extends Controller
{
public function show(int $id)
{
$customer = Customer::find($id);
$result = Benchmark::measure(
[
'Scenario 1' => fn() => Customer::find($id),
'Scenario 2' => fn() => Customer::where('id', ($id))->get(),
'Scenario 3' => fn() => DB::table('customers')->where('id', $id)->first(),
'Scenario 4' => fn() => DB::table('customers')->where('id', $id)->get(),
'Scenario 5' => fn() => DB::select('select * from customers where id = ?', [$id])
], 10);
if ($customer) {
return response()->json([
'time' => $result,
'data' => $customer]);
} else {
return response()->json(['message' => 'Customer not found'], 404);
}
}
}
Perceba que à frente de cada funções adicionei um álias: 'Scenario 1', 'Scenario 2', etc.
Esse álias, apesar de opcional, ajudará bastante a identificar qual tempo refere-se a qual função analisada.
Testando
Assim que a aplicação estiver executando vamos fazer uma chamada à rota que configuramos anteriormente e informar um código para pesquisar o cliente.
Explicando
Cenário 1
A consulta realizada neste cenário é a mais básica, onde utilizamos o próprio modelo para buscar o cliente através da chave primária com o método find.
Apesar do tempo não ser um dos melhores, há que se frisar que existe um custo de processamento para converter o resultado no modelo Customer.
Cenário 2
Neste o tempo melhorou um pouquinho em relação ao cenário anterior. A diferença é que passamos a coluna id diretamente para consultar.
Acredito que se a coluna id não fosse indexada o resultado seria significativamente pior.
E neste cenário ainda temos o custo de conversão do resultado da consulta no modelo Customer.
Cenário 3
A partir deste cenário ficamos mais próximos do banco de dados realizando consultas consideradas mais 'brutas'.
Por conta dessa abordagem note que os tempos de retorno são melhores justamente por eliminarmos o processamento feito na camada de abstração do Eloquent ORM.
Cenário 4
A única diferença em relação ao cenário anterior é que estamos utilizando o método get() ao invés do método first().
Ocorre que ao executarmos o método first() há um processamento adicional para retornar somente o primeiro registro da consulta o que não acontece com o método get().
Cenário 5
Na maioria dos testes este se mostrou o mais rápido de todos porque passamos uma consulta 'bruta' ao banco de dados filtrando o cliente pelo ID informado no parâmetro.
Apesar do tempo consideravelmente menor é importante lembrar que este tipo de consulta não se aplica a todas as situações possíveis.
Um bom exemplo onde o resultado poderia se apresentar mais produtivo, seriam as funções de agregação de dados (sum, max, count, etc) onde é menos custoso já trazer as consultas agrupadas ao invés de fazer um processamento adicional na aplicação.
Todos os testes foram executados 10 vezes, conforme informamos no parâmetro opcional $iterations do método estático measure(). Então, o resultado mostrado refere-se ao tempo médio das 10 tentativas realizadas.
Ao suprimir este parâmetro cada uma das funções será executada apenas uma vez.
Adições
Este release também trouxe outras funcionalidades:
Caminho do arquivo na função 'dd'
A partir deste release, sempre que utilizarmos a função dd (dump and die) o caminho completo do arquivo também fará parte do resultado
(mais detalhes aqui)
Encriptar e decriptar arquivos .env
Foram adicionados dois novos comandos ao script artisan, com a finalidade de gerar um arquivo encriptado a partir do arquivo '.env', bem como decriptá-lo.
Para encriptar: php artisan env:encrypt
Para decriptar: php artisan env:decrypt
Lembrando que os comandos devem ser executados utilizando o terminal de sua preferência a partir do diretório raiz da aplicação.
(mais detalhes aqui)
A lista completa das novas funcionalidades deste release, bem como correções e melhoramentos, pode ser encontrada aqui (em inglês).
Até breve!
😎
Top comments (0)