Kako optimizirati spletno aplikacijo PHP Laravel za visoko zmogljivost?

Laravel je veliko stvari. Toda hitra ni ena izmed njih. Naučimo se nekaj trikov trgovine, da bi lahko hitreje šli!


Nobenega razvijalca PHP ne dotika Laravel v teh dneh. Ali so razvijalci za mlajše ali srednje ravni, ki imajo radi hiter razvoj, ki ga ponuja Laravel, ali pa so višji razvijalci, ki se bodo zaradi pritiskov na trgu prisiljeni učiti Laravel.

Kakor koli že, ne zanikamo, da je Laravel oživil ekosistem PHP (zagotovo bi že zdavnaj zapustil svet PHP, če Laravel ne bi bil tam).

Odlomek (nekoliko upravičeno) samohvale Laravela

Ker pa se Laravel upogne nazaj, da vam olajša stvari, to pomeni, da pod njim počnete na tone in tone dela, da boste poskrbeli za prijetno življenje razvijalca. Vse “čarobne” lastnosti Laravela, ki samo na videz delujejo, imajo plasti na plasteh kode, ki jih je treba povleciti ob vsaki funkciji. Celo preprost izvleček izsledka, kako globoka je zajčja luknja (opazite, kje se napaka začne, vse do glavnega jedra):

Ker se zdi, da je napaka pri sestavljanju v enem od pogledov, je 18 funkcijskih klicev za sledenje. Osebno sem naletel na 40 in lahko bi bilo enostavno več, če uporabljate druge knjižnice in vtičnike.

Glede na to, da so privzeto te plasti na plasteh kode, Laravel počasen.

Kako počasen je Laravel?

Iskreno, na to vprašanje ni mogoče odgovoriti iz več razlogov.

Najprej, ni nobenega sprejetega, objektivnega in smiselnega standarda za merjenje hitrosti spletnih aplikacij. Hitrejše ali počasnejše v primerjavi s kaj? Pod kakšnimi pogoji?

Drugič, spletna aplikacija je odvisna od toliko stvari (zbirka podatkov, datotečni sistem, omrežje, predpomnilnik itd.), da je preprosto neumno govoriti o hitrosti. Zelo hitra spletna aplikacija z zelo počasno bazo podatkov je zelo počasna spletna aplikacija. ��

Toda prav ta negotovost je ravno razlog, zakaj so merila priljubljena. Čeprav ne pomenijo nič (glej to in to), nudijo nekaj referenčnega okvira in nam pomagajo, da se razjezimo. Zato z nekaj ščepci soli pripravimo napačno, grobo predstavo o hitrosti med okviri PHP.

Mimo tega dokaj uglednega GitHub-a vir, tukaj je opisano, kako se okviri PHP postavljajo v primerjavi:

Tu morda ne boste opazili niti Laravela (četudi resnično trhtiš), če svojega primera ne spustiš do konca repa. Ja, dragi prijatelji, Laravel je zadnji! Zdaj, seveda, večina teh “okvirov” ni zelo praktična ali celo uporabna, vendar nam pove, kako počasen je Laravel v primerjavi z drugimi bolj priljubljenimi.

Običajno ta „počasnost“ ni značilna za aplikacije, ker naše vsakdanje spletne aplikacije redko dosegajo veliko število. Ko pa to storijo (recimo več kot 200-500 sočasnosti), se strežniki začnejo zadušiti in umreti. Čas je, da tudi pri metanju večje strojne opreme težava ne reši in računi za infrastrukturo naraščajo tako hitro, da se vaši visoki ideali računalništva v oblaku zrušijo.

Ampak hej, razveselite se! Ta članek ne govori o tem, kaj ni mogoče storiti, ampak o tem, kaj je mogoče storiti. ��

Dobra novica je, da lahko veliko naredite, da bo aplikacija Laravel hitrejša. Nekajkrat hitro. Da, ne šalite se. Ista koda lahko postane balistična in vsak mesec prihranite nekaj sto dolarjev za račune za infrastrukturo / gostovanje. Kako? Pojdimo do tega.

Štiri vrste optimizacij

