Geekflare wird von unserem Publikum unterstützt. Wir können Affiliate-Provisionen durch den Kauf von Links auf dieser Website verdienen.
Teilen:

Wie optimiere ich die PHP Laravel-Webanwendung für hohe Leistung?

Laravel-Optimierung
Invicti Web Application Security Scanner – die einzige Lösung, die eine automatische Verifizierung von Schwachstellen mit Proof-Based Scanning™ bietet.

Laravel ist vieles. Aber schnell ist keiner von ihnen. Lassen Sie uns einige Tricks des Handels lernen, um es schneller zu machen!

Kein PHP-Entwickler bleibt davon unberührt Laravel heutzutage. Sie sind entweder Junior- oder Mid-Level-Entwickler, die die schnelle Entwicklung von Laravel lieben, oder sie sind Senior-Entwickler, die aufgrund des Marktdrucks gezwungen sind, Laravel zu lernen.

Auf jeden Fall ist nicht zu leugnen, dass Laravel das PHP-Ökosystem wiederbelebt hat (ich hätte die PHP-Welt sicher schon vor langer Zeit verlassen, wenn Laravel nicht da gewesen wäre).

Ein Ausschnitt aus (etwas gerechtfertigtem) Selbstlob von Laravel

Da sich Laravel jedoch nach hinten beugt, um Ihnen die Arbeit zu erleichtern, bedeutet dies, dass darunter jede Menge Arbeit geleistet wird, um sicherzustellen, dass Sie ein angenehmes Leben als Entwickler haben. Alle „magischen“ Funktionen von Laravel, die scheinbar nur funktionieren, verfügen über mehrere Codeebenen, die bei jeder Ausführung eines Features aktualisiert werden müssen. Sogar eine einfache Ausnahme zeigt, wie tief das Kaninchenloch ist (beachten Sie, wo der Fehler beginnt, bis hinunter zum Hauptkern):

Für einen Kompilierungsfehler in einer der Ansichten müssen 18 Funktionsaufrufe verfolgt werden. Ich persönlich bin auf 40 gestoßen, und es könnte leicht mehr geben, wenn Sie andere Bibliotheken und Plugins verwenden.

Der Punkt ist, dass diese Ebenen standardmäßig Laravel langsam machen.

Wie langsam ist Laravel?

Ehrlich gesagt ist es aus mehreren Gründen unmöglich, diese Frage zu beantworten.

VornameEs gibt keinen akzeptierten, objektiven und vernünftigen Standard zum Messen der Geschwindigkeit von Web-Apps. Schneller oder langsamer als was? Unter welchen Bedingungen?

ZweiteEine Web-App hängt von so vielen Dingen ab (Datenbank, Dateisystem, Netzwerk, Cache usw.), dass es einfach albern ist, über Geschwindigkeit zu sprechen. Eine sehr schnelle Web-App mit einer sehr langsamen Datenbank ist eine sehr langsame Web-App. 🙂

Aber genau diese Unsicherheit ist der Grund, warum Benchmarks beliebt sind. Auch wenn sie nichts bedeuten (siehe fehlen uns die Worte. und fehlen uns die Worte.), Sie liefern einige Bezugsrahmen und helfen Sie uns, verrückt zu werden. Lassen Sie uns daher mit mehreren Prisen Salz eine falsche, grobe Vorstellung von der Geschwindigkeit unter uns bekommen PHP-Frameworks.

An diesem ziemlich respektablen GitHub vorbei QuelleSo sehen die PHP-Frameworks im Vergleich aus:

Sie werden Laravel hier vielleicht nicht einmal bemerken (selbst wenn Sie wirklich hart blinzeln), es sei denn, Sie werfen Ihren Fall bis zum Ende des Schwanzes. Ja, liebe Freunde, Laravel kommt zuletzt! Zugegeben, die meisten dieser „Frameworks“ sind nicht sehr praktisch oder sogar nützlich, aber es zeigt uns, wie träge Laravel im Vergleich zu anderen populäreren ist.

