Kaip optimizuoti PHP „Laravel“ internetinę programą, kad ji būtų našesnė?

Laravelis yra daugybė dalykų. Bet greitas nėra nė vienas iš jų. Išmokime keletą prekybos gudrybių, kad ji vyktų greičiau!


Nei vienas PHP kūrėjas nėra nepaliestas Laravelis šiomis dienomis. Jie yra jaunesniojo ar vidutinio lygio kūrėjai, mėgstantys greitą „Laravel“ siūlomą plėtrą, arba vyresnysis kūrėjas, kuris yra priverstas mokytis „Laravel“ dėl rinkos spaudimo.

Bet kuriuo atveju negalima paneigti, kad Laravel atgaivino PHP ekosistemą (aš, be abejo, būčiau jau seniai palikęs PHP pasaulį, jei Laravelio ten nebūtų).

Laravelio (šiek tiek pagrįsto) savęs pagyrimo fragmentas

Tačiau kadangi „Laravel“ pasilenkia atgal, kad jums viskas būtų lengva, tai reiškia, kad apačioje jis atlieka daugybę darbų, kad užtikrintumėte patogų, kaip kūrėjas, gyvenimą. Visos „magiškos“ „Laravel“ savybės, kurios, atrodo, veikia, turi sluoksnius ant kodo sluoksnių, kuriuos reikia sušvilpti kiekvieną kartą, kai paleidžiama funkcija. Net paprastas išimtis leidžia atsekti triušio skylę (atkreipkite dėmesį, kur prasideda klaida, iki pat pagrindinio branduolio):

Tai, kas atrodo kompiliavimo klaida viename iš rodinių, yra 18 funkcijos kvietimų atsekti. Aš asmeniškai susidūriau su 40, ir jų gali būti daugiau, jei naudojate kitas bibliotekas ir papildinius.

Jei pagal nutylėjimą tai yra sluoksniai ant kodo sluoksnių, „Laravel“ sulėtėja.

Kiek lėtas Laravelas?

Sąžiningai kalbant, į šį klausimą atsakyti neįmanoma dėl kelių priežasčių.

Pirmas, nėra priimto, objektyvaus ir protingo žiniatinklio programų greičio matavimo standarto. Greičiau ar lėčiau, palyginti su kuo? Kokiomis sąlygomis?

Antra, žiniatinklio programa priklauso nuo tiek daug dalykų (duomenų bazės, failų sistemos, tinklo, talpyklos ir kt.), kad kalbėti apie greitį yra beprotiška. Labai greita žiniatinklio programa su labai lėta duomenų baze yra labai lėta žiniatinklio programa. ��

Tačiau būtent dėl ​​šio netikrumo yra populiarūs lyginamieji standartai. Nors jie nieko nereiškia (žr tai ir tai), jie pateikia tam tikrą orientyrą ir padeda mums išprotėti. Todėl turėdami kelis žiupsnelius druskos, suprasime neteisingą ir grubią idėją apie PHP struktūrų greitį.

Eidamas šiuo gana garbingu „GitHub“ šaltinis, Štai kaip lyginama PHP struktūra:

Gal net nepastebėsite Laravelio čia (net jei labai sunkiai sukramtote), nebent liekate savo bylą ties uodegos galu. Taip, mieli draugai, Laravelas ateina paskutinis! Dabar, žinoma, dauguma šių „rėmų“ nėra labai praktiški ar net naudingi, tačiau tai mums parodo, koks vangus yra „Laravel“, palyginti su kitais populiaresniais..

Paprastai šis „lėtumas“ netaikomas programose, nes mūsų kasdienėse žiniatinklio programose retai pasiekiamas didelis skaičius. Bet kai jie tai padaro (tarkime, padidėja 200-500 kartu), serveriai pradeda užspringti ir miršta. Laikas, kai net iššūkis daugiau techninės įrangos neišsprendžia problemos, o infrastruktūros sąskaitos auga taip greitai, kad sudužtų jūsų aukšti debesų kompiuterijos idealai.

Bet ei, pralinksmėk! Šis straipsnis yra ne apie tai, ko negalima padaryti, bet apie tai, ką galima padaryti. ��

