Question Laravel est-il vraiment si lent?


Je viens de commencer à utiliser Laravel. J'ai à peine écrit n'importe quel code, mais mes pages prennent presque une seconde à charger!

laravel timings

Cela me choque un peu quand mes applications sans framework et mes applications NodeJS prennent environ 2 ms. Que fait Laravel? Ce n'est pas un comportement normal est-ce? A-t-il besoin d'être affiné?


58
2018-04-25 03:18


origine


Réponses:


Laravel est ne pas réellement cette lent. 500-1000ms est absurde; Je l'ai descendu à 20ms en mode débogage.

Le problème était Vagrant / VirtualBox + dossiers partagés. Je n'ai pas réalisé qu'ils ont subi un tel succès. Je suppose que parce que Laravel a tellement de dépendances (charges ~ 280 fichiers) et que chacune de ces lectures de fichiers est lente, elle s’ajoute très rapidement.

Kreeves m'a orienté dans la bonne direction, ce billet de blog décrit une nouvelle fonctionnalité de Vagrant 1.5 qui vous permet de synchroniser vos fichiers sur la machine virtuelle plutôt que d'utiliser un dossier partagé.

Il n'y a pas de client rsync natif sur Windows, vous devrez donc utiliser cygwin. Installez-le et assurez-vous de cocher Net / rsync. Ajouter C:\cygwin64\bin à vos chemins.

Vagrant introduit la nouvelle fonctionnalité. J'utilise Puphet, donc mon fichier Vagrant semble un peu drôle. J'ai dû le modifier pour ressembler à ceci:

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", 
        id: "#{folder['id']}", 
        type: "rsync",
        rsync__auto: "true",
        rsync__exclude: ".hg/"
    end
  end

Une fois que vous êtes tous mis en place, essayez vagrant up. Si tout se passe bien, votre machine doit démarrer et copier tous les fichiers. Vous devrez exécuter vagrant rsync-auto dans un terminal pour garder les fichiers à jour. Vous allez payer un peu de latence, mais pour des chargements de pages 30 fois plus rapides, cela en vaut la peine!


Si vous utilisez PhpStorm, sa fonction de téléchargement automatique fonctionne encore mieux que rsync. PhpStorm crée beaucoup de fichiers temporaires qui peuvent tromper les observateurs de fichiers, mais si vous le laissez gérer lui-même les téléchargements, cela fonctionne parfaitement.


80
2018-04-26 18:08



Pour vous aider avec votre problème, j'ai trouvé cela Blog qui parle de l'optimisation de la production de laravel. La majeure partie de ce que vous devez faire pour rendre votre application rapide dépendra désormais de l’efficacité de votre code, de votre capacité réseau, de votre CDN, de votre mise en cache et de votre base de données.

Maintenant, je vais parler de la question:

Laravel est lent à sortir de la boîte. Il y a des moyens de l'optimiser. Vous avez également la possibilité d'utiliser la mise en cache dans votre code pour améliorer votre machine serveur, yadda yadda yadda. Mais au final, Laravel est toujours lent.

Laravel utilise beaucoup de bibliothèques symfony et comme vous pouvez le voir dans benchmark de techempower, symfony est très bas (le moins que l’on puisse dire). Vous pouvez même trouver le laravel référence être presque au fond.

Il y a beaucoup de chargement automatique en arrière-plan, des choses dont vous n'avez peut-être même pas besoin. Donc, techniquement, parce que laravel est facile à utiliser, cela vous aide à créer des applications rapidement, cela le ralentit également.

Mais je ne dis pas que Laravel est mauvais, c'est génial, super bien des choses. Mais si vous vous attendez à une forte augmentation du trafic, vous aurez besoin de beaucoup plus de matériel pour traiter les requêtes. Cela vous coûterait beaucoup plus cher. Mais si vous êtes très riche, vous pouvez réaliser n'importe quoi avec Laravel. :RÉ

Le compromis habituel:

 Easy = Slow, Hard = Fast

Je considérerais que C ou Java ont une courbe d’apprentissage difficile et une dureté de maintenance, mais il se classe très haut dans les frameworks Web.

Bien que pas trop lié. J'essaie juste de prouver le point de easy = slow:

Ruby a une très bonne réputation en termes de maintenabilité et de facilité à apprendre, mais il est également considéré comme le plus lent parmi les pythons et les php, comme indiqué ici.

enter image description here


21
2018-04-25 03:29



J'ai trouvé que le plus grand gain de vitesse avec Laravel 4 vous permet de choisir les bons pilotes de session;

Sessions "driver" file;