Normalerweise tritt diese „Langsamkeit“ in Anwendungen nicht auf, da unsere alltäglichen Web-Apps selten hohe Zahlen erreichen. Aber sobald sie dies tun (z. B. ab 200-500 Parallelität), beginnen die Server zu ersticken und zu sterben. Es ist die Zeit, in der noch mehr Hardware auf das Problem geworfen wird und die Infrastrukturrechnungen so schnell steigen, dass Ihre hohen Ideale für Cloud Computing zusammenbrechen.

Aber hey, sei fröhlich! In diesem Artikel geht es nicht darum, was nicht getan werden kann, sondern darum, was getan werden kann. 🙂

Die gute Nachricht ist, dass Sie viel tun können, um Ihre Laravel-App schneller zu machen. Mehrmals schnell. Ja, kein Scherz. Sie können dieselbe Codebasis ballistisch gestalten und jeden Monat mehrere hundert Dollar an Infrastruktur- / Hosting-Rechnungen sparen. Wie? Lasst uns anfangen.

Vier Arten von Optimierungen

Meiner Meinung nach kann die Optimierung auf vier verschiedenen Ebenen erfolgen (wenn es um PHP-Anwendungen, das ist):

  • Sprachniveau: Dies bedeutet, dass Sie eine schnellere Version der Sprache verwenden und bestimmte Funktionen / Codierungsstile in der Sprache vermeiden, die Ihren Code verlangsamt.
  • Framework-Ebene: Dies sind die Dinge, die wir in diesem Artikel behandeln werden.
  • Infrastrukturebene: Optimieren Ihres PHP-Prozessmanagers, Webservers, Ihrer Datenbank usw.
  • Hardware-Level: Umstellung auf eine bessere, schnellere und leistungsstärkere Hardware Hostinganbieter.

Alle diese Arten von Optimierungen haben ihren Platz (zum Beispiel PHP-fpm-Optimierung ist ziemlich kritisch und mächtig). Der Schwerpunkt dieses Artikels liegt jedoch auf Optimierungen vom Typ 2: solchen, die sich auf das Framework beziehen.

Übrigens gibt es keine Gründe für die Nummerierung und es ist kein akzeptierter Standard. Ich habe das gerade erfunden. Bitte zitieren Sie mich nie und sagen Sie: "Wir brauchen Typ-3-Optimierung auf unserem Server", sonst wird Ihr Teamleiter Sie töten, mich finden und mich dann auch töten. 😀

Und jetzt kommen wir endlich im gelobten Land an.

Be aware of n+1 database queries

Das n + 1-Abfrageproblem tritt häufig auf, wenn ORMs verwendet werden. Laravel hat sein mächtiges ORM namens Eloquent, das so schön und praktisch ist, dass wir oft vergessen, uns anzusehen, was los ist.

Stellen Sie sich ein sehr häufiges Szenario vor: Anzeigen der Liste aller Bestellungen, die von einer bestimmten Kundenliste aufgegeben wurden. Dies ist in E-Commerce-Systemen und allen Berichtsschnittstellen im Allgemeinen häufig der Fall, in denen alle Entitäten angezeigt werden müssen, die sich auf einige Entitäten beziehen.

In Laravel können wir uns eine Controller-Funktion vorstellen, die diese Aufgabe wie folgt erfüllt:

class OrdersController extends Controller 
{
    // ... 

    public function getAllByCustomers(Request $request, array $ids) {
        $customers = Customer::findMany($ids);        
        $orders = collect(); // new collection
        
        foreach ($customers as $customer) {
            $orders = $orders->merge($customer->orders);
        }
        
        return view('admin.reports.orders', ['orders' => $orders]);
    }
}

Süss! Und was noch wichtiger ist, elegant, schön. 🤩🤩

Leider ist es ein katastrophal Weg, um Code in Laravel zu schreiben.

Hier ist der Grund.

Wenn wir den ORM bitten, nach den angegebenen Kunden zu suchen, wird eine SQL-Abfrage wie diese generiert:

SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);

Welches ist genau wie erwartet. Infolgedessen werden alle zurückgegebenen Zeilen in der Auflistung gespeichert $customers innerhalb der Controller-Funktion.

Jetzt durchlaufen wir jeden Kunden einzeln und erhalten seine Bestellungen. Dies führt die folgende Abfrage aus. . .

SELECT * FROM orders WHERE customer_id = 22;