Po mojem mnenju je mogoče optimizacijo narediti na štirih različnih nivojih (ko gre za aplikacije PHP, torej):

  1. Jezikovna raven: To pomeni, da uporabljate hitrejšo različico jezika in se izogibate določenim značilnostim / slogom kodiranja v jeziku, zaradi katerih je vaša koda počasna.
  2. Okvirna raven: To so stvari, ki jih bomo obravnavali v tem članku.
  3. Raven infrastrukture: Uglaševanje upravitelja procesov PHP, spletnega strežnika, baze podatkov itd.
  4. Raven strojne opreme: Premik k boljšemu, hitrejšemu in zmogljivejšemu ponudniku gostovanja strojne opreme.

Vse te vrste optimizacij imajo svoje mesto (na primer, php-fpm optimizacija je precej kritična in močna). Toda poudarek tega članka bo optimizacija izključno tipa 2: tiste, povezane z ogrodjem.

Mimogrede, ne obstaja nobena utemeljitev številčenja in to ni sprejet standard. Pravkar sem jih izmislil. Nikoli me ne citirajte in ne recite: “Potrebujemo optimizacijo tipa 3 na našem strežniku”, ali vas bo vodstvo ekipe ubilo, našli in ubili tudi mene. ��

In zdaj končno pridemo do obljubljene dežele.

Bodite pozorni na n + 1 poizvedbe po bazi podatkov

Težava s poizvedbami n + 1 je pogosta, ko se uporabljajo ORM-ji. Laravel ima svoj močan ORM z imenom Eloquent, ki je tako lep, tako priročen, da pogosto pozabimo pogledati, kaj se dogaja.

Razmislite o zelo pogostem scenariju: prikaz seznama vseh naročil na določenem seznamu strank. To je precej pogosto v sistemih e-trgovine in na splošno vmesnikov za poročanje, kjer moramo prikazati vse subjekte, povezane z nekaterimi entitetami.

V Laravelu si lahko predstavljamo funkcijo krmilnika, ki opravi takole:

razreda OrdersController razširja Controller
{
// …

javna funkcija getAllByCustomers (Zahtevaj $ zahtevo, array $ ids) {
$ strank = stranka: findMany ($ ids);
$ naročil = zbirati (); // nova zbirka

foreach ($ odjemalci kot $ kupec) {
$ naročil = $ naročil->združitev ($ stranka->naročila);
}

povratni pogled (‘admin.reports.orders’, [‘order’ =)> $ naročila]);
}
}

Sladko! In še pomembneje, elegantno, lepo. ����

Žal je pisanje kode v Laravel katastrofalno.

Tukaj je razlog.

Ko od ORM-a zahtevamo, da poišče stranke, se poizvede SQL, kot je ta:

IZBERI * OD kupcev, KJER ID IN (22, 45, 34,.);

Kar je točno po pričakovanjih. Posledično se vse vrnjene vrstice shranijo v zbirko $ odjemalcev znotraj funkcije regulatorja.

Zdaj vsakega kupca preusmerimo po enega in dobimo njihova naročila. To izvede naslednjo poizvedbo . . .

IZBERI * IZ naročil, KJE je stranka_id = 22;

. . . tolikokrat, kolikor je kupcev.

Z drugimi besedami, če moramo pridobiti podatke o naročilu za 1000 strank, bo skupno število izvedenih poizvedb v bazi 1 (za pridobivanje vseh podatkov strank) + 1000 (za pridobivanje podatkov o naročilu za vsako stranko) = 1001. To od kod izvira ime n + 1.

Ali lahko naredimo bolje? Zagotovo! Z uporabo tako imenovanega nestrpnega nalaganja lahko ORM prisili, da izvede PRIDRUŽITEV in vrne vse potrebne podatke v eni poizvedbi! Všečkaj to:

$ order = Stranka :: findMany ($ ids)->z (‘naročila’)->get ();

Nastala struktura podatkov je zagotovo ugnezdena, vendar je podatke o naročilu enostavno pridobiti. V tem primeru je ena sama poizvedba takšna:

IZBERI * OD kupcev INNER JOIN naročil ON customers.id = order.customer_id WHERE customers.id IN (22, 45,.);

Ena sama poizvedba je seveda boljša od tisoč dodatnih poizvedb. Predstavljajte si, kaj bi se zgodilo, če bi bilo na predelavo 10.000 strank! Ali bog ne daj, če smo tudi želeli prikazati izdelke, ki jih vsebuje vsako naročilo! Ne pozabite, da se ime tehnike nenehno nalaga in je skoraj vedno dobra ideja.

Predpomni konfiguracijo!

