Kā optimizēt PHP Laravel tīmekļa lietojumprogrammu augstas veiktspējas nodrošināšanai?

Laravel ir daudzas lietas. Bet ātrs nav viens no tiem. Apgūsim dažus amata trikus, lai tas noritētu ātrāk!

Neviens PHP izstrādātājs nav neskarts Laravels šajās dienās. Viņi ir vai nu jaunākā vai vidējā līmeņa izstrādātāji, kuriem patīk Laravel piedāvātā straujā attīstība, vai arī viņi ir vecākie izstrādātāji, kuri ir spiesti apgūt Laravel tirgus spiediena dēļ.

Jebkurā gadījumā nevar noliegt, ka Laravel ir atdzīvinājis PHP ekosistēmu (es, protams, jau sen būtu pametis PHP pasauli, ja Laravela nebūtu).

Laravela (nedaudz pamatota) pašslavinājuma fragments

Tomēr, tā kā Laravel noliecas atpakaļ, lai jums atvieglotu darbu, tas nozīmē, ka zem tā tiek strādāts daudz un tonnu darbu, lai nodrošinātu jums ērtu izstrādātāja dzīvi. Visām Laravel “maģiskajām” funkcijām, kas, šķiet, darbojas, ir koda slāņi, kas ir jāpaplašina katru reizi, kad funkcija tiek palaista. Pat vienkāršs izņēmums izseko truša bedres dziļumam (ievērojiet, kur sākas kļūda, līdz pat galvenajam kodolam):

Šķiet, ka vienā no skatiem ir kompilācijas kļūda, ir 18 funkciju izsaukumi, lai izsekotu. Es personīgi esmu saskāries ar 40, un to varētu būt vairāk, ja izmantojat citas bibliotēkas un spraudņus.

Fakts ir tāds, ka pēc noklusējuma šis slāņi pēc koda slāņiem padara Laravel lēnu.

Cik lēns ir Laravels?

Godīgi sakot, uz šo jautājumu nav iespējams atbildēt vairāku iemeslu dēļ.

Pirmkārt, nav pieņemta, objektīva un saprātīga standarta tīmekļa lietotņu ātruma mērīšanai. Ātrāk vai lēnāk, salīdzinot ar ko? Kādos apstākļos?

Otrkārt, tīmekļa lietotne ir atkarīga no tik daudzām lietām (datu bāzes, failu sistēmas, tīkla, kešatmiņas utt.), ka ir vienkārši muļķīgi runāt par ātrumu. Ļoti ātra tīmekļa lietotne ar ļoti lēnu datu bāzi ir ļoti lēna tīmekļa lietotne. 🙂

Bet tieši šī nenoteiktība ir iemesls, kāpēc etaloni ir populāri. Pat ja tie neko nenozīmē (sk šis un šis), tie sniedz zināmu atskaites sistēmu un palīdz mums nesajukt prātā. Tāpēc, kad ir gatavas vairākas sāls šķipsnas, gūsim nepareizu, aptuvenu priekšstatu par ātrumu starp PHP ietvariem.

Izmantojot šo diezgan cienījamo GitHub avotsPHP ietvarus salīdzina šādi:

Jūs, iespējams, šeit pat nepamanīsit Laravelu (pat tad, ja ļoti smagi šķielējat), ja vien nenometīsiet savu lietu līdz pat astes galam. Jā, dārgie draugi, Laravels ir pēdējais! Tagad, protams, lielākā daļa no šiem “ietvariem” nav īpaši praktiski vai pat noderīgi, taču tie mums parāda, cik gausa ir Laravel, salīdzinot ar citiem populārākajiem.

Parasti šis “lēnums” lietojumprogrammās nav redzams, jo mūsu ikdienas tīmekļa lietotnēs reti tiek sasniegts liels skaits. Bet, tiklīdz tas notiek (teiksim, vairāk nekā 200–500 vienlaicīguma), serveri sāk aizrīties un nomirst. Tas ir laiks, kad pat lielāka aparatūras izmantošana problēmas risināšanai to nesamazina, un infrastruktūras rēķini pieaug tik strauji, ka jūsu augstie mākoņdatošanas ideāli sabrūk.