. . . so oft wie es Kunden gibt.

Mit anderen Worten, wenn wir die Bestelldaten für 1000 Kunden abrufen müssen, beträgt die Gesamtzahl der ausgeführten Datenbankabfragen 1 (zum Abrufen aller Kundendaten) + 1000 (zum Abrufen von Bestelldaten für jeden Kunden) = 1001. Dies Hier kommt der Name n + 1 her.

Können wir es besser machen? Bestimmt! Durch die Verwendung des so genannten eifrigen Ladens können wir den ORM zwingen, einen JOIN durchzuführen und alle erforderlichen Daten in einer einzigen Abfrage zurückzugeben! So was:

$orders = Customer::findMany($ids)->with('orders')->get();

Die resultierende Datenstruktur ist zwar verschachtelt, aber die Auftragsdaten können leicht extrahiert werden. Die resultierende Einzelabfrage sieht in diesem Fall ungefähr so ​​aus:

SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, . . .);

Eine einzelne Abfrage ist natürlich besser als tausend zusätzliche Abfragen. Stellen Sie sich vor, was passieren würde, wenn 10,000 Kunden bearbeitet werden müssten! Oder Gott bewahre, wenn wir auch die in jeder Bestellung enthaltenen Artikel anzeigen wollten! Denken Sie daran, der Name der Technik ist eifrig zu laden, und es ist fast immer eine gute Idee.

Cache the configuration!

Einer der Gründe für die Flexibilität von Laravel sind die unzähligen Konfigurationsdateien, die Teil des Frameworks sind. Möchten Sie ändern, wie / wo die Bilder gespeichert werden?

Nun, ändern Sie einfach die config/filesystems.php Datei (zumindest zum Zeitpunkt des Schreibens). Möchten Sie mit mehreren Warteschlangentreibern arbeiten? Fühlen Sie sich frei, sie in zu beschreiben config/queue.php. Ich habe gerade gezählt und festgestellt, dass es 13 Konfigurationsdateien für verschiedene Aspekte des Frameworks gibt, um sicherzustellen, dass Sie nicht enttäuscht werden, egal was Sie ändern möchten.

Angesichts der Natur von PHP wacht Laravel jedes Mal auf, wenn eine neue Webanforderung eingeht, bootet alles und analysiert Alle dieser Konfigurationsdateien, um herauszufinden, wie Sie diesmal etwas anderes tun können. Nur dass es dumm ist, wenn sich in den letzten Tagen nichts geändert hat! Das Neuerstellen der Konfiguration bei jeder Anforderung ist eine Verschwendung, die vermieden werden kann (tatsächlich muss), und der Ausweg ist ein einfacher Befehl, den Laravel anbietet:

php artisan config:cache

Dadurch werden alle verfügbaren Konfigurationsdateien in einer einzigen zusammengefasst, und der Cache kann irgendwo schnell abgerufen werden. Wenn das nächste Mal eine Webanforderung eingeht, liest Laravel einfach diese einzelne Datei und legt los.

Das heißt, Konfigurations-Caching ist eine äußerst heikle Operation, die Ihnen ins Gesicht sprengen kann. Das größte Problem ist, dass, sobald Sie diesen Befehl erteilt haben, die env() Funktionsaufrufe von überall außer den Konfigurationsdateien werden zurückgegeben null!

Es macht Sinn, wenn Sie darüber nachdenken. Wenn Sie das Konfigurations-Caching verwenden, sagen Sie dem Framework: "Weißt du was? Ich denke, ich habe die Dinge gut eingerichtet und bin zu 100% sicher, dass ich nicht möchte, dass sie sich ändern." Mit anderen Worten, Sie erwarten, dass die Umgebung statisch bleibt .env Dateien sind für.

Nach alledem sind hier einige eiserne, heilige, unzerbrechliche Regeln für das Caching von Konfigurationen:

  1. Tun Sie es nur auf einem Produktionssystem.
  2. Tun Sie dies nur, wenn Sie wirklich, wirklich sicher sind, dass Sie die Konfiguration einfrieren möchten.
  3. Falls etwas schief geht, machen Sie die Einstellung mit rückgängig php artisan cache:clear
  4. Betet, dass der Schaden, der dem Geschäft zugefügt wurde, nicht signifikant war!

