Foi liberado em 28/09 o launch 9.32 do Laravel.
A grande novidade deste launch é 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 IlluminateSupportBenchmark; na classe onde a análise será feita.
A classe Benchmark possui apenas dois métodos estáticos a saber:
public static perform measure(Closure|array $benchmarkables, int $iterations = 1): array|float
public static perform 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 quantity de informações, ressalto que a máquina onde os testes serão executados não possui uma efficiency 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 IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;
return new class extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public perform up()
{
Schema::create('clients', perform (Blueprint $desk) {
$desk->id();
$desk->foreignId('user_id')->constrained();
$desk->string('last_name');
$desk->string('first_name');
$desk->string('e-mail')->nullable();
$desk->string('cellphone', 30)->nullable();
$desk->string('avenue');
$desk->string('metropolis');
$desk->string('building_number', 30);
$desk->string('nation');
$desk->string('post_code');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public perform down()
{
Schema::dropIfExists('clients');
}
};
Rota
Vamos editar o arquivo de rotas de api (routesapi.php) criando uma nova rota e adicionando a referência para a controller CustomerController que criaremos em breve:
Route::get('/{id}/present', [CustomerController::class, 'show']);
E a referência para a controller:
use AppHttpControllersCustomerController;
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 AppHttpControllers;
use AppModelsCustomer;
use IlluminateDatabaseEloquentRelationsBelongsTo;
use IlluminateHttpRequest;
use IlluminateSupportBenchmark;
use IlluminateSupportFacadesDB;
class CustomerController extends Controller
{
public perform present(int $id)
{
$buyer = Buyer::discover($id);
$end 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 ($buyer) {
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: ‘Situation 1’, ‘Situation 2’, and many others.
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 discover.
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 Buyer.
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 Buyer.
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 notice 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, rely, and many others) 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 launch também trouxe outras funcionalidades:
Caminho do arquivo na função ‘dd’
A partir deste launch, 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 launch, bem como correções e melhoramentos, pode ser encontrada aqui (em inglês).
Até breve!
😎