Geros naujienos yra tai, kad galite padaryti daug, kad jūsų „Laravel“ programa veiktų greičiau. Kelis kartus greitai. Taip, nejuokauju. Galite padaryti tą pačią pagrindinę bazę naudodamiesi balistika ir kiekvieną mėnesį sutaupyti kelis šimtus dolerių už infrastruktūros / hostingo sąskaitas. Kaip? Pabandykime.

Keturios optimizacijos rūšys

Mano nuomone, optimizavimas gali būti atliekamas keturiais skirtingais lygmenimis (kai kalbama apie PHP programas, tai yra):

  1. Kalbos lygis: Tai reiškia, kad naudojate spartesnę kalbos versiją ir vengiate specifinių kodavimo kalbų funkcijų / stilių, dėl ko jūsų kodas lėtėja.
  2. Pagrindų lygis: Tai yra dalykai, kuriuos aptarsime šiame straipsnyje.
  3. Infrastruktūros lygis: Savo PHP proceso tvarkyklės, interneto serverio, duomenų bazės ir tt derinimas.
  4. Aparatūros lygis: Perėjimas prie geresnio, greitesnio ir galingesnio aparatūros prieglobos paslaugų teikėjo.

Visi šie optimizavimo tipai turi savo vietą (pavyzdžiui, „php-fpm“ optimizavimas yra gana kritiškas ir galingas). Tačiau pagrindinis dėmesys šiame straipsnyje bus skirtas tik 2 tipo optimizavimui: susijusiems su sistema.

Beje, numeracija nėra pagrįsta ir tai nėra priimtas standartas. Aš tiesiog sukūriau šiuos dalykus. Niekada nesakykite man citatos ir sakykite: „Mums reikia 3 tipo optimizacijos mūsų serveryje“. Priešingu atveju jūsų komandos vadovas nužudys jus, suras mane ir nužudys ir mane. ��

Ir štai pagaliau atvykstame į pažadėtą ​​žemę.

Žinokite apie n + 1 duomenų bazės užklausas

„N + 1“ užklausos problema yra dažna, kai naudojami ORM. „Laravel“ turi savo galingą ORM, vadinamą „Eloquent“, kuris yra toks gražus, toks patogus, kad dažnai pamirštame pažiūrėti, kas vyksta.

Apsvarstykite labai įprastą scenarijų: pateikite visų nurodyto klientų sąrašo pateiktų užsakymų sąrašą. Tai gana įprasta el. Prekybos sistemose ir bet kokiose ataskaitų teikimo sąsajose, kuriose turime rodyti visus su kai kuriais subjektais susijusius subjektus.

Laravele galime įsivaizduoti valdiklio funkciją, atliekančią šį darbą:

klasės OrdersController praplečia valdiklį
{
// …

viešoji funkcija getAllByCustomers (užklausa $ užklausa, masyvas $ id) {
$ klientai = klientas :: rasti daug ($ ID);
$ užsakymų = rinkti (); // nauja kolekcija

foreach ($ klientų kaip $ klientų) {
$ pavedimai = $ pavedimai->sujungti ($ klientas->įsakymai);
}

grįžimo vaizdas (‘admin.reports.orders’, [‘užsakymai’ => $ pavedimų]);
}
}

Saldus! Ir dar svarbiau, elegantiška, graži. ����

Deja, tai pražūtingas būdas rašyti kodą „Laravel“.

Štai kodėl.

Kai paprašome ORM ieškoti nurodytų klientų, sugeneruojama tokia SQL užklausa:

PASIRINKITE * IŠ klientų, kuriuose yra ID (22, 45, 34, …);

Kuris tiksliai toks, kokio tikėtasi. Dėl to visos grąžintos eilutės saugomos rinkinyje $ klientams valdiklio funkcijos viduje.

Dabar mes vertiname kiekvieną klientą po vieną ir gauname jų užsakymus. Tai įvykdo šią užklausą . . .

PASIRINKITE * IŠ užsakymų, kur kliento_ida = 22;

. . . tiek kartų, kiek yra klientų.

Kitaip tariant, jei mums reikia gauti užsakymo duomenis apie 1000 klientų, bendras atliktų duomenų bazės užklausų skaičius bus 1 (jei reikia visų klientų duomenų) + 1000 (norint gauti kiekvieno kliento užsakymo duomenis) = 1001. Tai iš kur kilęs vardas n + 1.