Eden od razlogov za Laravelovo fleksibilnost so številne konfiguracijske datoteke, ki so del ogrodja. Želite spremeniti, kako / kje so slike shranjene?

No, samo spremenite datoteko config / filesystems.php (vsaj med pisanjem). Želite sodelovati z več gonilniki čakalnih vrst? Lahko jih opišete v config / queue.php. Pravkar sem preštela in ugotovila, da obstaja 13 konfiguracijskih datotek za različne vidike okvira, s čimer zagotavljam, da ne boste razočarani, ne glede na to, kaj želite spremeniti.

Glede na naravo PHP-ja se Laravel vsakič, ko pride nova spletna zahteva, zbudi, zažene vse in razčleni vse te konfiguracijske datoteke, da ugotovi, kako to drugače početi. Razen, da je neumno, če se v zadnjih dneh ni nič spremenilo! Obnova konfigura pri vsaki zahtevi je izguba, ki se ji je (pravzaprav je treba) izogniti, izhod pa je preprost ukaz, ki ga ponuja Laravel:

php artisan config: predpomnilnik

To je združiti vse razpoložljive konfiguracijske datoteke v eno samo, predpomnilnik pa je nekje za hitro iskanje. Ko bo spletna zahteva naslednjič, bo Laravel preprosto prebral to eno datoteko in začel delovati.

Kljub temu je konfiguracijsko predpomnjenje izjemno občutljiva operacija, ki vam lahko piha v obraz. Največji problem je, da ko enkrat izdate ta ukaz, funkcija env () pokliče od koder koli, razen konfiguracijskih datotek, se vrne v nulo!

Smiselno je, ko razmišljate o tem. Če uporabljate predpomnilniško konfiguracijo, si okvirju rečete: “Veste kaj, mislim, da sem lepo uredil stvari in sem 100% prepričan, da jih ne želim spremeniti.” Z drugimi besedami, pričakujete, da bo okolje ostalo statično, za kar so .env datoteke.

Glede na to je tu nekaj svetih, svetih in neprekosljivih pravil konfiguracijskega predpomnjenja:

  1. Naredite to le v proizvodnem sistemu.
  2. To storite le, če ste resnično zelo prepričani, da želite zamrzniti konfiguracijo.
  3. Če gre kaj narobe, razveljavite nastavitev s predpomnilnikom php artisan: clear
  4. Prosite, da škoda, storjena podjetju, ni bila pomembna!

Zmanjšajte samodejno naložene storitve

Laravel si pomaga, ko se zbudi. Ti so na voljo v datoteki config / app.php kot del matrične tipke ‘ponudniki’. Poglejmo, kaj imam v mojem primeru:

/ *
|————————————————————————–
| Samodejno naloženi ponudniki storitev
|————————————————————————–
|
| Tu navedeni ponudniki storitev bodo samodejno naloženi na
| prošnjo za prijavo. Če želite dodati svoje storitve
| ta niz za dodelitev razširjene funkcionalnosti vašim aplikacijam.
|
* /

‘ponudniki’ => [

/ *
* Ponudniki storitev Laravel Framework…
* /
Osvetlite \ Auth \ AuthServiceProvider :: razred,
Osvetlite \ oddajanje \ BroadcastServiceProvider :: razred,
Osvetlite \ Bus \ BusServiceProvider :: razred,
Osvetlite \ Cache \ CacheServiceProvider :: razred,
Osvetlite \ Fundacija \ Ponudniki \ ConsoleSupportServiceProvider :: class,
Osvetlite \ Piškotek \ CookieServiceProvider :: razred,
Osvetlite \ Baza podatkov \ DatabaseServiceProvider :: razred,
Osvetlite \ Šifriranje \ EncryptionServiceProvider :: razred,
Osvetlite \ Filesystem \ FilesystemServiceProvider :: class,
Osvetlite \ Fundacija \ Ponudniki \ FoundationServiceProvider :: razred,
Osvetlite \ Hashing \ HashServiceProvider :: razred,
Osvetlite \ Mail \ MailServiceProvider :: razred,
Osvetlite \ Obvestila \ NotificationServiceProvider :: razred,
Osvetli \ Paginacija \ PaginationServiceProvider :: razred,
Osvetli \ Cevovod \ PipelineServiceProvider :: razred,
Osvetli \ Queue \ QueueServiceProvider :: razred,
Osvetlite \ Redis \ RedisServiceProvider :: razred,
Osvetlite \ Auth \ Gesla \ PasswordResetServiceProvider :: class,
Osvetli \ sejo \ sejoServiceProvider :: razred,
Osvetli \ Prevajanje \ PrevajanjeServiceProvider :: razred,
Osvetlite \ Validation \ ValidationServiceProvider :: class,
Osvetlite \ Pogled \ ViewServiceProvider :: razred,

/ *
* Ponudniki paketnih storitev…
* /

/ *
* Ponudniki storitev aplikacij…
* /
App \ Ponudniki \ AppServiceProvider :: class,
Aplikacija \ Ponudniki \ AuthServiceProvider :: razred,
// Aplikacija \ Ponudniki \ BroadcastServiceProvider :: razred,
App \ Ponudniki \ EventServiceProvider :: class,
App \ Ponudniki \ RouteServiceProvider :: class,

],

