cmackinlay's avatar

Very slow local application response time

Hello, I have a large application in production that generally runs well - some page loads can take a few hundred ms but generally it works fine.

Locally though (Windows, Herd Pro) each page load takes many seconds and even a simple Livewire interaction will generally take more than a second.

In Debugbar almost all of the time is attributed to "Application" and "Booting" with "Routing" and "Preparing Response" being negligible.

"Application" typically takes twice as long as "Booting" e.g. 2.1s and 0.8s.

It doesn't seem to be MySql since on the page with those timings there are 10 queries, no duplicates and all take around 1-2ms.

Can anyone suggest how I can dig into the timing of the booting and request cycle? I suspect it may be to do with middleware (it's a multitenat application using tenancyforlaravel v3) but I can't work out why it is so much worse locally than in production!

Thanks for any help ;)

0 likes
4 replies
LaryAI's avatar
Level 58

Certainly! Slow local performance in Laravel (especially on Windows) is a common pain point, and it can be due to several factors. Here’s a step-by-step approach to diagnose and improve your local app’s response time:

1. Profiling with Laravel Telescope

Install Laravel Telescope to get a more granular view of what’s happening during the request lifecycle:

composer require laravel/telescope --dev
php artisan telescope:install
php artisan migrate
php artisan telescope:publish

Visit /telescope and inspect the timeline for each request. This will help you see which service providers, middleware, or listeners are taking the most time.


2. Debugging Service Providers and Booting

Since most time is spent in "Application" and "Booting", try profiling your service providers:

  • Temporarily comment out custom or third-party service providers in config/app.php and see if performance improves.
  • If you identify a culprit, dig into its boot method for heavy operations.

3. Middleware Profiling

Since you suspect middleware (especially with tenancyforlaravel), try disabling them temporarily:

  • Comment out middleware in app/Http/Kernel.php and test.
  • If you see a big improvement, re-enable them one by one to isolate the slow one.

You can also log middleware execution time:

// In a middleware handle() method
$start = microtime(true);
$response = $next($request);
\Log::info('Middleware X took: ' . (microtime(true) - $start) . ' seconds');
return $response;

4. Windows Filesystem Performance

Windows is notoriously slow with many file operations (autoloading, config caching, etc). Try these:

  • Enable Opcache in your PHP config.
  • Use WSL2 (Windows Subsystem for Linux) for your dev environment if possible. Performance is much closer to production Linux.
  • Check for antivirus interference: Exclude your project directory from Windows Defender or any antivirus.

5. Optimize Laravel Caches

Run these commands to optimize your app:

php artisan config:cache
php artisan route:cache
php artisan view:cache
composer dump-autoload -o

6. Check Composer Dependencies

Large or unnecessary dependencies can slow down bootstrapping. Run:

composer install --optimize-autoloader --no-dev

7. Tenancyforlaravel Specifics

If you’re using tenancyforlaravel:

  • Make sure you’re not running expensive tenant resolution logic on every request.
  • Profile the package’s middleware and listeners as above.

8. Xdebug

If you have Xdebug enabled, it can slow things down considerably. Disable it unless you’re actively debugging.


9. Hardware and Herd Pro

  • Ensure Herd Pro is using the latest PHP version.
  • Try increasing the allocated resources (CPU, RAM) for Herd Pro.

10. Final Step: Compare with Production

If you have SSH access to production, run php artisan profile:requests (with spatie/laravel-ray) to compare timings.


Summary:

  • Use Telescope for profiling.
  • Isolate slow service providers/middleware.
  • Optimize caches.
  • Consider WSL2 for better filesystem performance.
  • Profile any custom or package code that runs on every request.

Let me know if you need help with any of these steps or want to share more specific Telescope or Debugbar output!

cmackinlay's avatar

Thanks Larry, definitely a good Tier 1 set of suggestions :)

  1. Profiling with Laravel Telescope

    • Tried that; telescope doesn't give a timeline for activities within the request as far as I can see.
  2. Debugging Service Providers and Booting

    • Commented out Bugsnag and Horizon and ParallelTestingMultiTenantProvider
    • Nothing in withRouting
    • Removed PreventAccessFromCentralDomains and CookieConsentMiddleware from tenant middleware group
    • Removed everything from withExceptions
    • Removed everytthing fromwithSchedule

    No difference

  3. Middleware Profiling

    • There is no app/Http/Kernel.php - this is Laravel 12 :)
  4. Windows Filesystem Performance

    • Tried those where possible (not WSL as I'm trying to run Herd)
  5. Optimize Laravel Caches

    • Already part of the config
  6. Check Composer Dependencies

    • Little impact, might be marginal
  7. Tenancyforlaravel Specifics

    • That's the point, tenant needs to be identified for it to work! Anyway, it doesn't seem expensive and it doesn't cause delay in production

8 Xdebug * Not in use

  1. Hardware and Herd Pro

    • Latest version of PHP installed
  2. Final Step: Compare with Production

    • That's what started this, production is fast, local is slow.

Has anyone else got a suggestion?

https://herd.laravel.com/docs/macos/debugging/profiler looks ideal but it's not available on Windows :(

Glukinho's avatar

I'd look at anti_virus, add project folders and Herd to exclusions or even turn off completely. I had issues with Windows Defender, even php artisan tinker took 20 seconds to start.

PS why antispam here prohibits word "anti_virus" without underscore?

Stasgrin's avatar

Lib: NoiseByNorthwest/php-spx

I would advise installing this locally. Despite it being a bit of a hassle, after all, you will have a really powerful debugging instrument. Basically, you will see a flamegraph and easily \visually identify what is going on with the app.

Additionally, a profiler with Xdebug may be sufficient. You can load profiler dumps in PhpStorm, for example.

Please or to participate in this conversation.