Reduce autoloaded services

Um hilfreich zu sein, lädt Laravel beim Aufwachen eine Menge Dienste. Diese sind in der verfügbar config/app.php Datei als Teil der 'providers' Array-Schlüssel. Schauen wir uns an, was ich in meinem Fall habe:

/*
    |--------------------------------------------------------------------------
    | Autoloaded Service Providers
    |--------------------------------------------------------------------------
    |
    | The service providers listed here will be automatically loaded on the
    | request to your application. Feel free to add your own services to
    | this array to grant expanded functionality to your applications.
    |
    */

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        Illuminate\Filesystem\FilesystemServiceProvider::class,
        Illuminate\Foundation\Providers\FoundationServiceProvider::class,
        Illuminate\Hashing\HashServiceProvider::class,
        Illuminate\Mail\MailServiceProvider::class,
        Illuminate\Notifications\NotificationServiceProvider::class,
        Illuminate\Pagination\PaginationServiceProvider::class,
        Illuminate\Pipeline\PipelineServiceProvider::class,
        Illuminate\Queue\QueueServiceProvider::class,
        Illuminate\Redis\RedisServiceProvider::class,
        Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
        Illuminate\Session\SessionServiceProvider::class,
        Illuminate\Translation\TranslationServiceProvider::class,
        Illuminate\Validation\ValidationServiceProvider::class,
        Illuminate\View\ViewServiceProvider::class,

        /*
         * Package Service Providers...
         */

        /*
         * Application Service Providers...
         */
        App\Providers\AppServiceProvider::class,
        App\Providers\AuthServiceProvider::class,
        // App\Providers\BroadcastServiceProvider::class,
        App\Providers\EventServiceProvider::class,
        App\Providers\RouteServiceProvider::class,

    ],

Ich habe noch einmal gezählt und es sind 27 Dienste aufgelistet! Jetzt brauchen Sie vielleicht alle, aber es ist unwahrscheinlich.

Zum Beispiel baue ich gerade eine REST-API auf, was bedeutet, dass ich den Sitzungsdienstanbieter, den Ansichtsdienstanbieter usw. nicht benötige. Und da ich einige Dinge auf meine Weise mache und die Framework-Standardeinstellungen nicht befolge Ich kann auch den Auth-Dienstanbieter, den Paginierungsdienstanbieter, den Übersetzungsdienstanbieter usw. deaktivieren. Insgesamt ist fast die Hälfte davon für meinen Anwendungsfall nicht erforderlich.

Schauen Sie sich Ihre Bewerbung genau an. Benötigt es all diese Dienstleister? Aber um Gottes willen, bitte kommentieren Sie diese Dienstleistungen nicht blind aus und drängen Sie zur Produktion! Führen Sie alle Tests aus, überprüfen Sie die Dinge manuell auf Entwicklungs- und Staging-Maschinen und seien Sie sehr, sehr paranoid, bevor Sie den Abzug betätigen. 🙂

Be wise with middleware stacks

Wenn Sie eine benutzerdefinierte Verarbeitung der eingehenden Webanforderung benötigen, ist das Erstellen einer neuen Middleware die Antwort. Jetzt ist es verlockend zu öffnen app/Http/Kernel.php und stecken Sie die Middleware in die web or api Stapel; Auf diese Weise wird es in der gesamten App verfügbar und wenn es nicht aufdringlich ist (z. B. Protokollierung oder Benachrichtigung).

Wenn die App wächst, kann diese Sammlung globaler Middleware jedoch zu einer stillen Belastung für die App werden, wenn alle (oder die Mehrheit) davon in jeder Anfrage vorhanden sind, auch wenn es keinen geschäftlichen Grund dafür gibt.

Mit anderen Worten, achten Sie darauf, wo Sie eine neue Middleware hinzufügen / anwenden. Es kann bequemer sein, etwas global hinzuzufügen, aber der Leistungsverlust ist auf lange Sicht sehr hoch. Ich kenne den Schmerz, den Sie erleiden müssten, wenn Sie jedes Mal, wenn es eine neue Änderung gibt, selektiv Middleware anwenden würden, aber es ist ein Schmerz, den ich gerne nehmen und empfehlen würde!

