2017-10-12 1 views
0

J'essaie de réduire mon TTFB à moins de 200 ms. Actuellement il est plus de 600ms.Identification du goulot d'étranglement sur l'application Laravel avec profilage Blackfire

Mon application utilise Laravel avec AsgardCMS. J'ai implémenté très peu de code personnalisé, et la base de données a 28 tables avec moins de 100 enregistrements au total.

J'ai installé la mise en cache de Redis (et activé la mise en cache), et j'ai exécuté php artisan optimize. J'utilise également Nginx avec Apache via Engintron.

Fondamentalement, j'ai essayé d'éliminer autant du goulot d'étranglement que possible! Cependant, après l'installation de Blackfire, il indique que Composer\Autoload\includeFile prend un total de 250 ms (plus de 299 appels). On l'appelle également 141 fois avec un temps total de 49ms.

Je reconnais qu'il est normal que l'autoloader soit appelé plusieurs fois, mais devrait-il vraiment prendre 250ms?

Mon VPS a 2 cœurs (processeur Intel Xeon) et 4 Go de RAM (dédié). Je viens de mettre à jour de 1 core et 2 Go de RAM, mais à peine remarqué une différence. Les disques sont des disques SSD. En cours d'exécution sur WHM/cPanel btw. Environ 10 sites sur le serveur, mais aucun d'entre eux particulièrement trafic élevé, et ces tests ont été exécutés pendant les périodes les plus calmes.

Dans le dernier essai, Blackfire rapporté: -

Time: 696ms 
I/O Wait: 149ms 
CPU time: 548ms 
SQL Queries: 2.38ms 

Toutes les idées? Plutôt s'il vous plaît ...

+0

* J'utilise aussi Nginx avec Apache * beaucoup de gens dans d'autres technologies peuvent utiliser nginx comme proxy inverse ** * * mais je ne comprends pas quand il s'agit de PHP, n'est-ce pas? pourquoi avez-vous besoin d'apache aussi? – teeyo

+1

Avez-vous activé ** opcache **? OPcache améliore les performances de PHP en stockant le bytecode de script précompilé dans la mémoire partagée, ce qui évite à PHP de charger et d'analyser des scripts à chaque requête. Cela m'a beaucoup aidé avec mon site web Drupal, quand je vérifie les statistiques, c'est juste incroyable! – teeyo

+0

@teeyo - oui en utilisant nginx comme un proxy inverse, seulement parce que je voulais voir si elle produisait des gains de performance, et comme le serveur utilise WHM/cPanel je ne voulais pas me débarrasser complètement d'Apache ... pour le moment (pas sûr si même possible). – pavsid

Répondre

0

Alors que je ne suis pas allé au fond de savoir s'il y avait un problème avec le serveur, ou le code PHP, ou si la "lenteur" de l'application était à prévoir, suite les commentaires sur ce sujet et les commentaires sur le lien fourni par @teeyo (https://laracasts.com/discuss/channels/laravel/adventures-in-increasing-laravel-performance) J'ai décidé de tester PHP7. WHM facilitait l'activation de PHP7 pour ce compte uniquement, ce qui était assez simple. Ran un autre test, qui est sorti environ 400ms - génial, mais toujours pas moins de 200ms.

Alors, j'ai décidé d'essayer de permettre à PHP-FPM, qui était aussi un sinch via WHM ...

F *** ME! Maintenant, je suis en train de faire 100ms! Et pour couronner le tout, si je désactive Engintron, je me rase 10-20ms de plus !! (Bien que cela ne soit probablement pas recommandé pour les sites à fort trafic, comme il ne bénéficiera pas de reverse proxy nginx).

Quoi qu'il en soit, merci à tous pour votre entrée ... espérons que cette aide d'autres ...