Ist Laravel wirklich so langsam?

Ich habe gerade angefangen, Laravel zu benutzen. Ich habe noch kaum Code geschrieben, aber das Laden meiner Seiten dauert fast eine Sekunde!

Das ist ein bisschen schockierend für mich, wenn meine Framework-freien Apps und NodeJS-Apps ~ 2 ms benötigen. Was macht Laravel? Das ist kein normales Verhalten, oder? Benötigt es eine Feinabstimmung?

Laravel ist eigentlich nicht so langsam. 500-1000ms ist absurd; Ich habe es im Debug-Modus auf 20 ms gebracht.

Das Problem waren freigegebene Ordner von Vagrant / VirtualBox +. Ich wusste nicht, dass sie einen solchen Leistungshit erlitten haben. Ich denke, weil Laravel so viele Abhängigkeiten hat (lädt ~ 280 Dateien) und jeder dieser Datei-Lesevorgänge langsam ist, summiert sich das sehr schnell.

kreeves hat mich in die richtige Richtung gelenkt. Dieser Blog-Beitrag beschreibt eine neue Funktion in Vagrant 1.5, mit der Sie Ihre Dateien in die VM synchronisieren können, anstatt einen freigegebenen Ordner zu verwenden.

Unter Windows gibt es keinen nativen rsync-Client, daher müssen Sie cygwin verwenden . Installieren Sie es und stellen Sie sicher, dass Net / rsync deaktiviert ist. Fügen Sie C:\cygwin64\binIhren Pfaden hinzu. [Oder Sie können es auf Win10 / Bash installieren]

Vagrant stellt die neue Funktion vor . Ich benutze Puphet, also sieht mein Vagrantfile ein bisschen lustig aus. Ich musste es optimieren, um so auszusehen:

  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

Wenn Sie alle eingerichtet sind, versuchen Sie es vagrant up. Wenn alles reibungslos funktioniert, sollte Ihr Computer hochfahren und alle Dateien kopieren. Sie müssen vagrant rsync-autoin einem Terminal ausgeführt werden, um die Dateien auf dem neuesten Stand zu halten. Sie zahlen ein wenig Latenz, aber für 30-mal schnellere Seitenladevorgänge lohnt es sich!

Wenn Sie PhpStorm verwenden, funktioniert die Funktion zum automatischen Hochladen sogar noch besser als rsync. PhpStorm erstellt viele temporäre Dateien, die Dateibetrachter auslösen können. Wenn Sie jedoch zulassen, dass die Uploads selbst ausgeführt werden, funktioniert dies einwandfrei.

Eine weitere Option ist die Verwendung von lsyncd . Ich hatte großen Erfolg damit auf Ubuntu Host -> FreeBSD Gast. Ich habe es noch nicht auf einem Windows-Host versucht.

Um Ihnen bei Ihrem Problem zu helfen, habe ich diesen Blog gefunden, in dem es darum geht, die Laravel-Produktion zu optimieren. Das meiste, was Sie tun müssen, um Ihre App schnell zu machen, liegt nun in der Hand, wie effizient Ihr Code ist, Ihre Netzwerkkapazität, CDN, Caching, Datenbank.

Jetzt werde ich über das Problem sprechen:

Laravel ist langsam aus der Box. Es gibt Möglichkeiten, dies zu optimieren. Sie haben auch die Möglichkeit, Caching in Ihrem Code zu verwenden und Ihren Server zu verbessern, yadda yadda yadda. Aber am Ende ist Laravel immer noch langsam.

Laravel verwendet viele Symfony-Bibliotheken, und wie Sie in den Benchmarks von techempower sehen können , ist Symfony sehr niedrig (gelinde gesagt). Sie können sogar feststellen, dass der Laravel- Benchmark fast ganz unten liegt.

Im Hintergrund wird viel automatisch geladen. Dinge, die Sie möglicherweise nicht einmal benötigen, werden geladen. Da Laravel einfach zu bedienen ist, können Sie Apps schnell erstellen und verlangsamen.

Aber ich sage nicht, dass Laravel schlecht ist, es ist großartig , großartig in vielen Dingen. Wenn Sie jedoch einen hohen Verkehrsaufkommen erwarten, benötigen Sie viel mehr Hardware, um die Anforderungen zu bearbeiten. Es würde dich viel mehr kosten. Aber wenn Sie schmutzig reich sind, können Sie mit Laravel alles erreichen. : D.

Der übliche Kompromiss:

 Easy = Slow, Hard = Fast