Avoid the ORM (at times)

Während Eloquent viele Aspekte der DB-Interaktion angenehm macht, geht dies zu Lasten der Geschwindigkeit. Als Mapper muss der ORM nicht nur Datensätze aus der Datenbank abrufen, sondern auch die Modellobjekte instanziieren und sie mit Spaltendaten hydratisieren (ausfüllen).

Also, wenn Sie eine einfache machen $users = User::all() Wenn beispielsweise 10,000 Benutzer vorhanden sind, ruft das Framework 10,000 Zeilen aus der Datenbank ab und führt intern 10,000 aus new User() und füllen Sie ihre Eigenschaften mit den relevanten Daten. Dies ist eine enorme Menge an Arbeit, die hinter den Kulissen geleistet wird. Wenn in der Datenbank Ihre Anwendung zu einem Engpass wird, ist es manchmal eine gute Idee, das ORM zu umgehen.

Dies gilt insbesondere für komplexe SQL-Abfragen, bei denen Sie viele Rahmen überspringen und Abschlüsse nach Abschlüssen schreiben müssen, um dennoch eine effiziente Abfrage zu erhalten. In solchen Fällen wird a DB::raw() und das Schreiben der Abfrage von Hand wird bevorzugt.

Geht vorbei fehlen uns die Worte. Leistungsstudie, auch für einfache Beilagen Eloquent ist mit steigender Anzahl von Datensätzen viel langsamer:

Use caching as much as possible

Eines der bestgehüteten Geheimnisse der Webanwendungsoptimierung ist das Caching.

Für Uneingeweihte bedeutet Caching, teure Ergebnisse (teuer in Bezug auf CPU- und Speicherauslastung) vorab zu berechnen und zu speichern und sie einfach zurückzugeben, wenn dieselbe Abfrage wiederholt wird.

In einem E-Commerce-Geschäft kann es beispielsweise vorkommen, dass es sich um 2 Millionen Produkte handelt. Die meisten Menschen interessieren sich für Produkte, die innerhalb einer bestimmten Preisspanne und für eine bestimmte Altersgruppe frisch gelagert sind. Das Abfragen der Datenbank nach diesen Informationen ist verschwenderisch. Da sich die Abfrage nicht häufig ändert, ist es besser, diese Ergebnisse an einem Ort zu speichern, auf den wir schnell zugreifen können.

Laravel verfügt über eine integrierte Unterstützung für verschiedene Arten von Caching. Zusätzlich zur Verwendung eines Caching-Treibers und zum Aufbau des Caching-Systems von Grund auf möchten Sie möglicherweise einige Laravel-Pakete verwenden, die dies erleichtern Modell-Caching, Abfrage-Caching, usw.

Beachten Sie jedoch, dass vorgefertigte Caching-Pakete über einen bestimmten vereinfachten Anwendungsfall hinaus mehr Probleme verursachen als lösen können.

Prefer in-memory caching

Wenn Sie etwas in Laravel zwischenspeichern, haben Sie mehrere Möglichkeiten, die resultierende Berechnung zu speichern, die zwischengespeichert werden muss. Diese Optionen werden auch als bezeichnet Cache-Treiber. Obwohl es möglich und durchaus sinnvoll ist, das Dateisystem zum Speichern von Cache-Ergebnissen zu verwenden, ist es nicht wirklich das, was Caching sein soll.

Idealerweise möchten Sie einen In-Memory-Cache (der vollständig im RAM lebt) wie Redis, Memcached, MongoDB usw. verwenden, damit das Caching bei höheren Lasten eine wichtige Verwendung darstellt, anstatt selbst zum Engpass zu werden.

Nun könnte man denken, dass eine SSD-Festplatte fast die gleiche ist wie die Verwendung eines RAM-Sticks, aber nicht einmal in der Nähe. Auch informell Benchmarks zeigen, dass RAM die SSD in Bezug auf die Geschwindigkeit um das 10 bis 20-fache übertrifft.

Mein Lieblingssystem beim Caching ist Redis. Es ist lächerlich schnell (100,000 Lesevorgänge pro Sekunde sind üblich) und kann für sehr große Cache-Systeme zu einem entwickelt werden Gruppe einfach.