Bet nu, uzmundrināt! Šis raksts nav par to, ko nevar izdarīt, bet gan par to, ko var izdarīt. 🙂

Labās ziņas ir tādas, ka jūs varat darīt daudz, lai jūsu Laravel lietotne darbotos ātrāk. Vairākas reizes ātri. Jā, nejoko. Varat padarīt to pašu kodu bāzi ballistisko un katru mēnesi ietaupīt vairākus simtus dolāru infrastruktūras/hostinga rēķinos. Kā? Ķersimies pie tā.

Četri optimizācijas veidi

Manuprāt, optimizāciju var veikt četros dažādos līmeņos (ja runa ir par PHP lietojumprogrammām, tas ir):

  • Valodas līmenis: tas nozīmē, ka izmantojat ātrāku valodas versiju un izvairāties no konkrētām valodas kodēšanas funkcijām/stiliem, kas padara kodu lēnu.
  • Ietvara līmenis: šīs ir lietas, ko mēs apskatīsim šajā rakstā.
  • Infrastruktūras līmenis: PHP procesa pārvaldnieka, tīmekļa servera, datu bāzes utt.
  • Aparatūras līmenis: pāreja uz labāku, ātrāku un jaudīgāku aparatūras mitināšanas pakalpojumu sniedzēju.

Visiem šiem optimizācijas veidiem ir sava vieta (piemēram, PHP-fpm optimizācija ir diezgan kritiska un spēcīga). Taču šajā rakstā galvenā uzmanība tiks pievērsta tikai 2. tipa optimizācijām: tām, kas saistītas ar ietvaru.

Starp citu, numerācijai nav loģikas, un tas nav pieņemts standarts. Es tikko šos izdomāju. Lūdzu, nekad necitējiet mani un nesakiet: “Mūsu serverī ir nepieciešama 3. tipa optimizācija”, pretējā gadījumā jūsu komandas vadītājs jūs nogalinās, atrod mani un pēc tam arī mani. 😀

Un tagad beidzot mēs nonākam apsolītajā zemē.

Esiet informēts par n+1 datu bāzes vaicājumiem

N+1 vaicājuma problēma ir izplatīta problēma, kad tiek izmantoti ORM. Laravel ir tā jaudīgā ORM ar nosaukumu Eloquent, kas ir tik skaista, tik ērta, ka mēs bieži aizmirstam paskatīties uz notiekošo.

  Kāpēc jums vajadzētu mācīties ReactJS un 12 labākie resursi, no kuriem to mācīties

Apsveriet ļoti izplatītu scenāriju: tiek parādīts visu pasūtījumu saraksts, ko veicis noteikts klientu saraksts. Tas ir diezgan izplatīts e-komercijas sistēmās un visās pārskatu saskarnēs kopumā, kur mums ir jāparāda visas entītijas, kas saistītas ar dažām entītijām.

Programmā Laravel mēs varētu iedomāties kontroliera funkciju, kas veic šādu darbu:

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]);
    }
}

Mīļi! Un vēl svarīgāk, elegants, skaists. 🤩🤩

Diemžēl tas ir postošs veids, kā rakstīt kodu Laravel.

Lūk, kāpēc.

Kad mēs lūdzam ORM meklēt norādītos klientus, tiek ģenerēts šāds SQL vaicājums:

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

Kas ir tieši tā, kā gaidīts. Rezultātā visas atgrieztās rindas tiek saglabātas kolekcijā $customers kontrollera funkcijas ietvaros.

Tagad mēs apstrādājam katru klientu pa vienam un saņemam viņu pasūtījumus. Tas izpilda šādu vaicājumu. . .

SELECT * FROM orders WHERE customer_id = 22;

. . . tik reižu, cik ir klientu.

Citiem vārdiem sakot, ja mums ir jāiegūst pasūtījuma dati par 1000 klientiem, kopējais izpildīto datu bāzes vaicājumu skaits būs 1 (lai iegūtu visus klientu datus) + 1000 (lai iegūtu pasūtījuma datus katram klientam) = 1001. no kurienes cēlies nosaukums n+1.

