Hoe kan ek PHP Laravel-webtoepassing optimaliseer vir hoë werkverrigting?

Laravel is baie dinge. Maar vinnig is nie een daarvan nie. Kom ons leer ‘n paar truuks van die handel om dit vinniger te laat verloop!


Geen PHP-ontwikkelaar is onaangeraak deur nie Laravel deesdae. Hulle is óf ‘n junior óf middelvlakontwikkelaar wat hou van die vinnige ontwikkeling wat Laravel bied, óf hulle is ‘n senior ontwikkelaar wat gedwing word om Laravel te leer weens die druk van die mark.

Hoe dan ook, daar is geen sprake van ontkenning dat Laravel die PHP-ekosisteem laat herleef het nie (ek sou die PHP-wêreld lank gelede verlaat het as Laravel nie daar was nie).

‘N Stukkie (ietwat geregverdigde) selfprys van Laravel

Aangesien Laravel egter agteroor buig om dinge vir jou maklik te maak, beteken dit dat daar onderin tonne werk gedoen word om seker te maak dat jy ‘n ontwikkelaar het. Al die “magiese” kenmerke van Laravel wat lyk asof dit werk, bevat lae op lae kodes wat elke keer as ‘n funksie gebruik word, opgesweep moet word. Selfs ‘n eenvoudige uitsondering kan sien hoe diep die konyngat is (let op waar die fout begin, tot by die kern):

Vir wat in een van die sienings ‘n samestellingsfout lyk, is daar 18 funksionele oproepe om op te spoor. Ek het persoonlik 40 gekry, en daar kan maklik meer wees as u ander biblioteke en inproppe gebruik.

Die feit dat Laravel traag is om hierdie lae op kode-kode standaard te plaas.

Hoe stadig is Laravel?

Dit is eerlik, om verskillende redes is dit onmoontlik om hierdie vraag te beantwoord.

eerste, daar is geen aanvaarde, objektiewe, verstandige standaard vir die meting van die spoed van webprogramme nie. Vinniger of stadiger in vergelyking met wat? Onder watter omstandighede?

tweede, ‘n Web-app is afhanklik van soveel dinge (databasis, lêerstelsel, netwerk, kas, ens.) dat dit dom is om oor spoed te praat. ‘N Baie vinnige webapp met ‘n baie stadige databasis is ‘n baie stadige webapp. ��

Maar hierdie onsekerheid is juis die rede waarom maatstawwe gewild is. Al beteken dit niks (sien hierdie en hierdie) bied hulle ‘n verwysingsraamwerk en help ons om mal te raak. Laat ons dus ‘n verkeerde, rowwe idee van spoed onder PHP-kaders kry, met verskeie knippies sout gereed.

Gaan deur hierdie redelik respekvolle GitHub bron, so vergelyk die PHP-raamwerke as dit vergelyk word:

U kan Laravel nie eens hier raaksien nie (selfs as u regtig hard slaan) tensy u u saak reg aan die einde van die stert gooi. Ja, liewe vriende, Laravel kom laaste! Nou, toegestaan, is die meeste van hierdie “raamwerke” nie baie prakties of selfs bruikbaar nie, maar dit vertel ons wel hoe traag Laravel is in vergelyking met ander meer gewilde rame.

Normaalweg funksioneer hierdie ‘traagheid’ nie in toepassings nie, omdat ons alledaagse webprogramme selde hoë getalle het. Maar sodra hulle dit doen (sê meer as 200-500 gelyktydig), begin die bedieners verstik en sterf. Dit is die tyd dat selfs die gebruik van meer hardeware by die probleem nie besnoei nie, en infrastruktuurrekenings klim so vinnig dat u hoë ideale vir wolkrekenaarstelsel neerstort.

Maar hey, hou op! Hierdie artikel handel nie oor wat nie gedoen kan word nie, maar oor wat gedoen kan word. ��

Goeie nuus is dat u baie kan doen om u Laravel-app vinniger te laat loop. Verskeie kere vinnig. Ja, geen grap nie. U kan dieselfde kodebasis laat ballisties bespaar en elke maand ‘n paar honderd dollar spaar op infrastruktuur- / hosting-rekeninge. Hoe? Laat ons daarby kom.

Vier tipes optimalisering

