Level 13
You can remove providers you do not need yes, but also be careful, something like cache you may not think you use directly, but parts of the application might.
2 likes
Mar 4, 2021
18
Level 8
Can we remove default service providers from laravel?
I just wanted to know if we aren't using any specific laravel component like laravel cache, Collection can we remove that from config/app.php
'providers' => [
/*
* Laravel Framework Service Providers...
*/
Illuminate\Auth\AuthServiceProvider::class,
Illuminate\Broadcasting\BroadcastServiceProvider::class,
Illuminate\Bus\BusServiceProvider::class,
Illuminate\Cache\CacheServiceProvider::class,
Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
Illuminate\Cookie\CookieServiceProvider::class,
Illuminate\Database\DatabaseServiceProvider::class,
Illuminate\Encryption\EncryptionServiceProvider::class,
Illuminate\Filesystem\FilesystemServiceProvider::class,
Illuminate\Foundation\Providers\FoundationServiceProvider::class,
Illuminate\Hashing\HashServiceProvider::class,
Illuminate\Mail\MailServiceProvider::class,
Illuminate\Notifications\NotificationServiceProvider::class,
Illuminate\Pagination\PaginationServiceProvider::class,
Illuminate\Pipeline\PipelineServiceProvider::class,
Illuminate\Queue\QueueServiceProvider::class,
Illuminate\Redis\RedisServiceProvider::class,
Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
Illuminate\Session\SessionServiceProvider::class,
Illuminate\Translation\TranslationServiceProvider::class,
Illuminate\Validation\ValidationServiceProvider::class,
Illuminate\View\ViewServiceProvider::class,
/*
* Package Service Providers...
*/
/*
* Application Service Providers...
*/
App\Providers\AppServiceProvider::class,
App\Providers\AuthServiceProvider::class,
// App\Providers\BroadcastServiceProvider::class,
App\Providers\EventServiceProvider::class,
App\Providers\RouteServiceProvider::class,
App\Providers\FortifyServiceProvider::class,
App\Providers\JetstreamServiceProvider::class,
],
Will it break anything?
Level 122
what possible benefit?
Level 8
I was thinking may be it can improve performance of framework.
Level 122
If you want to improve the performance, USE the cache, not remove it.
Otherwise you are just messing around and not really addressing any performance issues.
1 like
Level 8
I'm asking in general not specifically for cache component. There is redis service provider which I might not be using for my application so is it safe to comment that in config/app.php
Level 80
@pushpak130001 Don‘t use a framework at all if that worried about a few milliseconds 🙃
Level 8
Nice ! I'll save few milliseconds then.😉
1 like
Level 122
its only linking in the class incase its needed.
Messing with these things will give an benefit so small you would not be able to measure it.
Better to spend your time looking how you can make your own code more efficient if you actually have a performance issue.
Otherwise its just premature optimization
1 like
Level 33
If you're so concerned about performance you can use Lumen (which comes with almost everything turned off by default): https://lumen.laravel.com/
You're going to have a bad time though
1 like
Level 3
I don't understand the responses here. Laravel boots up a boatload of stuff and most responses (even just returning Redis cache) can take upwards of 400ms. If, for example you don't plan to use views, it doesn't make sense to just keep it. The framework doesn't add just a few ms and it doesn't seem at all like premature optimization since it could literally impact every call.
1 like
Level 122
@jonlink But the providers just register services. Not execute all the code. How long does it take to execute 10-20 lines of code?
Its not going to make a drop of difference compared to, say, caching the routes.
2 likes
Level 13
@jonlink 400ms? That is a usual response time for a full cycle while running my app on a far away server, and grabbing 50KB of data from across 8 tables with a heavy relational query. Most of my calls take 30-200ms max. I can't imagine where you get that 400ms number alone from, for just the framework booting. If I have no database calls, my response times are 10-30ms in total. All of what I said is without removing any ServiceProvider from my config. The only optimization included with my times are config/routes being cached.
1 like
Level 3
@Snapey It's not 10-20 lines of code though is it? When it hits AuthServiceProvider it registers different functions to the service provider. That one line is six function calls. After everything is registered it's also booted. I think you're slightly downplaying the impact. In most settings it won't mean much, but it is certainly making an impact.
Level 3
@Tippin to be clear the ~400ms that I observed wasn't deeply tested. My testing was literally using Postman to hit a local Docker container that was returning a single entry from a Redis socket, so it wasn't as onerous as what you're describing. In fact I've got a "health" route that just returns "ok" and even that takes more than 400ms. Routes, config, and files all cached.
That said, I should note that all these routes require authentication via a bearer token which is checked against a Redis store (again local to the server via a socket, so should be fast).
Level 122
@jonlink probably more a statement about your docker setup than Laravel
Level 3
@Snapey Except that the plain php endpoint I wrote to retrieve the entry from Redis returns in 10ms (or less).
EDIT: I should say too that I also wondered if it was related to my setup, but having the custom very short vanilla PHP endpoint seems to disprove that thoroughly.
Level 122
@jonlink does your plain php endpoint go through a webserver?
Level 3
@Snapey Yep, runs from the same container. Just awkwardly stuck into the public folder, we just hit that instead of index.php. It just instantiates a Redis connection and pulls the data we are looking for returned as a JSON object. The code is actually close to identical to what I had the route doing in Laravel, with the main difference that I couldn't use Laravel's fancy methods for reading the request.
I'm not at all against Laravel, by the way, I think it's a great framework. Like any framework it comes with some overhead. In the majority of cases rolling your own will likely result in the same overhead. There are use cases where that isn't true though. This just isn't one of those cases since we needed to ensure responses times maxed out at double digit.
Please or to participate in this conversation.