Si të zgjedhim aplikacionin në internet PHP Laravel për performancë të lartë?

Laravel është shumë gjëra. Por agjërimi nuk është njëri prej tyre. Le të mësojmë disa truke të tregtisë për ta bërë atë të shkojë më shpejt!


Asnjë zhvillues i PHP nuk është i prekur nga Laravel keto dite. Ata janë ose një zhvillues i ri ose i nivelit të mesëm që e duan zhvillimin e shpejtë që ofron Laravel, ose ata janë një zhvillues i vjetër që po detyrohet të mësojë Laravel për shkak të presioneve të tregut.

Sido që të jetë, nuk ka asnjë mohim që Laravel ka rivitalizuar ekosistemin PHP (Unë, me siguri, do të largohesha nga bota PHP shumë kohë më parë nëse Laravel nuk do të ishte atje).

Një copë e lavdërimit (disi të justifikuar) nga Laravel

Sidoqoftë, meqenëse Laravel përkulet prapa për t’i bërë gjërat më të lehta për ju, do të thotë që nën të po bëni ton dhe ton të punës për t’u siguruar që keni një jetë të rehatshme si një zhvillues. Të gjitha tiparet “magjike” të Laravel që thjesht duket se funksionojnë kanë shtresa mbi shtresa të kodit që duhet të fshihen sa herë që funksionon një veçori. Edhe një përjashtim i thjeshtë gjurmë sa e thellë është vrima e lepurit (vini re se ku fillon gabimi, deri në kernelin kryesor):

Për atë që duket se është një gabim përpilimi në një nga pamjet, ekzistojnë 18 thirrje funksionesh për të gjetur. Unë personalisht kam hasur në 40, dhe lehtë mund të ketë më shumë nëse përdorni biblioteka dhe shtojca të tjera.

Pika duke qenë, që këto shtresa default sipas shtresave të kodit, e bëjnë Laravel të ngadaltë.

Sa e ngadaltë është Laravel?

Sinqerisht, është e pamundur t’i përgjigjesh kësaj pyetjeje për disa arsye.

i parë, nuk ka asnjë standard të pranuar, objektiv dhe të ndjeshëm për matjen e shpejtësisë së aplikacioneve në Ueb. Më e shpejtë apo më e ngadaltë në krahasim me çfarë? Në çfarë kushtesh?

i dytë, një aplikacion në internet varet nga kaq shumë gjëra (baza e të dhënave, sistemi i skedarëve, rrjeti, cache, etj.) saqë është pa mend të flasim për shpejtësinë. Një aplikacion shumë i shpejtë në internet me një bazë të dhënash shumë të ngadaltë është një program shumë i ngadaltë në internet. ��

Por kjo pasiguri është pikërisht arsyeja pse standardet e njohjes janë të njohura. Edhe pse nuk kuptojnë asgjë (shiko kjo dhe kjo), ato ofrojnë një kornizë reference dhe na ndihmojnë të çmendemi. Prandaj, me disa copa kripe të gatshme, le të marrim një ide të gabuar, të ashpër për shpejtësinë midis kornizave PHP.

Duke kaluar nga ky GitHub mjaft i respektueshëm burim, Ja se si rreshtohen kornizat e PHP kur krahasohen:

Ju mund të mos e vini re edhe Laravel këtu (edhe nëse e dëmtoni vërtet) nëse nuk e vendosni çështjen tuaj deri në fund të bishtit. Po, të dashur miq, Laravel vjen i fundit! Tani, e dhënë, shumica e këtyre “kornizave” nuk janë shumë praktike dhe as të dobishme, por na tregon se sa i ngadaltë është Laravel kur krahasohet me ato të tjera më të njohura..

Normalisht, kjo “ngadalësi” nuk paraqet në aplikacione sepse aplikacionet tona të përditshme në internet rrallë godasin numra të lartë. Por sapo ta bëjnë (të themi, lart me 200-500 konkurencë), serverët fillojnë të mbyten dhe vdesin. Shtë koha kur edhe hedhja e më shumë pajisjeve ndaj problemit nuk e zvogëlon atë, dhe faturat e infrastrukturës ngjiten aq shpejt, sa idealet e tua të larta të informatikës cloud bien poshtë.

Por hej, gëzo! Ky artikull nuk ka të bëjë me atë që nuk mund të bëhet, por për atë që mund të bëhet. ��

