Optimiser les performances d'une application Laravel
Les requêtes N+1 et les index manquants captent toute l'attention. Voici les outils spécifiques à Laravel,Octane, Horizon, cache ciblé,qui font vraiment la différence en production.
La checklist d'audit couvre les tueurs de performance universels,requêtes N+1, index manquants, résultats non bornés. Cet article va plus loin : les outils spécifiques à Laravel qui font gagner le niveau supérieur une fois les fondamentaux corrigés.
Laravel Octane : garder le framework démarré entre les requêtes
Le PHP-FPM traditionnel démarre tout le framework,service providers, config, routes,à chaque requête. Octane (sur Swoole ou RoadRunner) garde l'application en mémoire entre les requêtes, réduisant significativement le temps de réponse sous charge. Le compromis : éviter que l'état ne fuite entre les requêtes, pas de propriétés statiques mutables, gestion prudente des singletons liés dans le container.
// config/octane.php
'server' => 'swoole',
'warm' => [
...Octane::defaultServicesToWarm(),
],
// Dangereux avec Octane : l'état statique persiste entre les requêtes
class ReportCache
{
private static array $cache = []; // fuite entre requêtes, à éviter
}Cache ciblé avec Cache::remember et les tags
Mettre en cache les requêtes coûteuses et répétées,pas toutes les requêtes. Les tags de cache permettent d'invalider une tranche spécifique de données mises en cache sans tout vider, ce qui compte dès qu'on a plus qu'une poignée de valeurs en cache.
$topProducts = Cache::tags(['products', 'dashboard'])
->remember('top-products', now()->addMinutes(30), function () {
return Product::withCount('orders')
->orderByDesc('orders_count')
->limit(10)
->get();
});
// Invalider seulement la tranche products, pas tout le cache
Cache::tags(['products'])->flush();Horizon : visibilité sur les queues
Les queue workers échouent silencieusement plus souvent qu'on ne le pense,un job lève une exception, retry trois fois, puis disparaît dans la table failed_jobs que personne ne consulte. Horizon donne des métriques en temps réel sur le débit, le temps d'attente et les échecs, avec des stratégies d'équilibrage configurables entre queues.
Telescope et Debugbar : trouver le goulot avant de deviner
Utiliser Telescope en staging pour inspecter en détail requêtes, requests et jobs,ne jamais le laisser actif sans authentification en production. Debugbar est plus léger et utile en local pour repérer les requêtes N+1 et les requêtes lentes pendant le développement, avant qu'elles n'atteignent le staging.
Mesurer avant d'optimiser. Octane ne corrigera pas des requêtes N+1, et le cache ne corrigera pas un index manquant. Profiler d'abord avec Telescope, corriger la cause racine, puis recourir à Octane et au cache pour les gains restants.
Un ordre d'optimisation réaliste
- ✓Corriger d'abord les requêtes N+1 et les index manquants,le meilleur retour, déjà couvert dans la checklist d'audit.
- ✓Ajouter du cache ciblé pour les requêtes coûteuses et répétées.
- ✓Déplacer le travail lourd vers des queues, monitorées avec Horizon.
- ✓Considérer Octane seulement ensuite,il multiplie le bénéfice d'une app déjà optimisée plutôt que de corriger une app lente.
Besoin d'aide sur ce sujet ? Audit Technique
Découvrir ce service →