Na my mening kan optimalisering op vier verskillende vlakke gedoen word (dit wil sê vir PHP-toepassings):

  1. Taal-vlak: Dit beteken dat u ‘n vinniger weergawe van die taal gebruik en spesifieke koderingskenmerke / -style vermy in die taal wat u kode stadig maak.
  2. Raamwerk-vlak: Dit is die dinge wat ons in hierdie artikel bespreek.
  3. Infrastruktuur-vlak: Stel u PHP-prosesbestuurder, webbediener, databasis, ens. In.
  4. Hardeware-vlak: Gaan na ‘n beter, vinniger, kragtiger verskaffer van hardeware-gasheer.

Al hierdie soorte optimalisering het hul plek (byvoorbeeld, php-fpm-optimalisering is redelik krities en kragtig). Maar die fokus van hierdie artikel is die optimalisering van tipe 2: die wat verband hou met die raamwerk.

Terloops, daar is geen rasionaal agter die nommering nie, en dit is nie ‘n aanvaarde standaard nie. Ek het dit net opgemaak. Moet my asseblief nooit ooit kwoteer en sê: ‘Ons benodig tipe-3-optimalisering op ons bediener nie,’ anders sal u spanleier u doodmaak, my vind en my ook doodmaak. ��

En nou kom ons uiteindelik by die beloofde land aan.

Wees bewus van n + 1-databasisnavrae

Die n + 1-navraagprobleem is algemeen wanneer ORM’s gebruik word. Laravel het sy kragtige ORM genaamd Eloquent, wat so mooi, so gerieflik is dat ons dikwels vergeet om te kyk na wat aangaan.

Oorweeg ‘n baie algemene scenario: vertoon die lys van alle bestellings wat deur ‘n gegewe lys van kliënte geplaas word. Dit is redelik algemeen in e-handelsstelsels en in alle rapporteringsinterfaces in die algemeen waar ons alle entiteite wat met sommige entiteite verband hou, moet vertoon..

Ons kan ons in Laravel dink aan ‘n beheerfunksie wat die werk soos volg doen:

klasbestellingsbeheerder brei die beheerder uit
{
// …

openbare funksie getAllByCustomers ($ versoek aanvra, reeks $ id’s) {
$ klante = kliënt :: vind baie ($ id’s);
$ bestellings = versamel (); // nuwe versameling

foreach ($ kliënte as $ klant) {
$ bestellings = $ bestellings->merge ($ kliënt->bestellings);
}

return view (‘admin.reports.orders’, [‘orders’ => $ Bestellings]);
}
}

Sweet! En belangriker, elegant, mooi. ����

Ongelukkig is dit ‘n rampspoedige manier om kode in Laravel te skryf.

Hier is die rede.

As ons die ORM vra om na die gegewe kliënte te soek, word ‘n SQL-navraag soos hierdie gegenereer:

KIES * UIT Kliënte waar hulle in (22, 45, 34,…) Is;

Dit is presies soos verwag. As gevolg hiervan, word al die teruggekeerde rye in die versameling $ -kliënte in die beheerfunksie gestoor.

Nou gaan ons elke kliënt een vir een oor en kry hul bestellings. Dit voer die volgende navraag uit . . .

KIES * UIT bestellings WAAR customer_id = 22;

. . . soveel keer as wat daar kliënte is.

Met ander woorde, as ons die bestellingsdata vir 1000 klante moet kry, is die totale aantal databasisnavrae 1 (om alle klante se data te gaan haal) + 1000 (om bestellingsdata vir elke kliënt te haal) = 1001. Dit is waar die naam n + 1 vandaan kom.

Kan ons beter doen? Beslis! Deur die sogenaamde gretige laai te gebruik, kan ons die ORM dwing om ‘n AANSLUITING uit te voer en al die nodige data in ‘n enkele navraag terug te besorg! Soos hierdie:

$ bestellings = kliënt :: findMany ($ ids)->met ( ‘bevele’)->kry ();

Die resulterende datastruktuur is wel ‘n geneste, maar die bestellingsdata kan maklik onttrek word. Die gevolglike enkele navraag is in hierdie geval so:

KIES * UIT Kliënte BINNENOEPTE bestellings OP klante.id = bestellings.Kliënt_ WAAR klante.ID IN (22, 45,…);

‘N Enkele navraag is natuurlik beter as duisend ekstra vrae. Stel jou voor wat sou gebeur as daar 10.000 kliënte sou wees om te verwerk! Of, verbied God as ons ook die artikels in elke volgorde wil vertoon! Onthou, die naam van die tegniek is gretig om te laai, en dit is byna altyd ‘n goeie idee.