Vai mēs varam labāk? Noteikti! Izmantojot to, ko sauc par nepacietīgu ielādi, mēs varam piespiest ORM veikt JOIN un atgriezt visus nepieciešamos datus vienā vaicājumā! Kā šis:

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

Rezultātā iegūtā datu struktūra, protams, ir ligzdota, taču pasūtījuma datus var viegli iegūt. Rezultātā iegūtais viens vaicājums šajā gadījumā ir aptuveni šāds:

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

Viens vaicājums, protams, ir labāks par tūkstoš papildu vaicājumiem. Iedomājieties, kas notiktu, ja būtu jāapstrādā 10 000 klientu! Vai nedod Dievs, ja mēs arī vēlējāmies izlikt katrā pasūtījumā esošās preces! Atcerieties, ka tehnikas nosaukums ir dedzīga iekraušana, un tā gandrīz vienmēr ir laba ideja.

Saglabājiet konfigurāciju kešatmiņā!

Viens no Laravel elastības iemesliem ir daudz konfigurācijas failu, kas ir daļa no sistēmas. Vai vēlaties mainīt to, kā/kur attēli tiek glabāti?

Vienkārši mainiet failu config/filesystems.php (vismaz rakstīšanas brīdī). Vai vēlaties strādāt ar vairākiem rindas draiveriem? Jūtieties brīvi aprakstiet tos config/queue.php. Es tikko saskaitīju un atklāju, ka dažādiem ietvara aspektiem ir 13 konfigurācijas faili, kas nodrošina, ka nebūsiet vīlušies neatkarīgi no tā, ko vēlaties mainīt.

Ņemot vērā PHP būtību, katru reizi, kad tiek saņemts jauns tīmekļa pieprasījums, Laravel pamostas, sāk visu un parsē visus šos konfigurācijas failus, lai noskaidrotu, kā šoreiz rīkoties citādi. Izņemot to, ka tas ir stulbi, ja pēdējās dienās nekas nav mainījies! Konfigurācijas pārbūve pēc katra pieprasījuma ir izšķērdība, no kuras var (patiesībā no tā ir) izvairīties, un izeja ir vienkārša komanda, ko piedāvā Laravel:

php artisan config:cache

Tas apvieno visus pieejamos konfigurācijas failus vienā, un kešatmiņa ir kaut kur ātrai izguvei. Nākamajā reizē, kad būs Web pieprasījums, Laravel vienkārši izlasīs šo vienu failu un sāks darbu.

Tomēr konfigurācijas kešatmiņa ir ārkārtīgi delikāta darbība, kas var uzspridzināt jūsu seju. Vislielākā problēma ir tāda, ka pēc šīs komandas izdošanas env() funkcija izsauc no jebkuras vietas, izņemot konfigurācijas failus, atgriezīs nulli!

Tam ir jēga, kad par to domā. Ja izmantojat konfigurācijas kešatmiņu, jūs sakāt ietvaram: „Es domāju, ka esmu labi iestatījis lietas, un esmu 100% pārliecināts, ka nevēlos, lai tās mainītos.” Citiem vārdiem sakot, jūs sagaidāt, ka vide paliks statiska, un tam ir paredzēti .env faili.