Lajm i mirë është, ju mund të bëni shumë për ta bërë aplikacionin tuaj Laravel të shkojë më shpejt. Disa herë shpejt. Po, jo shaka. Ju mund ta bëni të njëjtën bazë të kodit të shkojë balliste dhe të kurseni disa qindra dollarë në faturat e infrastrukturës / pritjes çdo muaj. Si? Le ta arrijmë atë.

Katër lloje optimizimesh

Sipas mendimit tim, optimizimi mund të bëhet në katër nivele të veçanta (kur bëhet fjalë për aplikimet PHP, domethënë):

  1. Të nivelit të gjuhës: Kjo do të thotë që ju përdorni një version më të shpejtë të gjuhës dhe shmangni karakteristikat / stilet specifike të kodimit në gjuhën që e bëjnë kodin tuaj të ngadaltë.
  2. Nivelit kornizë: Këto janë gjërat që do të mbulojmë në këtë artikull.
  3. Nivelit Infrastruktura: Akordimi i menaxherit tuaj të procesit PHP, serverit të internetit, bazës së të dhënave, etj.
  4. Të nivelit të hardware: Kalimi në një ofrues më të mirë, më të shpejtë, më të fuqishëm të pritjes së pajisjeve.

Të gjithë këta lloj optimizimesh kanë vendin e tyre (për shembull, optimizimi i php-fpm është goxha kritik dhe i fuqishëm). Por fokusi i këtij artikulli do të jetë optimizimi thjesht i tipit 2: ato që lidhen me kornizën.

Nga rruga, nuk ka asnjë arsyetim prapa numrimit, dhe nuk është një standard i pranuar. Unë thjesht i bëra këto. Ju lutem mos më citoni kurrë dhe mos thuaj, “Ne kemi nevojë për optimizim tip-3 në serverin tonë”, ose udhëheqësi i ekipit tuaj do t’ju vrasë, do të më gjeni dhe pastaj do të më vrisni gjithashtu. ��

Dhe tani, më në fund, mbërrijmë në tokën e premtuar.

Kini kujdes për pyetjet e të dhënave n + 1

Problemi i pyetjes n + 1 është i zakonshëm kur përdoren ORM-të. Laravel ka ORM-në e saj të fuqishme të quajtur Eloquent, e cila është aq e bukur, aq e përshtatshme, saqë shpesh harrojmë të shikojmë se çfarë po ndodh.

Konsideroni një skenar shumë të zakonshëm: shfaqjen e listës së të gjitha porosive të vendosura nga një listë e caktuar e klientëve. Kjo është mjaft e zakonshme në sistemet e tregtisë elektronike dhe çdo ndërfaqe raportuese në përgjithësi, ku ne kemi nevojë për të shfaqur të gjitha entitetet që lidhen me disa subjekte.

Në Laravel, ne mund të imagjinojmë një funksion kontrollues që e bën punën si kjo:

OrdersController i klasës shtrin Kontrollorin
{
// …

funksioni publik merrniAllByCustomers (Kërkoni kërkesë $ $, $ ID $) {
$ konsumatorë = Klientë :: findMany ($ ids);
$ urdhra = mbledh (); // Koleksion i ri

parathënë (klientët $ si klientë $) {
$ urdhra = $ urdhra->bashkojë ($ konsumatorëve->urdhërat);
}

pamje kthimi (‘admin.reports.order’, [‘urdhra’ => $ urdhërat]);
}
}

E embel! Dhe më e rëndësishmja, elegante, e bukur. ����

Fatkeqësisht, është një mënyrë shkatërrimtare për të shkruar kodin në Laravel.

Ja pse.

Kur kërkojmë nga ORM të kërkojë klientët e dhënë, një pyetje SQL si kjo gjenerohet:

SELECT * NGA klientët KU JENI ID (22, 45, 34, ….);

E cila është saktësisht siç pritej. Si rezultat, të gjitha rreshtat e kthyera ruhen në koleksionin klientët $ brenda funksionit të kontrolluesit.

Tani ne mbështjellim çdo klient një nga një dhe i marrim porositë e tyre. Kjo ekzekuton pyetjen e mëposhtme . . .

SELECT * NGA urdhrat KU KUJ konsumatori_id = 22;

. . . sa herë ka klientë.