Ar galime padaryti geriau? Be abejo! Naudodamiesi vadinamuoju noriu įkelti, mes galime priversti ORM atlikti JOIN ir grąžinti visus reikalingus duomenis į vieną užklausą! Kaip šitas:

$ užsakymų = Klientas :: rasti daug ($ ID)->su (‘užsakymai’)->gauti ();

Gauta duomenų struktūra yra įdėta, žinoma, tačiau užsakymo duomenis galima lengvai išgauti. Tokiu atveju gauta viena užklausa yra kažkas tokio:

PASIRINKITE * IŠ UŽSKAITŲ NUOTOLINIŲ JŪSŲ UŽSAKYMŲ UŽSAKYMŲ.

Viena užklausa, be abejo, yra geresnė nei tūkstantis papildomų užklausų. Įsivaizduokite, kas nutiktų, jei apdorotų 10 000 klientų! Arba neduok Dieve, jei mes taip pat norėjome parodyti kiekviename užsakyme esančius daiktus! Atminkite, kad technikos pavadinimas labai norisi įkelti, ir tai beveik visada yra gera idėja.

Talpykloje išsaugokite konfigūraciją!

Viena iš „Laravel“ lankstumo priežasčių yra daugybė konfigūracijos failų, kurie yra sistemos dalis. Norite pakeisti vaizdų saugojimo būdą / vietą?

Na, tiesiog pakeiskite failą config / filesystems.php (bent jau nuo rašymo). Norite dirbti su keliais eilės vairuotojais? Nedvejodami aprašykite juos config / queue.php. Aš tik suskaičiavau ir radau, kad yra 13 konfigūracijos failų, skirtų įvairiems sistemos aspektams, užtikrinant, kad neliksite nusivylę, nesvarbu, ką norite pakeisti.

Atsižvelgiant į PHP pobūdį, kiekvieną kartą pateikus naują žiniatinklio užklausą, Laravel atsibunda, įkelia viską ir analizuoja visus šiuos konfigūracijos failus, kad išsiaiškintų, kaip šį kartą elgtis kitaip. Išskyrus tai, kad tai yra kvaila, jei per pastarąsias kelias dienas niekas nepasikeitė! Konfigūracijos atstatymas pagal kiekvieną užklausą yra švaistymas, kurio galima (iš tikrųjų reikia vengti) išvengti, o išeitis yra paprasta komanda, kurią siūlo „Laravel“:

php amatininko konfigūracija: talpykla

Tai reiškia, kad visi galimi konfigūracijos failai sujungiami į vieną, o talpykla yra greito gavimo galimybė. Kai kitą kartą bus užklausa dėl interneto, „Laravel“ tiesiog perskaitys šį failą ir pradės veikti.

Konfigūracijos kaupimas talpykloje yra ypač subtilus veiksmas, kuris gali susprogdinti jūsų veidą. Didžiausia priegaida yra ta, kad kai tik išleisi šią komandą, funkcija „env ()“ skambina iš visur, išskyrus konfigūracijos failus, grįšianti negaliojanti!

Tai turi prasmę, kai pagalvoji apie tai. Jei naudojate konfigūracijos talpyklą, sakote sistemai „Žinai ką, manau, kad viską gerai suderinau ir esu 100% tikras, kad nenoriu, kad jie pasikeistų“. Kitaip tariant, jūs tikitės, kad aplinka išliks statiška, tam ir yra .env failai.

Tai pasakius, čia yra keletas geležies plakiruotų, šventų, nesulaužomų konfigūravimo talpyklos taisyklių:

  1. Darykite tai tik pagal gamybos sistemą.
  2. Darykite tai tik tada, kai esate tikrai tikri, ar tikrai norite užšaldyti konfigūraciją.
  3. Jei kas nors nutiks ne taip, anuliuokite nustatymą naudodamiesi „php artisan“ talpykla: išvalykite
  4. Melskitės, kad žala verslui nebuvo reikšminga!

Sumažinkite automatiškai įkeltų paslaugų skaičių