To sakot, šeit ir daži dzelžaini, svēti, nepārkāpjami konfigurācijas kešatmiņas noteikumi:

  • Dariet to tikai ražošanas sistēmā.
  • Dariet to tikai tad, ja esat patiešām pārliecināts, ka vēlaties iesaldēt konfigurāciju.
  • Ja kaut kas noiet greizi, atsauciet iestatījumu ar php artisan cache:clear
  • Lūdziet, lai uzņēmumam nodarītais kaitējums nebūtu būtisks!
  • Samaziniet automātiski ielādētos pakalpojumus

    Lai būtu noderīgs, Laravels ielādē ļoti daudz pakalpojumu, kad tas pamostas. Tie ir pieejami failā config/app.php kā daļa no masīva atslēgas “providers”. Apskatīsim, kas man ir manā gadījumā:

    /*
        |--------------------------------------------------------------------------
        | 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...
             */
            IlluminateAuthAuthServiceProvider::class,
            IlluminateBroadcastingBroadcastServiceProvider::class,
            IlluminateBusBusServiceProvider::class,
            IlluminateCacheCacheServiceProvider::class,
            IlluminateFoundationProvidersConsoleSupportServiceProvider::class,
            IlluminateCookieCookieServiceProvider::class,
            IlluminateDatabaseDatabaseServiceProvider::class,
            IlluminateEncryptionEncryptionServiceProvider::class,
            IlluminateFilesystemFilesystemServiceProvider::class,
            IlluminateFoundationProvidersFoundationServiceProvider::class,
            IlluminateHashingHashServiceProvider::class,
            IlluminateMailMailServiceProvider::class,
            IlluminateNotificationsNotificationServiceProvider::class,
            IlluminatePaginationPaginationServiceProvider::class,
            IlluminatePipelinePipelineServiceProvider::class,
            IlluminateQueueQueueServiceProvider::class,
            IlluminateRedisRedisServiceProvider::class,
            IlluminateAuthPasswordsPasswordResetServiceProvider::class,
            IlluminateSessionSessionServiceProvider::class,
            IlluminateTranslationTranslationServiceProvider::class,
            IlluminateValidationValidationServiceProvider::class,
            IlluminateViewViewServiceProvider::class,
    
            /*
             * Package Service Providers...
             */
    
            /*
             * Application Service Providers...
             */
            AppProvidersAppServiceProvider::class,
            AppProvidersAuthServiceProvider::class,
            // AppProvidersBroadcastServiceProvider::class,
            AppProvidersEventServiceProvider::class,
            AppProvidersRouteServiceProvider::class,
    
        ],

    Es vēlreiz saskaitīju, un tur ir 27 pakalpojumi! Tagad jums var būt nepieciešami tie visi, taču tas ir maz ticams.

      Automatizējiet HR uzdevumus ar Freshteam un uzlabojiet efektivitāti

    Piemēram, es pašlaik veidoju REST API, kas nozīmē, ka man nav vajadzīgs sesijas pakalpojumu sniedzējs, skatīšanas pakalpojumu sniedzējs utt. Un tā kā es daru dažas lietas savā veidā un neievēroju ietvara noklusējuma iestatījumus. , varu arī atspējot autentifikācijas pakalpojumu sniedzēju, lappušu veidošanas pakalpojumu sniedzēju, tulkošanas pakalpojumu sniedzēju utt. Kopumā gandrīz puse no tiem manam lietošanas gadījumam nav vajadzīgi.

    Ilgi un rūpīgi izskatiet savu pieteikumu. Vai tai ir vajadzīgi visi šie pakalpojumu sniedzēji? Bet dieva dēļ, lūdzu, akli nekomentējiet šos pakalpojumus un spiediet uz ražošanu! Izpildiet visus testus, manuāli pārbaudiet lietas izstrādātāju un inscenēšanas iekārtās un esiet ļoti paranoisks, pirms nospiežat mēlīti. 🙂

    Esiet gudrs ar starpprogrammatūras skursteņiem

    Ja jums ir nepieciešama ienākošā tīmekļa pieprasījuma pielāgota apstrāde, risinājums ir jaunas starpprogrammatūras izveide. Tagad ir vilinoši atvērt app/Http/Kernel.php un ievietot starpprogrammatūru tīmeklī vai api kaudzē; Tādā veidā tā kļūst pieejama visā lietotnē un, ja tā neveic kaut ko traucējošu (piemēram, nereģistrē vai neziņo).

    Tomēr, lietotnei augot, šī globālās starpprogrammatūras kolekcija var kļūt par klusu slogu lietotnei, ja visi (vai lielākā daļa) no tiem ir iekļauti katrā pieprasījumā, pat ja tam nav biznesa iemesla.

    Citiem vārdiem sakot, uzmanieties, kur pievienojat/lietojat jaunu starpprogrammatūru. Var būt ērtāk kaut ko pievienot globāli, taču veiktspējas sods ilgtermiņā ir ļoti liels. Es zinu, kādas sāpes jums nāktos piedzīvot, ja selektīvi lietotu starpprogrammatūru katru reizi, kad notiek jaunas izmaiņas, taču es labprāt pieņemtu un ieteiktu!

    Izvairieties no ORM (reizēm)

    Lai gan Eloquent padara daudzus DB mijiedarbības aspektus patīkamus, tas notiek uz ātruma rēķina. Tā kā ORM ir kartētājs, tam ir ne tikai jāiegūst ieraksti no datu bāzes, bet arī jāizveido modeļa objekti un jāhidratē (aizpilda tos) ar kolonnu datiem.

    Tātad, ja veicat vienkāršu $users = User::all() un ir, teiksim, 10 000 lietotāju, ietvars ienesīs 10 000 rindu no datu bāzes un iekšēji veiks 10 000 jaunu User() un aizpildīs to rekvizītus ar attiecīgajiem datiem. . Tas ir milzīgs darba apjoms, kas tiek veikts aizkulisēs, un, ja datubāze ir vieta, kur izmantojat lietojumprogrammu, kļūst par sašaurinājumu, dažkārt ir ieteicams apiet ORM.

    Tas jo īpaši attiecas uz sarežģītiem SQL vaicājumiem, kur jums ir jālēkā daudz stīpu un jāraksta aizvērumi, kad aizverat, un joprojām tiek iegūts efektīvs vaicājums. Šādos gadījumos priekšroka dodama DB::raw() un vaicājuma rakstīšanai ar roku.

    Ejot garām šis veiktspējas pētījums, pat vienkāršiem ieliktņiem Daiļrunīgs ir daudz lēnāks, jo palielinās ierakstu skaits:

    Cik vien iespējams, izmantojiet kešatmiņu

    Viens no vislabāk glabātajiem tīmekļa lietojumprogrammu optimizācijas noslēpumiem ir kešatmiņa.

    Nezinātājiem kešatmiņa nozīmē dārgu rezultātu iepriekšēju aprēķinu un glabāšanu (dārgi CPU un atmiņas lietojuma ziņā) un vienkārši to atgriešanu, kad tiek atkārtots viens un tas pats vaicājums.

    Piemēram, e-komercijas veikalā var saskarties ar to, ka no 2 miljoniem produktu cilvēkus lielākoties interesē tie, kas ir tikko noliktavā, noteiktā cenu diapazonā un paredzēti noteiktai vecuma grupai. Šīs informācijas vaicāšana datu bāzē ir izšķērdīga — tā kā vaicājums nemainās bieži, labāk ir glabāt šos rezultātus kaut kur, kur mēs varam ātri piekļūt.

    Laravel ir iebūvēts atbalsts vairākiem veidiem kešatmiņa. Papildus kešatmiņas draivera izmantošanai un kešatmiņas sistēmas izveidei no sākuma, iespējams, vēlēsities izmantot dažas Laravel pakotnes, kas atvieglo modeļa kešatmiņa, vaicājumu kešatmiņautt.

    Taču ņemiet vērā, ka ārpus noteiktas vienkāršotas lietošanas gadījuma iepriekš izveidotās kešatmiņas pakotnes var radīt vairāk problēmu, nekā atrisināt.

    Dodiet priekšroku kešatmiņai atmiņā

    Kad Laravel kaut ko saglabājat kešatmiņā, jums ir vairākas iespējas, kur saglabāt iegūto aprēķinu, kas jāglabā kešatmiņā. Šīs opcijas ir pazīstamas arī kā kešatmiņas draiveri. Tātad, lai gan ir iespējams un pilnīgi saprātīgi izmantot failu sistēmu kešatmiņas rezultātu glabāšanai, kešatmiņa nav īsti tā, kas ir domāta.

    Ideālā gadījumā vēlaties izmantot atmiņā esošo (pilnībā atrodas RAM) kešatmiņu, piemēram, Redis, Memcached, MongoDB utt., lai lielākās slodzēs kešatmiņa kalpotu vitāli svarīgai lietošanai, nevis kļūtu par sašaurinājumu.

    Tagad jūs varētu domāt, ka SSD disks ir gandrīz tas pats, kas RAM zibatmiņas izmantošana, taču tas nav pat tuvu. Pat neformāli etaloniem parāda, ka RAM pārspēj SSD 10-20 reizes ātruma ziņā.

    Mana iecienītākā sistēma, kad runa ir par kešatmiņu, ir Redis. Tas ir smieklīgi ātri (parastas ir 100 000 lasīšanas operācijas sekundē), un ļoti lielām kešatmiņas sistēmām to var pārveidot par klasteris viegli.

    Saglabājiet maršrutus kešatmiņā

    Tāpat kā lietojumprogrammas konfigurācija, maršruti laika gaitā īpaši nemainās un ir ideāli piemēroti kešatmiņas saglabāšanai. Tas jo īpaši attiecas uz gadījumiem, kad nevarat izturēt tādus lielus failus kā es un galu galā sadalāt savu web.php un api.php vairākos failos. Viena Laravel komanda apkopo visus pieejamos maršrutus un saglabā tos parocīgu turpmākai piekļuvei:

    php artisan route:cache

    Un, kad galu galā pievienojat vai maināt maršrutus, vienkārši rīkojieties šādi:

    php artisan route:clear

    Attēlu optimizācija un CDN

    Attēli ir lielākās daļas tīmekļa lietojumprogrammu sirds un dvēsele. Nejauši viņi ir arī lielākie joslas platuma patērētāji un viens no lielākajiem iemesliem, kāpēc lietotnes/vietnes ir lēnas. Ja jūs vienkārši naivi glabājat augšupielādētos attēlus serverī un nosūtāt tos atpakaļ HTTP atbildēs, jūs palaižat garām milzīgu optimizācijas iespēju.

      3 dažādi viltotu lietotņu veidi Google Play veikalā

    Mans pirmais ieteikums ir neglabāt attēlus lokāli — pastāv datu zuduma problēma, kas jārisina, un atkarībā no tā, kurā ģeogrāfiskajā reģionā atrodas jūsu klients, datu pārsūtīšana var būt sāpīgi lēna.

    Tā vietā meklējiet tādu risinājumu kā Mākoņains kas automātiski maina un optimizē attēlu izmērus.

    Ja tas nav iespējams, izmantojiet kaut ko līdzīgu Cloudflare, lai saglabātu kešatmiņu un apkalpotu attēlus, kamēr tie tiek glabāti jūsu serverī.

    Un, ja pat tas nav iespējams, nedaudz mainot tīmekļa servera programmatūru, lai saspiestu līdzekļus un novirzītu apmeklētāja pārlūkprogrammu, lai saglabātu lietas kešatmiņā, ir liela nozīme. Lūk, kā izskatītos Nginx konfigurācijas fragments:

    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";
        }
    }

    Es apzinos, ka attēla optimizācijai nav nekāda sakara ar Laravel, taču tas ir tik vienkāršs un spēcīgs triks (un tik bieži tiek atstāts novārtā), ka pats nevarēju palīdzēt.

    Autoloader optimizācija

    Automātiskā ielāde ir glīta, ne tik veca PHP funkcija, kas, iespējams, pasargāja valodu no posta. Tomēr attiecīgās klases atrašanas un ielādes process, atšifrējot doto nosaukumvietas virkni, prasa laiku, un no tā var izvairīties ražošanas izvietojumos, kur ir vēlama augsta veiktspēja. Vēlreiz Laravel tam ir vienas komandas risinājums:

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

    Sadraudzējies ar rindām

    Rindas ir tas, kā jūs apstrādājat lietas, ja to ir daudz, un katrai no tām ir nepieciešamas dažas milisekundes, lai pabeigtu. Labs piemērs ir e-pasta sūtīšana — plaši izplatīts tīmekļa lietotņu pielietojuma gadījums ir dažu paziņojumu e-pasta ziņojumu izsūtīšana, kad lietotājs veic noteiktas darbības.

    Piemēram, jaunizveidotā produktā jūs varētu vēlēties, lai uzņēmuma vadība (apmēram 6–7 e-pasta adreses) saņemtu paziņojumu ikreiz, kad kāds veic pasūtījumu, kas pārsniedz noteiktu vērtību. Pieņemot, ka jūsu e-pasta vārteja var atbildēt uz jūsu SMTP pieprasījumu 500 ms laikā, mēs runājam par labu 3–4 sekunžu nogaidīšanu, ko lietotājs gaida, pirms tiek sākts pasūtījuma apstiprinājums. Es esmu pārliecināts, ka tas ir ļoti slikts UX gabals. piekrītu.

    Risinājums ir saglabāt darbus, kad tie tiek saņemti, pastāstīt lietotājam, ka viss noritēja labi, un apstrādāt tos (dažas sekundes) vēlāk. Ja rodas kļūda, rindā esošos darbus var mēģināt atkārtoti dažas reizes, pirms tiek paziņots, ka tie ir neizdevušies.

    Autori: Microsoft.com

    Lai gan rindas sistēma nedaudz sarežģī iestatīšanu (un rada papildu pārraudzības izmaksas), tā ir neaizstājama modernā tīmekļa lietojumprogrammā.

    Līdzekļu optimizācija (Laravel Mix)

    Attiecībā uz visiem priekšgala līdzekļiem jūsu Laravel lietojumprogrammā, lūdzu, pārliecinieties, vai ir pieejams konveijers, kas apkopo un samazina visus līdzekļu failus. Tiem, kam patīk komplektēšanas sistēma, piemēram, Webpack, Gulp, Parcel utt., nav jāraizējas, taču, ja jūs to vēl nedarāt, Laravel maisījums ir drošs ieteikums.

    Mix ir viegls (un, godīgi sakot!) apburošs apvalks ap Webpack, kas rūpējas par visiem jūsu CSS, SASS, JS utt. failiem ražošanai. Tipisks .mix.js fails var būt tikpat mazs kā šis, un tas joprojām rada brīnumus:

    const mix = require('laravel-mix');
    
    mix.js('resources/js/app.js', 'public/js')
        .sass('resources/sass/app.scss', 'public/css');

    Tas automātiski rūpējas par importēšanu, samazināšanu, optimizāciju un visu darbību, kad esat gatavs ražošanai un palaist npm palaist ražošanu. Mix rūpējas ne tikai par tradicionālajiem JS un CSS failiem, bet arī Vue un React komponentiem, kas varētu būt jūsu lietojumprogrammas darbplūsmā.

    Vairāk informācijas šeit!

    Secinājums

    Veiktspējas optimizācija ir vairāk māksla nekā zinātne — zināt, kā un cik daudz darīt, ir svarīgāka par to, ko darīt. Tas nozīmē, ka nav gala tam, cik daudz un ko varat optimizēt Laravel lietojumprogrammā.

    Taču, lai ko jūs darītu, es vēlos sniegt jums dažus atvadīšanās padomus — optimizācija ir jāveic tad, kad tam ir pamatots iemesls, nevis tāpēc, ka tas izklausās labi vai tāpēc, ka jūs esat paranojā par lietotnes veiktspēju vairāk nekā 100 000 lietotājiem. ir tikai 10.

    Ja neesat pārliecināts, vai lietotne ir jāoptimizē vai nē, jums nav jāizsit sakāmvārdu sirseņu ligzda. Darbojas lietotne, kas šķiet garlaicīga, bet dara tieši to, kas tai ir jādara, ir desmit reizes vēlamāka nekā lietotne, kas ir optimizēta par mutantu hibrīda supermašīnu, bet ik pa laikam nokrīt.

    Un, lai iesācējs kļūtu par Laravel meistaru, pārbaudiet šo tiešsaistes kurss.

    Lai jūsu lietotnes darbotos daudz, daudz ātrāk! 🙂