Me fjalë të tjera, nëse duhet të marrim të dhënat e porosive për 1000 klientë, numri i përgjithshëm i pyetjeve të bazës së të dhënave të ekzekutuara do të jetë 1 (për marrjen e të dhënave të të gjithë klientëve) + 1000 (për marrjen e të dhënave për porosinë për secilin klient) = 1001. Kjo është prej nga vjen emri n + 1.

A mund të bëjmë më mirë? Sigurisht! Duke përdorur atë që njihet si ngarkim i etur, ne mund ta detyrojmë ORM të kryejë një PINRBASHKT dhe t’i kthejmë të gjitha të dhënat e nevojshme në një pyetje të vetme! Si kjo:

$ urdhra = Klienti :: findMany ($ ids)->me ( ‘urdhëron’)->marr();

Struktura e të dhënave rezultuese është e sigurt, por të dhënat e rendit mund të nxirren lehtësisht. Pyetja e vetme që rezulton, në këtë rast, është diçka si kjo:

SELECT * NGA klientët INNER T JO BASHKUAR T orders porositur MBI konsumatorët.id = urdhra.customer_id KU klientët.ID N ((22, 45, ….);

Një pyetje e vetme është, natyrisht, më e mirë se një mijë pyetje shtesë. Imagjinoni se çfarë do të ndodhte nëse do të kishte 10,000 klientë për t’u përpunuar! Ose Zoti na ruajt nëse do të donim të shfaqnim artikujt e përmbajtur në çdo mënyrë! Mos harroni, emri i teknikës është i etur për ngarkim dhe është pothuajse gjithmonë një ide e mirë.

Cache konfigurimin!

Një nga arsyet e fleksibilitetit të Laravel është ton i skedarëve të konfigurimit që janë pjesë e kornizës. Dëshironi të ndryshoni sesi / ku janë ruajtur imazhet?

Epo, thjesht ndryshoni skedarin e konfigurimit / skedarëve.php (të paktën sa i shkrimit). Dëshironi të punoni me shofer të shumëfishtë në radhë? Mos ngurroni t’i përshkruani ato në konfigurim / radhë.php. Unë thjesht llogaritura dhe zbulova se ka 13 skedarë konfigurimi për aspekte të ndryshme të kornizës, duke siguruar që nuk do të zhgënjeheni pa marrë parasysh se çfarë doni të ndryshoni.

Duke pasur parasysh natyrën e PHP, sa herë që hyni në një kërkesë të re në internet, Laravel zgjohet, çizmon gjithçka, dhe grumbullon të gjitha këto skedarë konfigurimi për të kuptuar se si t’i bëni gjërat ndryshe kësaj radhe. Përveç se është marrëzi nëse asgjë nuk ka ndryshuar gjatë ditëve të fundit! Rindërtimi i konfigurimit për çdo kërkesë është një humbje që mund të shmanget (në të vërtetë, duhet të shmanget), dhe rruga për të dalë është një komandë e thjeshtë që ofron Laravel:

konfigurimi i artizanës php: cache

Ajo që bën është kombinimi i të gjitha skedarëve të konfigurimit në dispozicion në një të vetme dhe cache është diku për rikthim të shpejtë. Herën tjetër kur të ketë një kërkesë në Ueb, Laravel thjesht do ta lexojë këtë skedar të vetëm dhe do të shkojë.

Thënë kështu, ruajtja e konfigurimit është një operacion jashtëzakonisht delikat që mund të fryhet në fytyrën tuaj. Gjëja më e madhe është që pasi të keni lëshuar këtë komandë, thirrja e funksionit env () nga kudo, përveç se skedarët e konfigurimit do të kthehen të pavlefshme!

Ka kuptim kur mendoni për të. Nëse përdorni caching të konfigurimit, ju po i thoni kornizës, “Ju e dini se çfarë, unë mendoj se i kam vendosur gjërat mirë dhe unë jam 100% i sigurt që nuk dua që ato të ndryshojnë.” Me fjalë të tjera, ju po prisni që mjedisi të mbetet statik, për çka janë skedarët .env.

Me sa thamë, këtu janë disa rregulla të veshura me hekur, të shenjtë, të pathyeshëm të caching të konfigurimit:

  1. Bëni atë vetëm në një sistem prodhimi.
  2. Bëni atë vetëm nëse jeni vërtet, vërtet të sigurt që dëshironi të ngrini konfigurimin.
  3. Në rast se diçka nuk shkon mirë, prishni cilësimin me cache artizanale PHP: qartë
  4. Lutuni që dëmi i bërë biznesit të mos ishte i rëndësishëm!

Ulja e shërbimeve të autoloaded

Për të qenë e dobishme, Laravel ngarkon një ton shërbimesh kur zgjohet. Këto janë të disponueshme në skedarin e konfigurimit / app.php si pjesë e çelësit të grupit ‘ofruesit’. Le ta shohim atë që kam në rastin tim:

/ *
|————————————————————————–
| Ofruesit e Shërbimeve të Autorizuara
|————————————————————————–
|
| Ofruesit e shërbimeve të listuara këtu do të ngarkohen automatikisht në internet
| kërkesë për kërkesën tuaj. Mos ngurroni të shtoni shërbimet tuaja në
| kjo grup për të dhënë funksionalitet të zgjeruar në aplikacionet tuaja.
|
* /

‘ofruesit’ => [

/ *
* Ofruesit e Shërbimit Kuadër Laravel…
* /
Ndriçoji \ Auth \ AuthServiceProvider :: klasë,
Ndriçoji \ Broadcasting \ BroadcastServiceProvider :: klasë,
Ndriçoji \ Bus \ BusServiceProvider :: klasë,
Ndriçoji \ Cache \ CacheServiceProvider :: klasë,
Ndriçoji \ themeli \ ofruesve \ ConsoleSupportServiceProvider :: klasë,
Ndriçoji \ Cookie \ CookieServiceProvider :: klasë,
Ndriçuar \ Baza e të dhënave \ DatabaseServiceProvider :: klasë,
Ndriçoji \ Encryption \ EncryptionServiceProvider :: klasë,
Ndriçoji \ Filesystem \ FilesystemServiceProvider :: klasë,
Ndriçoji \ themeli \ ofruesve \ FoundationServiceProvider :: klasë,
Ndriçuar \ hashing \ HashServiceProvider :: klasë,
Ndriçoji \ Mail \ MailServiceProvider :: klasë,
Ndriçoji \ Njoftimet \ NotificationServiceProvider :: klasë,
Ndriçoji \ Pagination \ PaginationServiceProvider :: klasë,
Ndriçoji \ Pipeline \ PipelineServiceProvider :: klasë,
Ndriçoji \ Queue \ QueueServiceProvider :: klasë,
Ndriçoji \ Redis \ RedisServiceProvider :: klasë,
Ndriçoji \ Auth \ Passwords \ PasswordResetServiceProvider :: klasë,
Ndriçoji \ Session \ SessionServiceProvider :: klasë,
Ndriçoji \ Përkthimi \ TranslationServiceProvider :: klasë,
Ndriçoji \ Validation \ ValidationServiceProvider :: klasë,
Ndriçoji \ View \ ViewServiceProvider :: klasë,

/ *
* Ofruesit e Shërbimeve të Paketave…
* /

/ *
* Ofruesit e Shërbimit të Aplikimit…
* /
APP \ ofruesve \ AppServiceProvider :: klasë,
APP \ ofruesve \ AuthServiceProvider :: klasë,
// klasa e aplikacionit \ Ofruesit \ BroadcastServiceProvider ::,
APP \ ofruesve \ EventServiceProvider :: klasë,
APP \ ofruesve \ RouteServiceProvider :: klasë,

],

Edhe një herë, unë numërova, dhe janë 27 shërbime të listuara! Tani, ju mund të keni nevojë për të gjithë ata, por nuk është e mundshme.

Për shembull, unë jam duke ndërtuar një API REST për momentin, që do të thotë se nuk kam nevojë për Ofruesin e Shërbimit Sesion, Shiko Ofruesin e Shërbimit, etj. Meqenëse jam duke bërë disa gjëra në mënyrën time dhe jo duke ndjekur standardet e kornizës , Mund të çaktivizoj gjithashtu Ofruesin e Shërbimit Auth, Ofruesin e Shërbimit të Paginimit, Ofruesin e Shërbimit të Përkthimit, etj. Në përgjithësi, pothuajse gjysma e këtyre janë të panevojshme për rastin e përdorimit tim.

Shikoni një vështrim të gjatë dhe të vështirë në aplikacionin tuaj. A i duhen të gjithë këta ofrues të shërbimeve? Por për hir të Zotit, ju lutemi mos i komentoni verbërisht këto shërbime dhe nxitni për prodhim! Drejtoni të gjitha provat, kontrolloni gjërat manualisht në makinat dev dhe skenë, dhe bëhuni shumë paranojak para se të tërhiqni zinxhirin. ��

Jini të mençur me rafte të mesit

Kur keni nevojë për disa përpunime me porosi të kërkesës në hyrje në Web, krijimi i një programi të ri ndërmjetës është përgjigjja. Tani, është joshëse të hapni aplikacionin / Http / Kernel.php dhe të ngjitni programin e mesit në internet ose rafte të api; në atë mënyrë, ai bëhet i disponueshëm në të gjithë aplikacionin dhe nëse nuk po bën diçka ndërhyrëse (psh logjikimi ose njoftimi, për shembull).

Sidoqoftë, ndërsa aplikacioni rritet, kjo koleksion i middleware global mund të bëhet një barrë e heshtur për aplikacionin nëse të gjitha (ose shumica) e këtyre janë të pranishme në çdo kërkesë, edhe nëse nuk ka asnjë arsye biznesi për këtë.

Me fjalë të tjera, kini kujdes se ku shtoni / aplikoni një ndërmjetës të ri. Mund të jetë më i përshtatshëm për të shtuar diçka globalisht, por dënimi i performancës është shumë i lartë në planin afatgjatë. Unë e di dhimbjen që duhet të pësoni nëse do të aplikonit në mënyrë selektive çdo herë që të keni një ndryshim të ri, por është një dhimbje që do ta marr dhe rekomandoj me dëshirë!

Shmangni ORM-in (nganjëherë)

Ndërsa Eloquent i bën shumë aspekte të ndërveprimit DB të këndshëm, ai vjen me koston e shpejtësisë. Duke qenë një hartues, ORM jo vetëm që duhet të marrë shënime nga baza e të dhënave, por edhe të nxisë objektet e modelit dhe t’i hidratojë (plotësojë ato) me të dhëna kolone.

Pra, nëse bëni një përdorues të thjeshtë $ $ = Përdorues: të gjithë () dhe ka, të themi, 10,000 përdorues, korniza do të marrë 10,000 rreshta nga baza e të dhënave dhe nga brenda do të bëjë 10,000 Përdorues të rinj () dhe të plotësojë pronat e tyre me të dhënat përkatëse . Kjo është sasi masive e punës që po bëhet prapa skenës, dhe nëse baza e të dhënave është kur aplikacioni po bëhet një pengesë, anashkalimi i ORM është një ide e mirë ndonjëherë.

Kjo është veçanërisht e vërtetë për pyetjet komplekse SQL, ku do të duhet të hidheni shumë sythe dhe të shkruani mbyllje në mbyllje dhe të përfundoni akoma me një pyetje efikase. Në raste të tilla, preferohet të bëni një DB :: të papërpunuar () dhe të shkruani pyetjen me dorë.

Duke shkuar pranë kjo studimi i performancës, edhe për futjet e thjeshta Eloquent është shumë më i ngadalshëm pasi numri i regjistrave rritet:

Përdorni caching sa më shumë që të jetë e mundur

Një nga sekretet e ruajtura më së miri për optimizimin e aplikacionit në internet është caching.

Për të pa inituruarit, caching do të thotë prekompozim dhe ruajtje e rezultateve të shtrenjta (të shtrenjta për sa i përket CPU-së dhe përdorimit të kujtesës), dhe thjesht kthimi i tyre kur të njëjtën pyetje përsëritet.

Për shembull, në një dyqan të tregtisë elektronike, ai mund të haset me atë të 2 milion produkteve, shumicën e kohës njerëzit janë të interesuar për ato që janë furnizuar me njolla të reja, brenda një diapazoni të caktuar çmimesh, dhe për një grupmoshë të veçantë. Kërkimi i bazës së të dhënave për këtë informacion është i kotë – pasi kërkesa nuk ndryshon shpesh, është më mirë t’i ruajmë këto rezultate diku në të cilat mund t’i qasemi shpejt.

Laravel ka një mbështetje të integruar për disa lloje të caching. Përveç përdorimit të një shofer rezervimi dhe ndërtimin e sistemit të ruajtjes nga toka lart, mund të dëshironi të përdorni disa pako Laravel që lehtësojnë caching model, caching query, etj.

Por vini re se përtej një rasti të caktuar të thjeshtuar të përdorimit, paketat e paracaktuara të ruajtjes mund të shkaktojnë më shumë probleme sesa ato zgjidhin.

Preferoni caching të memorjes

Kur ruani diçka në Laravel, ju keni disa opsione se ku mund të ruani llogaritjen e rezultuar që duhet të ruhet. Këto opsione njihen gjithashtu si drejtuesit e cache. Pra, megjithëse është e mundur dhe krejtësisht e arsyeshme të përdoret sistemi i skedarëve për ruajtjen e rezultateve në cache, nuk është me të vërtetë ajo që synimi i fshehjes është menduar të jetë.

Në mënyrë ideale, ju dëshironi të përdorni një memorie memorie (që jeton në RAM plotësisht) si Redis, Memcached, MongoDB, etj., Në mënyrë që nën ngarkesa më të larta, caching të shërbejë për një përdorim jetësor në vend se të bëhet shndërrim në vetvete.

Tani, mund të mendoni se të kesh një disk SSD është pothuajse e njëjtë me përdorimin e një shkop RAM, por nuk është as afër. Edhe joformale standardet tregojnë se RAM e tejkalon SSD me 10-20 herë kur bëhet fjalë për shpejtësinë.

Sistemi im i preferuar kur bëhet fjalë për caching është Redis. është qesharake shpejt (100,000 operacione për lexim në sekondë janë të zakonshme), dhe për sistemet shumë të mëdha të cache, mund të evoluohen në një grumbull lehtë.

Rezervoni rrugët

Ashtu si konfigurimi i aplikacionit, rrugët nuk ndryshojnë shumë me kalimin e kohës dhe janë një kandidat ideal për ruajtje. Kjo është veçanërisht e vërtetë nëse nuk mund të qëndroni në skedarë të mëdhenj si unë dhe përfundoni duke ndarë web.php dhe api.php tuaj për disa skedarë. Një komandë e vetme Laravel paketon të gjitha rrugët në dispozicion dhe i mban ata të dobishëm për qasje në të ardhmen:

rruga artizanale php: cache

Dhe kur përfundoni duke shtuar ose ndryshuar rrugë, thjesht bëni:

rruga artizanale php: e qartë

Optimizimi i figurës dhe CDN

Imazhet janë zemra dhe shpirti i shumicës së aplikacioneve në Internet. Rastësisht, ata janë gjithashtu konsumatorët më të mëdhenj të brezit dhe një nga arsyet më të mëdha për aplikacione / faqe të ngadalta. Nëse thjesht i ruani imazhet e ngarkuara në mënyrë naive në server dhe i dërgoni ato në përgjigje HTTP, do të lejoni që një mundësi masive optimizimi të kalojë nga.

Rekomandimi im i parë është që të mos i ruani imazhet në vend – ekziston problemi i humbjes së të dhënave, dhe varësisht se në cilin rajon gjeografik është klienti juaj, transferimi i të dhënave mund të jetë i ngadalshëm.

Në vend të kësaj, shkoni për një zgjidhje si Cloudinary që automatikisht ndryshon madhësinë dhe optimizon imazhet në fluturim.

Nëse nuk është e mundur, përdorni diçka si Cloudflare për të ruajtur dhe shërbyer imazhe ndërsa ato janë ruajtur në serverin tuaj.

Dhe nëse edhe kjo nuk është e mundur, ndryshimi i softuerit të serverit tuaj të internetit pak për të kompresuar pasuritë dhe drejtuar shfletuesin e vizitorit për t’i fshehur gjërat, bën shumë ndryshime. Ja se si do të duket një pjesë e konfigurimit e Nginx:

serveri {

# skedar i cunguar

Parametrat e ngjeshjes # gzip
gzip në;
gzip_comp_level 5;
gzip_min_l gjatësi 256;
gzip_proxied ndonjë;
gzip_vary në;

# kontrolli i cache të shfletuesit
vendndodhja ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $
skadon 1d;
akses_logjik;
add_header Pragma publik;
add_header Cache-Control "publik, max-mosha = 86400";
}
}

