webspark/profiling-laravel

Lightweight profiling package for Laravel projects.

1.0.1 2024-04-30 17:54 UTC

This package is auto-updated.

Last update: 2024-05-30 15:19:40 UTC


README

pipeline coverage release

Navigation

Installation

You can install the package via composer:

composer require webspark/profiling-laravel

Configuration

1. Profiling configs.

You can override default configs by specifying them in your .env file:

PROFILING_SPEED_ENABLED={true|false}
PROFILING_SPEED_LATENCY={profiling latency in miliseconds}

PROFILING_TIMINGS_ENABLED={true|false}

2. Enable profiling.

To enable profiling you need to add ProfilingServiceProvider to your providers list. After this you need to enable profiling in your .env file:

PROFILING_SPEED_ENABLED=true
PROFILING_TIMINGS_ENABLED=true

3. Processors.

By default, speed profiler will use InMemoryProfilingProcessor to collect profiling logs. This will give you profiling statistics on the current page load. To collect historical logs of all actions you need to create your own processor or use one proposed by us. Your custom processor must implement an interface ProfilingProcessorInterface.

You can use LogChannelProfilingProcessor for storing profiling logs in a laravel log file. You need to provide laravel logging channel for processor constructor.

To use custom processor you need to override speed profiler registration in service provider:

class CustomProfilingServiceProvider extends ProfilingServiceProvider
{
    protected function speedProfilingProcessor(): ProfilingProcessorInterface
    {
        return new LogChannelProfilingProcessor('daily');
    }
}

Usage

Speed profiling.

1. Speed profiling global actions.

To add global profiling you should add SpeedProfilingMiddleware to your middlewares list. It will start speed profiling for every request to your project.

2. Speed profiling statistic command.

Command output contains this fields: Max - the largest time of all logged requests, Avg - the average time of all logged action requests, Med - the median time of all logged action requests without 10% from the max execution and 10% from the min execution, Min - the smaller time of all logged action requests, Call - count of logged action requests and Action - the name of action.

 Max:   57.33   | Avg:   55.16 | Med:   52.32  | Min:   49.33  | Calls:    87 - App\Http\Controllers\Frontend\Auth\LoginController@login 
 Max:   17.28   | Avg:   15.21 | Med:   14.39  | Min:   13.19  | Calls:    43 - App\Http\Controllers\Frontend\HomeController@index 
 Sorted by max

Artisan command name: profiling:speed-statistic. You can specify date (by default the all logged dates are in format Y-m-d), limit rows (by default is 10) and sorting (by default sorting by max time).

Sorting can be: max (from larger max time to smaller), min (from larger min time to smaller), avg (from larger avg time to smaller), med (from larger med time to smaller) and calls (from larger count of calls to smaller).

php artisan profiling:speed-statistic --sort=calls --limit=20 --date=2024-03-25

3. Speed profiling for methods.

For methods profiling you need to create a profiler object in this method.

class Example
{
    public function execute(): void
    {
        $profiler = new SpeedProfiler('Example execute action.');
        
        ... // some logic
    }
}

Timings profiling.

Timings profiling is a useful tool to see how much time it takes on your code parts. You can see measurement results in browser in network in section Timing.

example.png

1. Enable timings profiling.

To enable timings in browser you should add TimingsProfilingMiddleware to your middlewares list.

By default, you will that timings: Bootstrap (framework initialisation), App (time from route action was detected to exit from application) and Database (how much time was spent on database queries).

All timings you will also have in speed profiler logs - it is helpful thing to understand how much time was taken on code parts for long term action.

2. Timing measurements.

You can add additional timing measurements:

public function execute(): void
{
    TimingsProfiling::start('Execute');
    
    ... // some logic
    
    TimingsProfiling::stop('Execute');
}

You also can just start timing. It will stop on application response.

public function execute(): void
{
    TimingsProfiling::start('Execute');
    
    ... // some logic
}

You also can use TimingsProfiler to add your timings. It will stop measurement on profiler destructor, when script leaves a method.

class Example
{
    public function execute(): void
    {
        $profiler = new TimingsProfiler('Example action');
        
        ... // some logic
    }
}

Simple way to write callback execution measurement:

TimingsProfiling::setDuration('Timing name', static function () {
    ... // some logic here
});

There is another way to add measurement. The better place to use it is to measure repetitive actions, like time, that spent on external requests. It will increase previously finished measurements.

public function execute(): void
{
    $startPoint = microtime(true);
    
    ... // some logic
    
    TimingsProfiling::increment('Requests', (microtime(true) - $startPoint) * 1000);
}

Testing

composer test

Changelog

Please see CHANGELOG for more information on what has changed recently.

License

The MIT License (MIT). Please see License File for more information.