Še enkrat sem štel in naštetih je 27 storitev! Zdaj jih boste morda potrebovali, vendar je malo verjetno.

Na primer, trenutno gradim API REST, kar pomeni, da ne potrebujem ponudnika storitev seje, ponudnika storitev itd. In ker nekaj stvari počnem po svoje in ne sledim privzetim okvirom , Lahko tudi onemogočim ponudnika avtentičnih storitev, ponudnika storitev paginacije, ponudnika prevajalskih storitev in tako naprej. Skupno je skoraj polovica teh nepotrebnih za moj primer uporabe.

Oglejte si svojo prošnjo dolgo in težko. Ali potrebuje vse te ponudnike storitev? Ampak za božjo voljo, prosimo, da teh storitev ne slepo komentirate in pojdite na proizvodnjo! Zaženite vse teste, ročno preverite stvari na napravah za razvijalce in uprizoritev ter bodite zelo paranoični, preden potegnete sprožilec. ��

Bodite pametni s sredstvi programske opreme

Ko potrebujete nekaj obdelave dohodne spletne zahteve po meri, je ustvarjanje nove vmesne programske opreme odgovor. Zdaj je skušnjava odpreti app / Http / Kernel.php in vstaviti vmesno programsko opremo v splet ali skladbo api; tako postane na voljo v aplikaciji in če ne počne kaj vsiljivega (na primer beleženje ali obveščanje).

Ko pa aplikacija raste, lahko ta zbirka globalne vmesne programske opreme postane tiho breme za aplikacijo, če so vsi (ali večina) teh prisotni v vsaki zahtevi, tudi če za to ni poslovnega razloga.

Z drugimi besedami, bodite previdni, kam dodate / uporabite novo vmesno programsko opremo. Primerneje je dodati nekaj po vsem svetu, vendar je kazen za delovanje na dolgi rok zelo visoka. Vem, da bi se morali spopadati, če bi selektivno uporabljali vmesni program vsakič, ko se bo pojavila nova sprememba, vendar je bolečina, ki bi jo rado sprejel in priporočil!

Izogibajte se ORM (na trenutke)

Čeprav je Eloquent številne vidike interakcije z DB prijetnimi, se to zgodi s ceno hitrosti. ORM-ov je kot zemljevidnik ne le, da pridobiva zapise iz baze podatkov, temveč tudi instancira objekte modela in jih hidrira (napolni) s podatki stolpcev..

Torej, če naredite preproste $ users = Uporabnik :: all () in je recimo 10.000 uporabnikov, bo okvir iz baze podatkov prestavil 10.000 vrstic, interno pa 10.000 novih Uporabnikov () in napolnil njihove lastnosti z ustreznimi podatki . To je ogromno dela, ki se opravlja v zakulisju, in če baza podatkov tam, kjer se prijavljate, postaja ozko grlo, je včasih obhod ORM dobra ideja..

To še posebej velja za zapletene poizvedbe SQL, pri katerih morate na koncu zapreti veliko obročkov in ob zaprtju napisati zapore in še vedno končati z učinkovito poizvedbo. V takšnih primerih je zaželeno narediti DB :: raw () in pisati poizvedbo ročno.

Mimo to študija uspešnosti, tudi za preproste vstavke Zgovorno je veliko počasneje, saj se število zapisov poveča:

Uporabite predpomnilnik čim več

Ena od najbolje ohranjenih skrivnosti optimizacije spletnih aplikacij je predpomnjenje.

Za neuveljavljeno predpomnjenje pomeni predhodno računanje in shranjevanje dragih rezultatov (dragih v smislu porabe CPU-ja in pomnilnika) in preprosto vračanje le-teh, ko se ista poizvedba ponovi.