Cache die konfigurasie!

Een van die redes vir Laravel se buigsaamheid is die tonne konfigurasielêers wat deel uitmaak van die raamwerk. Wil u verander hoe / waar die beelde gestoor word?

Wel, verander net die config / filesystems.php-lêer (ten minste vanaf skryf). Wil u met meerdere toubestuurders werk? Beskryf dit gerus in config / queue.php. Ek het net getel en gevind dat daar 13 konfigurasielêers vir verskillende aspekte van die raamwerk is, wat verseker dat u nie teleurgesteld sal raak nie, maak nie saak wat u wil verander nie.

Gegewe die aard van PHP, word Laravel elke keer as ‘n nuwe webversoek inkom, wakker, begin alles op, en ontleed al hierdie konfigurasielêers om uit te vind hoe om hierdie keer dinge anders te doen. Behalwe dat dit dom is as niks die afgelope paar dae verander het nie! Die herbou van die konfigurasie op elke versoek is ‘n vermorsing wat (eintlik moet word) vermy word, en die uitweg is ‘n eenvoudige opdrag wat Laravel bied:

php ambagsman config: cache

Wat dit wel doen, is om die beskikbare config-lêers in ‘n enkele een te kombineer en die kas te plaas, is êrens om vinnig te herwin. Die volgende keer dat daar ‘n webversoek is, sal Laravel eenvoudig hierdie enkele lêer lees en aan die gang gaan.

Dit gesê, konfigurasie-cache is ‘n buitengewone delikate operasie wat in u gesig kan opblaas. Die grootste gotcha is dat sodra u hierdie opdrag uitgereik het, die env () -funksie van oral af oproep, behalwe dat die config-lêers null!

Dit maak sin as u daaraan dink. As u konfigurasie-cache gebruik, sê u die raamwerk: “Weet u wat, ek dink ek het dinge mooi opgestel en ek is 100% seker dat ek nie wil hê dat hulle moet verander nie.” Met ander woorde, u verwag dat die omgewing staties sal bly, en dit is waarvoor .env-lêers bedoel is.

Hiermee is ‘n paar ysterbeklede, heilige, onbreekbare reëls vir konfigurasiekas:

  1. Doen dit slegs op ‘n produksiestelsel.
  2. Doen dit slegs as u regtig, regtig seker is dat u die opset wil vries.
  3. As iets verkeerd gaan, moet u die instelling ongedaan maak met php artisan cache: duidelik
  4. Bid dat die skade wat die onderneming aangerig het, nie beduidend was nie!

Verminder outomaties gelaaide dienste

Om behulpsaam te wees, laai Laravel baie dienste as dit wakker word. Dit is beskikbaar in die config / app.php-lêer as deel van die skikkingsleutel ‘verskaffers’. Kom ons kyk wat ek in my geval het:

/ *
|————————————————————————–
| Autoloaded diensverskaffers
|————————————————————————–
|
| Die diensverskaffers wat hier gelys word, sal outomaties op die
| versoek om u aansoek. Voel vry om u eie dienste by te voeg
| hierdie skikking om uitgebreide funksionaliteit aan u toepassings toe te staan.
|
* /

‘aanbieders’ => [

/ *
* Verskaffers van Laravel-raamwerk…
* /
Verlig \ Auth \ AuthServiceProvider :: klas,
Verlig \ Broadcasting \ BroadcastServiceProvider :: klas,
Verlig \ Bus \ BusServiceProvider :: klas,
Verlig \ Cache \ CacheServiceProvider :: klas,
Verlig \ Foundation \ Verskaffers \ ConsoleSupportServiceProvider :: klas,
Verlig \ Cookie \ CookieServiceProvider :: klas,
Verlig \ Databasis \ DatabaseServiceProvider :: klas,
Verlig \ Encryption \ EncryptionServiceProvider :: klas,
Verlig \ lêerstelsel \ FilesystemServiceProvider :: klas,
Verlig \ Foundation \ Verskaffers \ FoundationServiceProvider :: klas,
Verlig \ Hashing \ HashServiceProvider :: klas,
Verlig \ Mail \ MailServiceProvider :: klas,
Verlig \ Kennisgewings \ NotificationServiceProvider :: klas,
Verlig \ Pagination \ PaginationServiceProvider :: klas,
Verlig \ pyplyn \ PipelineServiceProvider :: klas,
Verlig \ Queue \ QueueServiceProvider :: klas,
Verlig \ Redis \ RedisServiceProvider :: klas,
Verlig \ Auth \ wagwoorde \ PasswordResetServiceProvider :: klas,
Verlig \ Sessie \ SessionServiceProvider :: klas,
Verlig \ Vertaling \ TranslationServiceProvider :: klas,
Verlig \ Validation \ ValidationServiceProvider :: klas,
Verlig \ View \ ViewServiceProvider :: klas,

/ *
* Diensverskaffers van pakkette…
* /

/ *
* Verskaffers van toepassingsdienste…
* /
App \ Verskaffers \ AppServiceProvider :: klas,
App \ Verskaffers \ AuthServiceProvider :: klas,
// Program \ Aanbieders \ BroadcastServiceProvider :: klas,
App \ Verskaffers \ EventServiceProvider :: klas,
App \ Verskaffers \ RouteServiceProvider :: klas,

],