Unë jam i vetëdijshëm që optimizimi i imazhit nuk ka asnjë lidhje me Laravel, por është një mashtrim kaq i thjeshtë dhe i fuqishëm (dhe shpesh është lënë pas dore) që nuk mund ta ndihmoj veten time.

Optimizimi i autoloaderit

Autoloading është një tipar i zoti, jo aq i vjetër në PHP që me siguri e shpëtoi gjuhën nga dënimi. Thënë kjo, procesi i gjetjes dhe ngarkimit të klasës përkatëse duke deshifruar një varg hapësirë ​​të caktuar emrash kërkon kohë dhe mund të shmanget në vendosjet e prodhimit, ku performanca e lartë është e dëshirueshme. Edhe një herë, Laravel ka një zgjidhje me një komandë të vetme për këtë:

kompozitor instaloj –optimize-autoloader –no-dev

Bëni miq me radhë

Radhët jeni se si i përpunoni gjërat kur ka shumë prej tyre, dhe secilit prej tyre merr disa milisekonda për t’i përfunduar. Një shembull i mirë është dërgimi i postave elektronike – një rast i përhapur i përdorimit në aplikacionet në internet është të shfletoni disa email njoftimesh kur një përdorues kryen disa veprime.

Për shembull, në një produkt të sapo lançuar, ju mund të dëshironi që udhëheqësia e kompanisë (rreth 6-7 adresat e-mail) të njoftohet sa herë që dikush vendos një porosi mbi një vlerë të caktuar. Duke supozuar se porta juaj e postës elektronike mund t’i përgjigjet kërkesës suaj SMTP në 500ms, ne po flasim për një pritje të mirë 3-4 sekondë për përdoruesin përpara se të fillojë konfirmimi i porosisë. Një pjesë e vërtetë e keqe e UX, jam i sigurt se do të bie dakord.