Requests per second:    188.07 [#/sec] (mean)
Time per request:       26.586 [ms] (mean)
Time per request:       5.317 [ms] (mean, across all concurrent requests)


Session "driver" database;

Requests per second:    41.12 [#/sec] (mean)
Time per request:       121.604 [ms] (mean)
Time per request:       24.321 [ms] (mean, across all concurrent requests)

J'espère que cela pourra aider


12
2017-10-01 06:29



De mon concours Hello World, Lequel est Laravel? Je pense que vous pouvez deviner. J'ai utilisé docker container pour le test et voici les résultats

Pour faire une réponse http "Hello World":

  • Golang avec un manipulateur de bûche stdout: 6000 rps
  • SpringBoot avec gestionnaire de journaux stdout: 3600 rps
  • Laravel 5 avec off log: 230 Rps

11
2018-01-05 05:32



Oui - Laravel est vraiment si lent. J'ai construit une application POC pour cela. Routeur simple, avec un formulaire de connexion. Je pouvais seulement obtenir 60 RPS avec 10 connexions simultanées sur un serveur océanique numérique de 20 $ (peu de RAM);

Installer:

2gb RAM
Php7.0
apache2.4
mysql 5.7
memcached server (for laravel session)

J'ai exécuté des optimisations, composeur autoload dump, etc. abaissé le RPS à 43-ish.

Le problème est que l'application répond dans 200-400ms. J'ai effectué un test AB à partir de la machine locale où se trouvait le système (c’est-à-dire pas via le trafic Web); et j'ai seulement 112 RPS; avec un temps de réponse de 200 ms plus rapide avec une moyenne de 300 ms.

Comparativement, j'ai testé mon application PHP native de production en exécutant quelques millions de requêtes par jour sur un AWS t2.medium (x3, charge équilibrée). Quand j'ai eu 25 connexions simultanées de ma machine locale à celle sur le Web, via ELB, j'ai eu environ 1200 RPS. Différence énorme sur une machine avec une charge par rapport à une page "login".

Ce sont des pages avec des sessions (elasticache / memcached), des recherches dans Live DB (requêtes en cache via memcached), des ressources récupérées sur des CDN, etc., etc., etc.

Ce que je peux dire, les bâtons de laravel se situent à environ 200-300ms. C'est bien pour PHP Des vues générées, après tout, ce type de délai est tolérable en charge. Cependant, pour les vues PHP qui utilisent Ajax / JS pour gérer de petites mises à jour, cela commence à être lent.

Je ne peux pas imaginer à quoi ressemblerait ce système avec une application multi-locataires, alors que 200 robots analysent chacun 100 pages en même temps.

Laravel est idéal pour les applications simples. Lumen est tolérable si vous n'avez pas besoin de faire quelque chose de compliqué qui nécessiterait un non-sens du middleware (IE, pas d'applications multi-locataires et de domaines personnalisés, etc.);

Cependant, je n'aime jamais commencer avec quelque chose qui peut lier et causer 300ms de chargement pour un message "Bonjour tout le monde".

Si vous pensez "Qui s'en soucie?"

.. Créez une recherche prédictive basée sur des requêtes rapides pour répondre aux suggestions de saisie semi-automatique sur quelques centaines de milliers de résultats. Ce retard de 200-300ms conduira vos utilisateurs absolument fou.


7
2017-11-16 02:30



J'utilise pas mal Laravel et je ne crois tout simplement pas aux chiffres qu'il me dit, car le rendu de bout en bout, mesuré par mon navigateur, indique un temps total inférieur de la demande à la fin.

De plus, j'obtiens des nombres légèrement plus élevés sur ma machine au travail, ce qui exécute la page sensiblement plus vite que ma machine à la maison.

Je ne sais pas comment ces chiffres sont calculés, mais ils ne sont pas corroborés par des observations ou des outils de navigation comme Firebug ...

Laravel n'est pas si lent que ça, surtout lorsqu'il est optimisé. Il a faim de mémoire cependant. Même un CMS lourd comme Drupal, qui est très lent, semble avoir environ 1/3 de l'empreinte mémoire d'une requête de Laravel.

Ainsi, pour exécuter Laravel en production, je me déploierais sur des serveurs optimisés en mémoire avant les serveurs optimisés pour la CPU.


4
2018-04-25 06:12



Je sais que c'est une petite question ancienne, mais les choses ont changé. Laravel n'est pas si lent. Comme mentionné, les dossiers synchronisés sont lents. Cependant, sur Windows 10, je ne pouvais pas utiliser rsync. J'ai essayé les deux cygwin et minGW. Il semble que rsync est incompatible avec git for windowsla version de ssh.

Voici ce qui a fonctionné pour moi: NFS.

Documents vagabonds dit:

Les dossiers NFS ne fonctionnent pas sur les hôtes Windows. Vagrant ignorera votre demande de dossiers synchronisés NFS sous Windows.

Ce n'est plus vrai. On peut utiliser vagrant-winnfsd  brancher aujourd'hui. C'est vraiment simple à installer:

  1. Exécuter vagrant plugin install vagrant-winnfsd
  2. Changer dans votre Vagrantfile: config.vm.synced_folder ".", "/vagrant", type: "nfs"
  3. Ajouter à Vagrantfile: config.vm.network "private_network", type: "dhcp"

C'est tout ce dont j'avais besoin pour faire NFS travail. Le temps de réponse de Laravel est passé de 500 ms à 100 ms pour moi.


2
2018-06-15 07:26



Laravel est lent, car dans la plupart des cas, l'utilisation de PHP pour les pages Web est lente.

Avec Laravel, la structure entière est reconstruite à chaque appel - c'est pourquoi toutes les pages pointent vers index.php. Comme tout le framework est constitué de scripts PHP, ils doivent tous passer par l’interpréteur PHP - à chaque fois. Plus le cadre est large, plus cela prend de temps.

Comparez cela avec un "environnement serveur" (par exemple, tomcat) où le serveur exécute le code d'initialisation une seule fois, et éventuellement toutes les pages seront en code natif (après JIT).

Comme exemple de référence, en utilisant le même matériel, le même système d’exploitation, etc., un simple «monde salutaire» utilisant JSP sur ce matériel est de 3 000 tr / min, le même monde salut sur laravel est de 51 tr / s.

Le moyen le plus simple de tester le temps système et le nombre maximum de RPS par cœur est d'utiliser Apache AB et une valeur de simultanéité de 1, avec un simple «monde de salutations» dynamique (pour éviter la mise en cache statique des pages).


0
2017-07-23 22:20