Na primer, v trgovini za e-trgovino je mogoče naleteti na prodajo dveh milijonov izdelkov, večino časa pa ljudje zanimajo tiste, ki so na zalogi, v določenem cenovnem razredu in za določeno starostno skupino. Poizvedovanje po zbirki podatkov po teh podatkih je potratno – ker se poizvedba ne spreminja pogosto, je bolje, da te rezultate shranite nekje, do katerih lahko hitro dostopamo.

Laravel ima vgrajeno podporo za več vrst predpomnjenje. Poleg uporabe gonilnika za predpomnjenje in gradnje predpomnilnega sistema od spodaj navzgor, boste morda želeli uporabiti tudi nekaj paketov Laravel, ki olajšajo predpomnjenje modelov, predpomnilnik poizvedb, itd.

Upoštevajte pa, da lahko vnaprej izdelani predpomnilni paketi poleg določenih primerov poenostavljene uporabe povzročijo več težav, kot jih rešujejo.

Raje predpomnilnik v pomnilniku

Ko nekaj predpomnite v programu Laravel, imate več možnosti, kam shraniti rezultat, ki ga je treba predpomniti. Te možnosti so znane tudi kot gonilniki predpomnilnika. Čeprav je datotečni sistem mogoče in povsem smiselno uporabljati za shranjevanje rezultatov predpomnilnika, ni resnično, kaj naj bi predpomnilnik.

V idealnem primeru želite uporabiti predpomnilnik v pomnilniku (v celoti živi v RAM-u), kot so Redis, Memcached, MongoDB itd., Tako da predpomnilnik pri večjih obremenitvah služi vitalni rabi, ne pa da postane sam ozko grlo.

Zdaj bi si morda mislili, da je imeti SSD disk skoraj enako kot uporabljati pomnilniško kartico, vendar niti približno ni. Celo neformalno merila uspešnosti kažejo, da RAM po hitrosti prekaša SSD 10-20 krat.

Moj najljubši sistem pri predpomnjenju je Redis. Je smešno hitro (100.000 bralnih operacij na sekundo je običajno), pri zelo velikih predpomnilnih sistemih pa se lahko razvije v a grozd enostavno.

Predpomnite poti

Tako kot v konfiguraciji aplikacije se tudi poti sčasoma ne spreminjajo in so idealen kandidat za predpomnjenje. To še posebej velja, če ne prenesete velikih datotek, kot sem jaz, in na koncu delite web.php in api.php na več datotek. Z enim ukazom Laravel pakirate vse razpoložljive poti in jih naredite pri roki za prihodnji dostop

php obrtna pot: predpomnilnik

In ko dodate ali spremenite poti, preprosto naredite:

php obrtna pot: jasno

Optimizacija slike in CDN

Slike so srce in duša večine spletnih aplikacij. Po naključju so tudi največji porabniki pasovne širine in eden največjih razlogov za počasne aplikacije / spletna mesta. Če naložene slike preprosto shranite naivno na strežnik in jih pošljete nazaj v odzive HTTP, puščate množično priložnost za optimizacijo.

Moje prvo priporočilo je, da slik ne shranjujete lokalno – težava je izguba podatkov, s katero se morate spoprijeti, in odvisno od tega, v kateri geografski regiji je vaša stranka, je prenos podatkov lahko počasi počasen.

Namesto tega pojdite na rešitev, kot je Oblačno ki samodejno spreminja velikost slike in optimizira slike.

Če to ni mogoče, uporabite nekaj podobnega kot Cloudflare za predpomnjenje in prikazovanje slik, medtem ko so shranjene na vašem strežniku.

In tudi če to ni mogoče, je veliko razlike v nastavitvi programske opreme spletnega strežnika, da stisne sredstva in usmeri brskalnik obiskovalca, da predpomni stvari. Takole bo izgledal delček konfiguracije Nginx:

strežnik {

# datoteka okrnjena

# gzip nastavitve stiskanja
gzip naprej;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied kateri koli;
gzip_vary vklopljen;

# nadzor predpomnilnika brskalnika
lokacija ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
poteče 1d;
access_log izklopljen;
add_header Pragma javna;
add_header Cache-Control "javni, maks. starost = 86400";
}
}