Ich würde C oder Java als eine harte Lernkurve und eine harte Wartbarkeit betrachten, aber es hat einen sehr hohen Stellenwert in Web-Frameworks.

Obwohl nicht zu verwandt. Ich versuche nur zu beweisen easy = slow:

Ruby hat einen sehr guten Ruf in Bezug auf Wartbarkeit und die Leichtigkeit, es zu erlernen, aber es wird auch als das langsamste unter Python und PHP angesehen, wie hier gezeigt .

Ja - Laravel ist wirklich so langsam. Ich habe dafür eine POC-App erstellt. Einfacher Router mit Anmeldeformular. Ich konnte nur 60 RPS mit 10 gleichzeitigen Verbindungen auf einem digitalen Ocean-Server für 20 US-Dollar (wenige GB RAM) erhalten.

Konfiguration:

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

Ich habe Optimierungen, Composer Dump Autoload usw. ausgeführt und den RPS auf 43-ish gesenkt .

Das Problem ist, dass die App in 200-400 ms reagiert. Ich habe einen AB-Test von der lokalen Maschine ausgeführt, auf der Laravel aktiv war (dh nicht über den Webverkehr). und ich bekam nur 112 RPS; mit 200ms schnellerer Reaktionszeit mit durchschnittlich 300ms.

Im Vergleich dazu habe ich meine produktive PHP Native-App getestet, auf der täglich einige Millionen Anfragen auf einem AWS t2.medium (x3, Load Balanced) ausgeführt werden. Als ich über ELB 25 gleichzeitige Verbindungen von meinem lokalen Computer zu diesem über das Internet herstellte, erhielt ich ungefähr 1200 RPS. Großer Unterschied zwischen einer Maschine mit Last und einer Laravel-Anmeldeseite.

Dies sind Seiten mit Sitzungen (Elasticache / Memcached), Live DB-Lookups (zwischengespeicherte Abfragen über Memcached), Assets, die über CDNs gezogen wurden, usw. usw. usw.

Was ich sagen kann, Laravel klebt ungefähr 200-300ms Last über Dinge. Es ist in Ordnung für PHP-generierte Ansichten, schließlich ist diese Art von Verzögerung beim Laden tolerierbar. Bei PHP-Ansichten, die Ajax / JS verwenden, um kleine Updates zu verarbeiten, fühlt es sich jedoch langsam an.

Ich kann mir nicht vorstellen, wie dieses System mit einer Mandanten-App aussehen würde, während 200 Bots jeweils 100 Seiten gleichzeitig crawlen.

Laravel eignet sich hervorragend für einfache Apps. Lumen ist tolerierbar, wenn Sie nichts Besonderes tun müssen, das Middleware-Unsinn erfordert (IE, keine mandantenfähigen Apps und benutzerdefinierten Domänen usw.).

Ich mag es jedoch nie, mit etwas zu beginnen, das 300 ms Last für einen "Hallo Welt" -Post binden und verursachen kann.

Wenn du denkst "Wen interessiert das?"

.. Schreiben Sie eine vorausschauende Suche, die sich auf schnelle Abfragen stützt, um auf Vorschläge zur automatischen Vervollständigung über einige hunderttausend Ergebnisse zu antworten. Diese Verzögerung von 200-300 ms wird Ihre Benutzer absolut verrückt machen.

Ich habe festgestellt, dass Sie mit Laravel 4 den größten Geschwindigkeitsgewinn erzielen können, wenn Sie die richtigen Sitzungstreiber auswählen.

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)

hoffentlich hilft das

Welches ist Laravel aus meinem Hello World-Wettbewerb? Ich denke du kannst es erraten. Ich habe Docker-Container für den Test verwendet und hier sind die Ergebnisse

So machen Sie eine http-Antwort "Hello World":

• Golang mit Log Handler Standard: 6000 U / min
• SpringBoot mit Log Handler Standard: 3600 U / min
• Laravel 5 mit Off Log: 230 U / min

Ich benutze Laravel ziemlich oft und glaube einfach nicht an die Zahlen, die es mir sagt, weil das von meinem Browser gemessene End-to-End-Rendering die UNTERE Gesamtzeit von der Anfrage bis zur Fertigstellung anzeigt.

Außerdem erhalte ich auf meinem Computer bei der Arbeit etwas höhere Zahlen, wodurch die Seite merklich schneller ausgeführt wird als auf meinem Computer zu Hause.

Ich weiß nicht, wie diese Zahlen berechnet werden, aber sie werden nicht durch Beobachtung oder Browser-Tools wie Firebug bestätigt ...