Ilaçi është që të ruani punët kur hyjnë, t’i tregoni përdoruesit që gjithçka shkoi mirë, dhe t’i përpunojë ato (disa sekonda) më vonë. Nëse ka ndonjë gabim, punët në radhë mund të rivotohen disa herë para se të deklarohen se kanë dështuar.

Kredite: Microsoft.com

Ndërsa një sistem i radhitjes komplikon pak konfigurimin (dhe shton disa monitorime të sipërme), është i domosdoshëm në një aplikim modern në internet.

Optimizimi i pasurisë (Laravel Mix)

Për çdo pasuri të përparme në aplikacionin tuaj Laravel, ju lutemi sigurohuni që të ketë një tubacion që përpilon dhe minifikon të gjithë skedarët e pasurive. Ata që janë të kënaqur me një sistem bundler si Webpack, Gulp, Parcel, etj., Nuk kanë nevojë të shqetësojnë, por nëse nuk po e bëni këtë tashmë, Mix Laravel është një rekomandim i fortë.

Mix është një mbështjellës i lehtë (dhe i lezetshëm, me gjithë ndershmëri!) Rreth Webpack i cili kujdeset për të gjitha skedarët tuaj CSS, SASS, JS, etj. Një skedar tipik .mix.js mund të jetë aq i vogël sa kjo dhe akoma mrekulli që funksionojnë:

const mix = kërko (‘larvel-mix’);

mix.js (‘burime / js / app.js’, ‘publike / js’)
.sass (‘burime / sass / app.scss’, ‘publike / css’);

Kjo automatikisht kujdeset për importet, minifikimin, optimizimin dhe tërë shebangun kur jeni gati për prodhim dhe drejtoni npm prodhim të drejtuar. Mix kujdeset për jo vetëm skedarët tradicionale JS dhe CSS, por edhe komponentët Vue dhe React që mund të keni në rrjedhën e punës tuaj të aplikacionit.

Me shume informacion këtu!

përfundim

Optimizimi i performancës është më shumë art sesa shkencë – të dish se si dhe sa për të bërë është e rëndësishme sesa të bësh. Thënë kjo, nuk ka fund sesa dhe çfarë mund të zgjedhësh në një aplikacion Laravel.

Por çfarëdo që të bësh, do të doja të të lë me disa këshilla për ndarje – optimizimi duhet të bëhet kur ekziston një arsye e fortë, dhe jo sepse tingëllon mirë ose sepse je paranojak për performancën e aplikacionit për 100,000+ përdorues ndërsa në realitet ka vetëm 10.

Nëse nuk jeni të sigurt nëse duhet të zgjedhni ose jo aplikacionin tuaj, nuk keni nevojë të goditni folenë e brirëve proverbial. Një aplikacion pune që ndjehet i mërzitshëm, por bën pikërisht atë që duhet të jetë dhjetë herë më i dëshirueshëm sesa një aplikacion që është optimizuar në një supermachine hibride mutante, por bie sheshtë tani dhe më pas.

Dhe, që newbiew të bëhet një mjeshtër Laravel, shikoni këtë kurs online.

Maj aplikacionet tuaja shumë më shpejt! ��

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