Cache the routes

Genau wie bei der Anwendungskonfiguration ändern sich die Routen im Laufe der Zeit nicht wesentlich und sind ein idealer Kandidat für das Caching. Dies gilt insbesondere dann, wenn Sie große Dateien wie mich nicht ausstehen und Ihre Dateien am Ende aufteilen können web.php und api.php über mehrere Dateien. Ein einziger Laravel-Befehl packt alle verfügbaren Routen zusammen und hält sie für den zukünftigen Zugriff bereit:

php artisan route:cache

Und wenn Sie am Ende Routen hinzufügen oder ändern, tun Sie einfach Folgendes:

php artisan route:clear

Image optimization and CDN

Bilder sind das Herz und die Seele der meisten Webanwendungen. Zufälligerweise sind sie auch die größten Konsumenten von Bandbreite und einer der Hauptgründe für langsame Apps / Websites. Wenn Sie die hochgeladenen Bilder einfach naiv auf dem Server speichern und in HTTP-Antworten zurücksenden, entgeht Ihnen eine massive Optimierungsmöglichkeit.

Meine erste Empfehlung ist, Bilder nicht lokal zu speichern. Es besteht das Problem des Datenverlusts. Je nachdem, in welcher geografischen Region sich Ihr Kunde befindet, kann die Datenübertragung schmerzhaft langsam sein.

Entscheiden Sie sich stattdessen für eine Lösung wie Cloudinary Dadurch werden Bilder automatisch geändert und optimiert.

Wenn dies nicht möglich ist, verwenden Sie Cloudflare, um Bilder zwischenzuspeichern und bereitzustellen, während sie auf Ihrem Server gespeichert sind.

Und wenn selbst dies nicht möglich ist, macht es einen großen Unterschied, Ihre Webserver-Software ein wenig zu optimieren, um Assets zu komprimieren und den Browser des Besuchers zum Zwischenspeichern zu veranlassen. So würde ein Ausschnitt aus der Nginx-Konfiguration aussehen:

server {

   # file truncated
    
    # gzip compression settings
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_vary on;

   # browser cache control
   location ~* \.(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
         expires 1d;
         access_log off;
         add_header Pragma public;
         add_header Cache-Control "public, max-age=86400";
    }
}

Ich bin mir bewusst, dass die Bildoptimierung nichts mit Laravel zu tun hat, aber es ist ein so einfacher und mächtiger Trick (und wird so oft vernachlässigt), der mir nicht helfen konnte.

Autoloader optimization

Autoloading ist eine nette, nicht so alte Funktion in PHP, die die Sprache wohl vor dem Untergang bewahrt hat. Das Finden und Laden der relevanten Klasse durch Entschlüsseln einer bestimmten Namespace-Zeichenfolge nimmt jedoch Zeit in Anspruch und kann in Produktionsbereitstellungen vermieden werden, in denen eine hohe Leistung wünschenswert ist. Wieder einmal hat Laravel eine Lösung mit einem einzigen Befehl:

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

Make friends with queues

Queues So verarbeiten Sie Dinge, wenn es viele davon gibt, und jeder von ihnen benötigt einige Millisekunden, um fertig zu werden. Ein gutes Beispiel ist das Senden von E-Mails. Ein weit verbreiteter Anwendungsfall in Web-Apps besteht darin, einige Benachrichtigungs-E-Mails abzuschießen, wenn ein Benutzer bestimmte Aktionen ausführt.

Bei einem neu eingeführten Produkt möchten Sie beispielsweise möglicherweise, dass die Unternehmensleitung (etwa 6-7 E-Mail-Adressen) benachrichtigt wird, wenn jemand eine Bestellung über einem bestimmten Wert aufgibt. Vorausgesetzt, Ihr E-Mail-Gateway kann auf Ihre SMTP Anfrage in 500ms, wir sprechen von einer guten 3-4-Sekunden-Wartezeit für den Benutzer, bevor die Bestellbestätigung einsetzt. Ein wirklich schlechtes Stück UX, da werden Sie mir sicher zustimmen.