Kad būtų naudinga, „Laravel“ atsikelia labai daug paslaugų, kai atsibunda. Juos galima rasti „config / app.php“ faile kaip „teikėjų“ masyvo rakto dalį. Pažvelkime į tai, ką turiu savo atveju:

/ *
|————————————————————————–
| Autoloadled Service Providers
|————————————————————————–
|
| Čia išvardyti paslaugų teikėjai bus automatiškai įkeliami į
| prašymą jūsų paraiškai. Nesivaržykite įtraukti savo paslaugų
| Šis rinkinys suteikia išplėstinę jūsų programų funkcionalumą.
|
* /

‘teikėjai’ => [

/ *
* „Laravel“ pagrindų paslaugų teikėjai…
* /
Apšvieskite \ Auth \ AuthServiceProvider :: klasė,
Apšvieskite \ Broadcasting \ BroadcastServiceProvider :: klasė,
Apšvieskite \ Autobusas \ BusServiceProvider :: klasė,
Apšviesti \ Cache \ CacheServiceProvider :: klasė,
Apšvieskite \ Foundation \ Providers \ ConsoleSupportServiceProvider :: klasė,
Apšviesti \ Cookie \ CookieServiceProvider :: klasė,
Apšviesti \ Duomenų bazė \ DatabaseServiceProvider :: klasė,
Apšviesti \ Encryption \ EncryptionServiceProvider :: klasė,
Apšvieskite \ Filesystem \ FilesystemServiceProvider :: klasė,
Apšvieskite \ Foundation \ Providers \ FoundationServiceProvider :: klasė,
Apšvieskite \ hashing \ HashServiceProvider :: klasę,
Apšvieskite \ Mail \ MailServiceProvider :: klasė,
Apšvieskite \ Notifications \ NotificationServiceProvider :: klasė,
Apšviesti \ Paginimas \ PaginationServiceProvider :: klasė,
Apšvieskite \ Pipeline \ PipelineServiceProvider :: klasė,
Apšvieskite \ Queue \ QueueServiceProvider :: klasė,
Apšvieskite \ Redis \ RedisServiceProvider :: klasė,
Apšvieskite \ Auth \ Passwords \ PasswordResetServiceProvider :: klasė,
Apšvieskite \ Sesija \ SessionServiceProvider :: klasė,
Apšvieskite \ Translation \ TranslationServiceProvider :: klasė,
Apšviesti \ Validation \ ValidationServiceProvider :: klasė,
Apšvieskite \ View \ ViewServiceProvider :: klasę,

/ *
* Pakuotės paslaugų teikėjai…
* /

/ *
* Programų paslaugų teikėjai…
* /
„App \ Providers \ AppServiceProvider ::“ klasė,
Programos \ teikėjai \ AuthServiceProvider :: klasė,
// Programos \ teikėjai \ BroadcastServiceProvider :: klasė,
„App \ Providers \ EventServiceProvider ::“ klasė,
Programos \ teikėjai \ RouteServiceProvider :: klasė,

],

Dar kartą suskaičiavau, kad yra 27 paslaugos išvardytos! Dabar gali reikėti jų visų, bet mažai tikėtina.

Pvz., Aš šiuo metu kuriu REST API, tai reiškia, kad man nereikia sesijų paslaugų teikėjo, peržiūros paslaugų teikėjo ir kt. Kadangi aš darau keletą dalykų savo kelią ir nesilaikau numatytųjų sistemos pagrindų , Taip pat galiu išjungti „Auth“ paslaugų teikėją, puslapių kūrimo paslaugų teikėją, vertimo paslaugų teikėją ir pan. Apskritai, beveik pusė jų yra nereikalingi mano naudojimui.

Ilgai ir sunkiai pažvelkite į savo paraišką. Ar reikia visų šių paslaugų teikėjų? Bet dėl ​​Dievo, prašau nekomentuoti šių paslaugų ir stumti į produkciją! Atlikite visus testus, patikrinkite dalykus rankiniu būdu naudodami dev ir sustojimo mašinas ir būkite labai paranojiški prieš traukdami gaiduką. ��

Būkite protingi naudodami tarpinės programinės įrangos paketus