Ek het weer getel en daar is 27 dienste gelys! Nou, miskien het u hulle almal nodig, maar dit is onwaarskynlik.

Byvoorbeeld, ek is op die oomblik besig om ‘n REST-API te bou, wat beteken dat ek nie die sessie-diensverskaffer, ‘n diensverskaffer, ens. Nodig het nie. En omdat ek ‘n paar dinge op my manier doen en nie die standaard-raamwerk volg nie , Kan ek ook outentieke diensverskaffer, diensverskaffer vir paginering, diensverskaffer vir vertaaldienste, ensovoorts deaktiveer. Altesaam is byna die helfte hiervan nie nodig vir my gebruik nie.

Kyk mooi na u aansoek. Benodig dit al hierdie diensverskaffers? Maar om God se onthalwe, moet u asseblief nie hierdie dienste blindelings kommentaar lewer nie en na produksie stoot! Voer al die toetse uit, kyk dinge met die hand op toerusting en opstellingsmasjiene, en wees baie paranoïes voordat u die sneller trek. ��

Wees wys met middelware stapels

As u ‘n pasgemaakte verwerking van die inkomende webversoek benodig, is die skep van ‘n nuwe middelware die antwoord. Nou is dit aanloklik om app / Http / Kernel.php oop te maak en die middelware in die web of api-stapel te plak; op die manier, word dit regoor die app beskikbaar en as dit nie iets indringends doen nie (soos om aan te meld of kennis te gee, byvoorbeeld).

Namate die app egter groei, kan hierdie versameling wêreldwye middelware ‘n stil las op die app word as al (of meerderheid) hiervan in elke versoek teenwoordig is, selfs al is daar geen besigheidsredes daarvoor nie.

Met ander woorde, wees versigtig waar u ‘n nuwe middelware byvoeg / toepas. Dit kan geriefliker wees om iets wêreldwyd by te voeg, maar die prestasieboete is op die lange duur baie hoog. Ek weet die pyn wat u moet ondergaan as u middelware selektief sou toepas elke keer as daar ‘n nuwe verandering is, maar dit is ‘n pyn wat ek graag wil aanbeveel en aanbeveel!

Vermy die ORM (soms)

Terwyl Eloquent baie aspekte van DB-interaksie aangenaam maak, is dit ten koste van die snelheid. Aangesien dit ‘n kartering is, hoef die ORM nie net rekords uit die databasis te haal nie, maar ook die modelvoorwerpe onmiddellik te hidreer en dit met kolomdata te hidreer (vul dit in).

Dus, as u ‘n eenvoudige $ gebruikers doen = Gebruiker :: almal () en daar is, byvoorbeeld, 10.000 gebruikers, sal die raamwerk 10.000 rye uit die databasis haal en 10.000 nuwe gebruikers intern doen () en hul eiendomme met die toepaslike data invul. . Dit is groot hoeveelhede werk wat agter die skerms gedoen word, en as die databasis is waar u aansoek ‘n knelpunt word, is dit soms ‘n goeie idee om die ORM te omseil.

Dit geld veral vir komplekse SQL-navrae, waar u baie hoepels moet opspring en sluitings moet sluit tydens sluiting en steeds met ‘n doeltreffende navraag kan eindig. In sulke gevalle word ‘n DB :: raw () gedoen en die hand met die hand geskryf.

Verby hierdie prestasiestudie, selfs vir eenvoudige insetsels is Eloquent baie stadiger namate die aantal rekords styg:

Gebruik soveel as moontlik kas