Zavedam se, da optimizacija slike nima nobene povezave z Laravelom, vendar je tako preprost in močan trik (in je tako pogosto zanemarjen), da si ne bi mogel pomagati.

Optimizacija samodejnega nakladalca

Samodejno nalaganje je čedna, še ne stara funkcija v PHP-u, ki je jezik zagotovo rešila pred pogubo. Povedano je to, da postopek iskanja in nalaganja ustreznega razreda z dešifriranjem določenega niza imenskega prostora zahteva čas in se mu lahko izognemo v proizvodnih razmestitvah, kjer je zaželena visoka zmogljivost. Znova ima Laravel rešitev z enim ukazom za to:

skladateljeva namestitev –optimize-autoloader –no-dev

Spoprijatelji se s čakalnimi vrstami

Čakalne vrste kako obdelujete stvari, ko jih je veliko, in vsaka od njih traja nekaj milisekund. Dober primer je pošiljanje e-poštnih sporočil – zelo razširjena uporaba v spletnih aplikacijah je odstranjevanje nekaj e-poštnih sporočil, ko uporabnik izvede nekaj dejanj.

Na primer na novo predstavljenem izdelku boste morda želeli, da je vodstvo podjetja (približno 6-7 e-poštnih naslovov) obveščeno vsakič, ko nekdo odda naročilo nad določeno vrednostjo. Če predpostavimo, da bo vaš e-poštni prehod lahko odgovoril na vašo zahtevo SMTP v 500 ms, govorimo o dobrih 3-4 sekundah čakanja na uporabnika, preden začne potrditev naročila. Resnično slab kos UX-a, prepričan sem, da boste se strinjam.

Sredstvo je shranjevanje delovnih mest, ko pridejo, uporabniku sporočiti, da je šlo vse po redu, in ga obdelati (nekaj sekund) kasneje. Če pride do napake, lahko opravila iz čakalnih vrst vnovič poskusite znova, preden se razglasijo za neuspešna.

Zasluge: Microsoft.com

Čeprav čakalni sistem nekoliko oteži nastavitev (in doda nekaj nadzornega nadstropja), je v sodobni spletni aplikaciji nepogrešljiv.

Optimizacija premoženja (Laravel Mix)

Za vsa vhodna sredstva v aplikaciji Laravel preverite, ali obstaja cevovod, ki zbira in minimizira vse datoteke sredstev. Tistim, ki jim je všeč sistem paketov, kot so Webpack, Gulp, Parcel itd., Se ni treba truditi, a če tega že ne počnete, Laravel Mix je trdno priporočilo.

Mix je lahka (in čudovita, z iskrenostjo!) Ovoj okoli Webpacka, ki skrbi za vse vaše datoteke CSS, SASS, JS itd. Za izdelavo. Običajna .mix.js datoteka je lahko tako majhna in še vedno dela čudeže:

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

mix.js (‘sredstva / js / app.js’, ‘javni / js’)
.sass (‘sredstva / sass / app.scss’, ‘public / css’);

To samodejno poskrbi za uvoz, minifikacijo, optimizacijo in celoten pas, ko ste pripravljeni na proizvodnjo in zaženete npm zagon proizvodnje. Mix skrbi za ne le tradicionalne datoteke JS in CSS, ampak tudi komponente Vue in React, ki jih imate v delovnem toku aplikacije.

Več informacij tukaj!

Zaključek

Optimizacija delovanja je bolj umetnost kot znanost – vedeti, kako in koliko narediti, je pomembno kot kaj storiti. Glede na to, koliko in kaj vse lahko optimizirate v aplikaciji Laravel, ni konca.

Vseeno pa bi vam rad dal nekaj nasvetov o ločitvi – optimizacijo je treba izvesti, če obstaja utemeljen razlog, in ne zato, ker se sliši dobro ali ker ste paranoični glede uspešnosti aplikacij za 100.000+ uporabnikov, v resnici pa jih je le 10.

Če niste prepričani, ali morate optimizirati aplikacijo ali ne, vam ni treba brcati pregovornega gnezda. Delovna aplikacija, ki se počuti dolgočasno, vendar počne natanko tisto, kar mora, je desetkrat bolj zaželena kot aplikacija, ki je bila optimizirana v mutantni hibridni super stroj, a tu in tam zastavlja.

In, da bi newbiew postal Laravel mojster, preverite to spletni tečaj.

Naj se vaše aplikacije zaženejo veliko, veliko hitreje! ��

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