Kai jums reikia šiek tiek apdoroti gaunamą žiniatinklio užklausą, atsakymas yra naujos tarpinės programinės įrangos kūrimas. Dabar kyla pagunda atidaryti programą / „Http“ / „Kernel.php“ ir priklijuoti tarpinę programinę įrangą žiniatinklyje arba „api“ krūvoje; tokiu būdu ji tampa prieinama visoje programoje ir jei ji nedaro kažkokio įkyraus (pvz., prisijungia ar nepraneša, pavyzdžiui).

Tačiau augant programai ši visuotinės tarpinės programinės įrangos kolekcija gali tapti tylia našta programai, jei visi (arba dauguma) jų yra kiekvienoje užklausoje, net jei tam nėra verslo priežasties..

Kitaip tariant, būkite atsargūs, kur pridėsite / pritaikysite naują tarpinę programinę įrangą. Gali būti patogiau ką nors pridėti visame pasaulyje, tačiau ilgainiui bausmė už atlikimą yra labai didelė. Aš žinau, kokį skausmą turėtumėte patirti, jei pasirinktinai taikytumėte tarpinę programinę įrangą kiekvieną kartą, kai įvyks naujas pakeitimas, tačiau tai skausmas, kurio norėčiau priimti ir rekomenduoti.!

Venkite ORM (kartais)

Nors Eloquent daugeliu DB sąveikos aspektų teikia malonumą, tačiau tai kainuoja greičio sąskaita. Būdamas žemėlapių sudarytoju, ORM ne tik turi gauti įrašus iš duomenų bazės, bet ir atgaminti modelio objektus ir hidruoti (užpildyti) juos stulpelių duomenimis..

Taigi, jei naudojate paprastą $ vartotoją = Vartotojas :: visi () ir yra, tarkime, 10 000 vartotojų, sistema iš duomenų bazės nuskaitys 10 000 eilučių, o viduje padarys 10 000 naujų Vartotojų () ir užpildys jų savybes atitinkamais duomenimis. . Tai užima didelę dalį darbų, kuriuos atliksite užkulisiuose, ir jei duomenų bazė, kur esate, yra programa, tampa kliūtimi, kartais gera idėja apeiti ORM.

Tai ypač pasakytina apie sudėtingas SQL užklausas, kai jūs turėtumėte peršokti daug lankstų ir rašyti uždarymus uždarydami ir vis tiek baigti efektyvia užklausa. Tokiais atvejais pirmenybė teikiama DB :: raw () ir užklausos rašymui ranka.

Važiuoju pro šalį tai atlikimo tyrimas, net ir paprastų intarpų atveju, Eloquent yra daug lėtesnis, nes didėja įrašų skaičius:

Kiek įmanoma naudokite talpyklą

Viena iš geriausiai saugomų žiniatinklio programų optimizavimo paslapčių yra talpyklos kaupimas.

Neinicijuotas talpyklos kaupimas reiškia iš anksto apskaičiuoti ir saugoti brangius rezultatus (brangius, atsižvelgiant į procesoriaus ir atminties naudojimą), o juos paprasčiausiai grąžinti, kai pakartojama ta pati užklausa..

Pavyzdžiui, el. Prekybos parduotuvėje gali tekti susidurti su 2 milijonais produktų, dažniausiai žmonės domisi produktais, kurie yra šviežiai sandėliuojami, tam tikru kainų intervalu ir tam tikrai amžiaus grupei. Užklausti šios informacijos duomenų bazę yra beprasmiška – kadangi užklausa nesikeičia dažnai, šiuos rezultatus geriau laikyti ten, kur galime greitai pasiekti..

„Laravel“ turi kelių tipų palaikymą talpyklos. Galbūt norėsite ne tik naudoti talpyklos tvarkyklę ir kaupti talpyklos sistemą nuo pat žemės paviršiaus, bet ir keletą „Laravel“ paketų, kurie palengvina modelio talpyklos kaupimas, užklausos talpyklos, ir tt.

Tačiau atminkite, kad ne tik tam tikru supaprastintu naudojimo atveju, iš anksto sukurti talpyklos paketai gali sukelti daugiau problemų, nei jie išsprendžia.

Geriau kaupti talpykloje