Een van die bes bewaarde geheime van die optimalisering van die webtoepassing is cache.

Vir oningewydes beteken dit dat kasgeheue duur resultate bereken en berg (duur in terme van CPU en geheue gebruik), en dit eenvoudig terugstuur wanneer dieselfde navraag herhaal word.

Byvoorbeeld, in ‘n e-handelwinkel kan dit voorkom dat die 2 miljoen produkte meestal geïnteresseerd is in diegene wat vars voorraad het, binne ‘n sekere prysklas en vir ‘n spesifieke ouderdomsgroep. Die navraag van die databasis vir hierdie inligting is verkwistend – aangesien die navraag nie gereeld verander nie, is dit beter om hierdie resultate op te slaan waar ons vinnig toegang kan kry.

Laravel het ingeboude ondersteuning vir verskillende soorte caching. Benewens die gebruik van ‘n caching-bestuurder en die bou van die caching-stelsel van die grond af, wil jy dalk ‘n paar Laravel-pakkette gebruik wat dit vergemaklik model kas, navraag kas, ens.

Maar let op dat voorbehoefte-kaspakkette, bo ‘n sekere vereenvoudigde gebruiksgeval, meer probleme kan veroorsaak as wat hulle oplos.

Verkies caching in die geheue

As u iets in Laravel kasseer, het u verskillende opsies om die berekening wat u benodig, te stoor. Hierdie opsies staan ​​ook bekend as kasbestuurders. Dus, hoewel dit moontlik en heeltemal redelik is om die lêerstelsel te gebruik om kasresultate te stoor, is dit nie regtig wat caching bedoel is nie.

Ideaal gesproke wil u ‘n geheue-geheue (geheel en al in die RAM-geheue) gebruik, soos Redis, Memcached, MongoDB, ens., Sodat caching ‘n noodsaaklike gebruik maak as om ‘n bottelnek te word..

Nou, miskien sou u dink dat ‘n SSD-skyf amper dieselfde is as om ‘n RAM-stok te gebruik, maar dit is nie eens naby nie. Selfs informeel maatstawwe toon aan dat RAM 10-20 keer beter is as die snelheid.

My gunsteling stelsel as dit kom by kas, is Redis. Dis belaglik vinnig (100,000 leesbewerkings per sekonde kom gereeld voor), en vir baie groot kasstelsels kan dit ontwikkel word tot ‘n cluster maklik.

Cache die roetes

Net soos met die programkonfigurasie, verander die roetes nie mettertyd nie en is dit ‘n ideale kandidaat om te kas. Dit is veral waar as u nie groot lêers soos ek kan staan ​​nie en uiteindelik u web.php en api.php oor verskillende lêers kan verdeel. ‘N Enkele Laravel-opdrag pak al die beskikbare roetes saam en hou dit byderhand vir toekomstige toegang:

php ambagsmanroete: cache

En as u eindelik roetes byvoeg of verander, doen dit net:

php ambagsmanroete: duidelik

Beeldoptimalisering en CDN

Beelde is die hart-en-siel van die meeste webtoepassings. Toevallig is hulle ook die grootste verbruiker van bandwydte en een van die grootste redes vir stadige programme / webwerwe. As u die opgelaaide prente eenvoudig naïef op die bediener stoor en terugstuur in HTTP-antwoorde, laat u ‘n massiewe optimaliseringsgeleentheid verby.

My eerste aanbeveling is om nie prente plaaslik te stoor nie – daar is die probleem met verlies van data om mee te werk, en afhangende van watter geografiese streek u kliënt is, kan data-oordrag pynlik stadig wees.

Gaan liewer na ‘n oplossing soos Cloudinary wat prente vinnig verander en optimaliseer.

As dit nie moontlik is nie, gebruik iets soos Cloudflare om foto’s te stoor en te bedien terwyl dit op u bediener gestoor word.

En selfs al is dit nie moontlik nie, maak dit ‘n groot verskil aan u webbediener-sagteware om die bates saam te druk en die besoeker se blaaier op dinge te laat strook. So sal ‘n stuk Nginx-opset lyk:

bediener {

# lêer afgekap

# gzip-kompressie-instellings
gzip aan;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied enige;
gzip_vary aan;

# blaaiergeheue beheer
ligging ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
verval 1d;
toegang_log af;
add_header Pragma publiek;
add_header Cache-Control "publiek, maksimum ouderdom = 86400";
}
}