Laravel ist eigentlich gar nicht so langsam, besonders wenn es optimiert ist. Es ist jedoch speicherhungrig. Selbst ein schweres CMS wie Drupal, das sehr langsam ist, scheint etwa 1/3 des Speicherbedarfs einer Laravel-Anfrage zu haben.

Um Laravel in der Produktion auszuführen, würde ich daher vor CPU-optimierten Servern auf speicheroptimierten Servern bereitstellen.

Ich weiß, dass dies eine etwas alte Frage ist, aber die Dinge haben sich geändert. Laravel ist nicht so langsam. Wie bereits erwähnt, sind synchronisierte Ordner langsam. Unter Windows 10 konnte ich jedoch nicht verwenden rsync. Ich habe beides versucht cygwinund minGW. Es scheint nicht rsynckompatibel mit git for windowsder Version von ssh.

Folgendes hat bei mir funktioniert: NFS .

Vagrant docs sagt:

NFS-Ordner funktionieren nicht auf Windows-Hosts. Vagrant ignoriert Ihre Anfrage nach NFS-synchronisierten Ordnern unter Windows.

Das stimmt nicht mehr. Wir können heutzutage vagrant-winnfsd Plugins verwenden . Es ist wirklich einfach zu installieren:

1. Ausführen vagrant plugin install vagrant-winnfsd
2. Änderung in Ihrem Vagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. Hinzufügen zu Vagrantfile:config.vm.network "private_network", type: "dhcp"

Das ist alles was ich brauchte um NFSArbeit zu machen . Die Reaktionszeit von Laravel verringerte sich für mich von 500 ms auf 100 ms.

Ich habe mich 1.40sbei der Arbeit mit einer reinen Laravel im Entwicklungsbereich konfrontiert !

Das Problem bestand php artisan servedarin, den Webserver auszuführen

Als ich stattdessen den Apache-Webserver (oder NGINX) für denselben Code verwendete, auf den ich ihn gebracht habe 153ms

Da es niemand anderes erwähnt hat, stellte ich fest, dass der xdebug-Debugger die Zeit dramatisch verlängerte. Ich habe eine grundlegende dynamische Seite "Hallo Welt, die Zeit ist 2020-01-01T01: 01: 01.010101" bereitgestellt und diese in meiner httpd.conf verwendet, um die Anfrage zeitlich zu steuern:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D**" combined

% T ist die Servierzeit in Sekunden,% D ist die Zeit in Mikrosekunden. Mit diesem in meiner php.ini:

[XDebug]
xdebug.remote_autostart = 1
xdebug.remote_enable = 1

Ich hatte ungefähr 770 ms Antwortzeiten, aber als beide auf 0 gesetzt waren, um sie zu deaktivieren, sprang es sofort auf 160 ms. Wenn beide ausgeführt wurden, wurde der Wert auf 120 ms gesenkt:

php artisan route:cache
php artisan config:cache

Der Nachteil ist, dass ich Konfigurations- oder Routenänderungen neu zwischenspeichern müsste, was ärgerlich ist.

Als Nebenbemerkung bot das Verschieben der Site von meiner SSD auf eine sich drehende Festplatte seltsamerweise keine Leistungsvorteile, was für mich sehr seltsam ist, aber ich nehme an, es ist möglicherweise zwischengespeichert, ich bin auf Windows 10 mit XAMPP.

Laravel ist langsam, da die Verwendung von PHP für Webseiten in den meisten Fällen langsam ist.

Mit Laravel wird das gesamte Framework bei jedem Aufruf neu erstellt. Deshalb verweisen alle Seiten auf index.php. Da das gesamte Framework aus PHP-Skripten besteht, müssen alle den PHP-Interpreter durchlaufen - jedes Mal. Je größer das Framework, desto länger dauert dies.

Vergleichen Sie dies mit einer "Serverumgebung" (z. B. Tomcat), in der der Server den Initialisierungscode einmal ausführt und schließlich alle Seiten im nativen Code sind (nach JIT).

Als Referenzbeispiel für dieselbe Hardware, dasselbe Betriebssystem usw. beträgt eine einfache Hallo-Welt mit JSP auf dieser Hardware 3000 U / min, dieselbe Hallo-Welt auf Laravel 51 U / s.

Der einfachste Weg, den Framework-Overhead und den daraus resultierenden maximalen RPS pro Kern zu testen, ist die Verwendung von Apache AB und einem Parallelitätswert von 1 mit einer einfachen "Hallo Welt", die dynamisch ist (um statisches Seiten-Caching zu vermeiden).