Kai ką nors talpinate „Laravel“, turite keletą galimybių, kur laikyti gautą skaičiavimą, kurį reikia talpykloje. Šios parinktys taip pat žinomos kaip talpyklų tvarkyklės. Taigi, jei įmanoma ir visiškai pagrįsta naudoti failų sistemą talpyklos rezultatams saugoti, tai tikrai nėra tai, kas yra talpyklos turėjimas.

Idealiu atveju norite naudoti talpykloje esančią talpyklą (kurioje gyvenama visa RAM), pvz., „Redis“, „Memcached“, „MongoDB“ ir kt., Kad didesnėmis apkrovomis talpyklos būtų naudojamos gyvybiškai, o ne taptų kliūtimi..

Dabar galite pamanyti, kad turėti SSD diską yra beveik tas pats, kas naudoti RAM atmintį, tačiau jis nėra net artimas. Net neformalus etalonai parodykite, kad RAM viršija SSD 10-20 kartų, kai kalbama apie greitį.

Mano mėgstamiausia sistema talpykloje yra „Redis“. Tai yra juokingai greitai (100 000 skaitymo operacijų per sekundę yra įprasti), o labai didelėms talpyklų sistemoms galima paversti a klasteris lengvai.

Talpinkite maršrutus

Kaip ir programos konfigūracija, maršrutai laikui bėgant beveik nesikeičia ir yra idealus kandidatas talpykloje. Tai ypač aktualu, jei negalite pakęsti didelių failų, tokių kaip aš, ir galų gale padalinti web.php ir api.php keliems failams. Viena „Laravel“ komanda supakuoja visus galimus maršrutus ir juos patogu naudoti ateityje:

php amatininkų maršrutas: talpykla

Kai galų gale pridėsite ar pakeisite maršrutus, tiesiog darykite:

php amatininkų maršrutas: aiškus

Vaizdo optimizavimas ir CDN

Vaizdai yra daugumos interneto programų širdis ir siela. Aišku, jie taip pat yra didžiausi pralaidumo vartotojai ir viena didžiausių lėtų programų / svetainių priežasčių. Jei tiesiog naiviai saugote įkeltus vaizdus serveryje ir atsiųsite juos atgal į HTTP atsakymus, leisite didžiulę optimizavimo galimybę paslėpti.

Mano pirmoji rekomendacija nėra saugoti vaizdus vietoje – kyla duomenų praradimo problema, ir atsižvelgiant į tai, kuriame geografiniame regione yra jūsų klientas, duomenų perdavimas gali būti skausmingai lėtas.

Verčiau ieškokite tokio sprendimo Debesuota kuris automatiškai keičia dydį ir optimizuoja vaizdus skrendant.

Jei tai neįmanoma, naudokite kažką panašaus į „Cloudflare“ talpykloje ir atvaizdams pateikti, kol jie saugomi jūsų serveryje.

Ir net jei tai neįmanoma, šiek tiek pakeisdami žiniatinklio serverio programinę įrangą, kad suspaustumėte išteklius ir nukreiptumėte lankytojo naršyklę į talpyklą, yra labai daug. Štai kaip atrodytų „Nginx“ konfigūracijos fragmentas:

serveris {

# failas sutrumpintas

# gzip glaudinimo nustatymai
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied bet;
gzip_vary on;

# naršyklės talpyklos valdymas
vieta ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
baigiasi 1d;
„access_log off“;
add_header Pragma public;
add_header Cache-Control "viešas, maksimalus amžius = 86400";
}
}

Aš žinau, kad vaizdo optimizavimas neturi nieko bendra su Laravel, tačiau tai yra toks paprastas ir galingas triukas (ir taip dažnai pamiršamas), kuris man negalėjo padėti.

Automatinio krautuvo optimizavimas

Automatinis krovimas yra tvarkinga, ne tokia jau sena PHP funkcija, kuri, be abejo, išgelbėjo kalbą nuo likimo. Vis dėlto atitinkamos klasės radimo ir įkėlimo procesas, iššifruojant duotą vardų srities eilutę, užtrunka ir to galima išvengti diegiant gamybą, kur pageidautinas didelis našumas. Dar kartą „Laravel“ turi vienos komandos sprendimą tam:

kompozitoriaus instaliacija –optimizuoti-autoloader –no-dev

Draugaukite su eilėmis