Ek is bewus daarvan dat beeldoptimalisering niks met Laravel te doen het nie, maar dit is so ‘n eenvoudige en kragtige truuk (en word so gereeld verwaarloos) wat myself nie kan help nie.

Outoloader-optimalisering

Autoloading is ‘n netjiese, nie-so-ou funksie in PHP wat die taal waarskynlik van ondergang gered het. Dit gesê, die proses om die betrokke klas te vind en te laai deur ‘n gegewe naamruimtesnare te ontsyfer, neem tyd en kan vermy word in produksie-ontplooiings waar hoë werkverrigting wenslik is. Weereens het Laravel ‘n oplossing met ‘n enkele opdrag hiervoor:

komponis installeer – optimize-autoloader –no-dev

Maak vriende met toue

toue is hoe u dinge verwerk as daar baie van hulle is, en elkeen neem ‘n paar millisekondes om te voltooi. ‘N Goeie voorbeeld is om e-pos te stuur – ‘n algemene gebruik in webapps is om ‘n paar kennisgewings-e-posse af te skiet wanneer ‘n gebruiker aksies uitvoer.

Byvoorbeeld, in ‘n nuut-bekendgestelde produk, wil u hê dat die leierskap van die onderneming (ongeveer 6-7 e-posadresse) in kennis gestel moet word wanneer iemand ‘n bestelling bo ‘n sekere waarde plaas. As ons aanvaar dat u e-poshek op 500 m kan reageer op u SMTP-versoek, praat ons van ‘n goeie 3-4 sekondes-wag vir die gebruiker voordat die bestelbevestiging inskop. ‘N Slegte UX-stuk, ek is seker dat u stem.

Die oplossing is om bane te stoor wanneer hulle binnekom, die gebruiker te kenne gee dat alles goed verloop en dit (enkele sekondes) later verwerk. As daar ‘n fout is, kan die werkgeleenthede ‘n paar keer herprobeer word voordat dit verklaar word dat hulle misluk het.

Krediete: Microsoft.com

Terwyl ‘n toustelsel die opstelling ‘n bietjie bemoeilik (en ‘n bietjie toesighouding bykom), is dit onontbeerlik in ‘n moderne webtoepassing.

Bateoptimalisering (Laravel Mix)

Maak seker dat daar ‘n portefeulje is wat al die bate lêers saamstel en verkleineer. Diegene wat gemaklik is met ‘n bundelstelsel soos Webpack, Gulp, Pakket, ens., Hoef nie die moeite te doen nie, maar as u dit nog nie doen nie, Laravel Mix is ‘n goeie aanbeveling.

Mix is ​​’n liggewig (en in alle eerlikheid!) Omhulsel rondom Webpack wat sorg vir al u CSS-, SASS-, JS-, ens. Lêers vir produksie. ‘N Tipiese .mix.js-lêer kan so klein soos hierdie wees en werk nog steeds wonders:

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

mix.js (‘resources / js / app.js’, ‘public / js’)
.sass (‘resources / sass / app.scss’, ‘publiek / css’);

Dit sorg outomaties vir invoer, minifisering, optimalisering en die hele rommelstelsel wanneer u gereed is vir produksie en die produksie van npm-loop. Mix sorg nie net vir tradisionele JS- en CSS-lêers nie, maar ook vir Vue en React-komponente wat u in u toepassingsvloei het..

Meer inligting hier!

Afsluiting

Prestasieoptimalisering is meer kuns as wetenskap – om te weet hoe en wat om te doen is belangriker as wat om te doen. Dit gesê, daar is geen einde aan hoeveel en wat u alles in ‘n Laravel-program kan optimaliseer nie.

Maar wat u ook al doen, ek wil u met ‘n paar raad oor afskeid gee: optimering moet gedoen word as daar ‘n goeie rede is, en nie omdat dit goed klink nie, of omdat u paranoïes is oor die programprestasie vir meer as 100.000 gebruikers terwyl u in werklikheid is daar is net tien.

As u nie seker is of u u app moet optimaliseer of nie, hoef u nie die spreekwoordelike nes te skop nie. ‘N Werkende app wat vervelig voel, maar presies doen wat dit moet, is tien keer meer wenslik as ‘n app wat in ‘n mutante baster-supermasjien geoptimaliseer is, maar nou en dan plat val.

En as u ‘n Laravel-meester wil sien, moet u dit sien aanlyn kursus.

Mag u programme baie, baie vinniger loop! ��

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