Die Abhilfe besteht darin, Aufträge beim Eingang zu speichern, dem Benutzer mitzuteilen, dass alles gut gelaufen ist, und sie (einige Sekunden) später zu verarbeiten. Wenn ein Fehler auftritt, können die Jobs in der Warteschlange einige Male wiederholt werden, bevor sie als fehlgeschlagen deklariert werden.

Quellennachweis: Microsoft.com

Während ein Warteschlangensystem die Einrichtung ein wenig kompliziert (und einen gewissen Überwachungsaufwand verursacht), ist es in einer modernen Webanwendung unverzichtbar.

Asset optimization (Laravel Mix)

Stellen Sie für alle Front-End-Assets in Ihrer Laravel-Anwendung sicher, dass eine Pipeline vorhanden ist, die alle Asset-Dateien kompiliert und minimiert. Diejenigen, die mit einem Bündlersystem wie Webpack, Gulp, Parcel usw. vertraut sind, müssen sich nicht darum kümmern, aber wenn Sie dies nicht bereits tun, Laravel-Mix ist eine solide Empfehlung.

Mix ist ein leichter (und ehrlich gesagt entzückender!) Wrapper um Webpack, der alle Ihre CSS-, SASS-, JS- usw. Dateien für die Produktion verwaltet. Ein typischer .mix.js Datei kann so klein sein und dennoch Wunder wirken:

const mix = require('laravel-mix');

mix.js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css');

Dies kümmert sich automatisch um Importe, Minimierung, Optimierung und den gesamten Shebang, wenn Sie für die Produktion und den Betrieb bereit sind npm run production. Mix kümmert sich nicht nur um herkömmliche JS- und CSS-Dateien, sondern auch um Vue- und React-Komponenten, die möglicherweise in Ihrem Anwendungsworkflow enthalten sind.

Info hier !

Conclusion

Leistungsoptimierung ist mehr Kunst als Wissenschaft - zu wissen, wie und wie viel zu tun ist, ist wichtig als zu tun. Das heißt, es gibt kein Ende, wie viel und was Sie alles in einer Laravel-Anwendung optimieren können.

Aber was auch immer Sie tun, ich möchte Ihnen einige Ratschläge zum Abschied geben - die Optimierung sollte durchgeführt werden, wenn es einen soliden Grund gibt, und nicht, weil es sich gut anhört oder weil Sie in der Realität paranoid in Bezug auf die App-Leistung für mehr als 100,000 Benutzer sind es gibt nur 10.

Wenn Sie nicht sicher sind, ob Sie Ihre App optimieren müssen oder nicht, müssen Sie nicht in das sprichwörtliche Hornissennest treten. Eine funktionierende App, die sich langweilig anfühlt, aber genau das tut, was sie muss, ist zehnmal wünschenswerter als eine App, die für eine mutierte Hybrid-Supermaschine optimiert wurde, aber ab und zu flach fällt.

Und damit Newbiew ein Laravel-Meister wird, lesen Sie dies Online Kurs.

Mögen Ihre Apps viel, viel schneller laufen! 🙂

Danke an unsere Sponsoren
Weitere großartige Lektüre zum Thema Entwicklung
Treiben Sie Ihr Geschäft an
Einige der Tools und Dienste, die Ihr Unternehmen beim Wachstum unterstützen.
  • Invicti verwendet das Proof-Based Scanning™, um die identifizierten Schwachstellen automatisch zu verifizieren und innerhalb weniger Stunden umsetzbare Ergebnisse zu generieren.
    Versuchen Sie es mit Invicti
  • Web-Scraping, Wohn-Proxy, Proxy-Manager, Web-Unlocker, Suchmaschinen-Crawler und alles, was Sie zum Sammeln von Webdaten benötigen.
    Versuchen Sie es mit Brightdata
  • Semrush ist eine All-in-One-Lösung für digitales Marketing mit mehr als 50 Tools in den Bereichen SEO, Social Media und Content-Marketing.
    Versuchen Sie es mit Semrush
  • Intruder ist ein Online-Schwachstellenscanner, der Cyber-Sicherheitslücken in Ihrer Infrastruktur findet, um kostspielige Datenschutzverletzungen zu vermeiden.
    MIT DER INTELLIGENTEN SCHADENKALKULATION VON Intruder