Eilės yra tai, kaip jūs apdorojate dalykus, kai jų yra daug, ir kiekvienam iš jų atlikti reikia kelių milisekundžių. Puikus pavyzdys yra el. Laiškų siuntimas – žiniatinklio programose paplitęs atvejis yra tai, kad vartotojui atliekant tam tikrus veiksmus reikia nušauti kelis pranešimų el. Laiškus..

Pavyzdžiui, naujai išleistame produkte galite norėti, kad apie tai įmonės vadovybei (apie 6–7 el. Pašto adresus) būtų pranešta kiekvieną kartą, kai kas nors pateikia užsakymą virš tam tikros vertės. Darant prielaidą, kad jūsų el. Pašto šliuzas gali atsakyti į jūsų SMTP užklausą per 500 ms, mes kalbame apie gerą 3–4 sekundžių laukimą, kol vartotojas pradės užsakymo patvirtinimą. Tikrai blogas UX kūrinys, aš tikiu, kad jūs susitarti.

Priemonė yra saugoti užduotis, kai tik jie ateina, pasakyti vartotojui, kad viskas vyko gerai, ir vėliau (kelias sekundes) juos apdoroti. Jei įvyksta klaida, eilėje pateiktus darbus galima kelis kartus išbandyti dar prieš paskelbiant, kad jie nepavyko.

Kreditai: Microsoft.com

Eilių sudarymo sistema šiek tiek apsunkina sąranką (ir prideda šiek tiek stebėjimo išlaidų), ji yra būtina šiuolaikinėje žiniatinklio programoje..

Turto optimizavimas („Laravel Mix“)

Turėdami visą „Laravel“ programos aktyvųjį turinį, įsitikinkite, kad yra paruoštas vamzdynas, kuris kaupia ir mažina visus išteklių failus. Tiems, kuriems patogu naudoti tokias įpakavimo sistemas kaip „Webpack“, „Gulp“, „Parcel“ ir kt., Nereikia nerimauti, bet jei to dar nepadarote, „Laravel Mix“ yra tvirta rekomendacija.

„Mix“ yra lengvas (ir be galo malonus, be galo sąžiningas!) Aplankas aplink „Webpack“, kuris rūpinasi visais jūsų CSS, SASS, JS ir kt. Failais, skirtais gaminti. Įprastas .mix.js failas gali būti toks mažas ir vis dar įdomu:

const mix = reikalauti (‘laravel-mix’);

mix.js („ištekliai / js / app.js“, „public / js“)
.sass (‘ištekliai / sass / app.scss’, ‘public / css’);

Tai automatiškai pasirūpins importu, sumažinimu, optimizavimu ir visu šablonu, kai būsite pasirengę gamybai ir vykdysite „npm run“ gamybą. „Mix“ rūpinasi ne tik tradiciniais JS ir CSS failais, bet ir „Vue“ bei „React“ komponentais, kurie gali būti jūsų programos darbo eigoje..

Daugiau informacijos čia!

Išvada

Spektaklio optimizavimas yra daugiau menas nei mokslas – svarbu žinoti, kaip ir kiek reikia padaryti, nei ką daryti. Nepaisant to, ne viskas, ką galite optimizuoti naudodami „Laravel“ programą, nesibaigia.

Bet kad ir ką darytumėte, norėčiau jums pateikti keletą patarimų dėl atskyrimo – optimizavimas turėtų būti atliekamas tada, kai yra svari priežastis, o ne todėl, kad tai gerai skamba ar todėl, kad esate paranojiškas dėl programos našumo 100 000 ir daugiau vartotojų, o iš tikrųjų yra tik 10.

Jei nesate tikri, ar turite optimizuoti savo programą, ar ne, jums nereikia spardyti patarlių ragelių lizdo. Veiksminga programa, kuri jaučiasi nuobodi, tačiau padaro būtent tai, ką turi, yra dešimt kartų labiau pageidautina nei programa, kuri buvo optimizuota į mutantinį hibridinį supermachiną, tačiau dabar sustingsta.

Ir norėdami, kad newbiew taptų „Laravel“ meistru, patikrinkite tai internetinis kursas.

Tegul jūsų programos veikia daug, daug greičiau! ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map