Laravel sok minden. De a gyors nem tartozik ezek közé. Tanuljunk meg néhány trükköt a szakmából, hogy gyorsabban menjen!
Egyetlen PHP fejlesztőt sem érinthetett meg Laravel ezek a napok. Vagy junior vagy középszintű fejlesztők, akik szeretik a Laravel által kínált gyors fejlődést, vagy olyan vezető fejlesztők, akiknek a piaci nyomás miatt kénytelenek megtanulni a Laravelt.
Akárhogy is, tagadhatatlan, hogy a Laravel újjáélesztette a PHP ökoszisztémáját (az biztos, hogy rég elhagytam volna a PHP világát, ha Laravel nincs ott).
Egy részlet (valamennyire indokolt) öndicséretből Laraveltől
Mivel azonban a Laravel hátrahajlik, hogy megkönnyítse az Ön dolgát, ez azt jelenti, hogy alatta rengeteg munkát végez annak érdekében, hogy fejlesztőként kényelmes életet élhessen. A Laravel összes „varázslatos” funkciója, amely csak úgy tűnik, működik, több rétegben kódol, amelyet minden egyes funkció futtatásakor fel kell pörgetni. Még egy egyszerű kivétel is nyomon követi, milyen mély a nyúllyuk (figyelje meg, hol kezdődik a hiba, egészen a fő kernelig):
Az egyik nézetben fordítási hibának tűnő esethez 18 függvényhívást kell nyomon követni. Én személy szerint 40-nel találkoztam, és könnyen lehet, hogy több is lehet, ha más könyvtárakat és beépülő modulokat használ.
Lényeg, hogy ez alapértelmezés szerint a kód rétegei után lelassítja a Laravelt.
Milyen lassú Laravel?
Őszintén szólva, több okból is lehetetlen válaszolni erre a kérdésre.
Először is, nincs elfogadott, objektív és ésszerű szabvány a webalkalmazások sebességének mérésére. Mihez képest gyorsabb vagy lassabb? Milyen feltételekkel?
Másodszor, egy webalkalmazás olyan sok mindentől függ (adatbázis, fájlrendszer, hálózat, gyorsítótár stb.), hogy egyszerűen hülyeség a sebességről beszélni. Egy nagyon gyors webalkalmazás nagyon lassú adatbázissal nagyon lassú webalkalmazás. 🙂
De éppen ez a bizonytalanság az oka annak, hogy a benchmarkok népszerűek. Annak ellenére, hogy semmit sem jelentenek (lásd ez és ez), nyújtanak némi referenciakeretet, és segítenek megőrülni. Ezért, miután több csipet só készen áll, kapjunk egy rossz, hozzávetőleges képet a PHP keretrendszerek sebességéről.
Ez a meglehetősen tekintélyes GitHub forrása PHP-keretrendszerek a következőképpen állnak össze, ha összehasonlítjuk:
Lehet, hogy itt észre sem veszed Laravelt (még akkor sem, ha nagyon hunyorogsz), hacsak nem veted az ügyedet a farka végére. Igen, kedves barátaim, Laravel az utolsó! Igaz, ezeknek a „kereteknek” a többsége nem túl praktikus, sőt nem is hasznos, de elárulja, milyen lomha a Laravel a többi népszerűbbhöz képest.
Általában ez a „lassúság” nem jelentkezik az alkalmazásokban, mivel mindennapi webes alkalmazásaink ritkán érik el a magas számokat. De amint megtörténik (mondjuk 200-500-nál felfelé egyidejűleg), a szerverek elkezdenek megfulladni és elhalnak. Ez az az idő, amikor még több hardverrel sem oldódik meg a probléma, és az infrastrukturális számlák olyan gyorsan emelkednek, hogy a felhőalapú számítástechnika magas ideálja összeomlik.
De hé, vidíts fel! Ez a cikk nem arról szól, hogy mit nem lehet megtenni, hanem arról, hogy mit lehet tenni. 🙂
A jó hír az, hogy sokat tehet a Laravel alkalmazás gyorsabb működéséért. Többször gyorsan. Igen, nem viccelek. Ugyanazt a kódbázist ballisztikussá teheti, és havonta több száz dollárt takaríthat meg az infrastruktúra/tárhelyszámlákon. Hogyan? Térjünk rá.
Négyféle optimalizálás
Véleményem szerint az optimalizálás négy különböző szinten végezhető el (ami a PHP-alkalmazásokat illeti:
- Nyelvi szintű: Ez azt jelenti, hogy a nyelv gyorsabb verzióját használja, és kerüli a nyelv speciális jellemzőit/stílusait, amelyek lelassítják a kódot.
- Keretszint: Ezekkel a dolgokkal foglalkozunk ebben a cikkben.
- Infrastruktúra szintű: A PHP folyamatkezelő, webszerver, adatbázis stb. hangolása.
- Hardverszint: Jobb, gyorsabb és erősebb hardvertárhely-szolgáltató felé váltás.
Minden ilyen típusú optimalizálásnak megvan a maga helye (például a PHP-fpm optimalizálás meglehetősen kritikus és hatékony). Ennek a cikknek a középpontjában azonban a tisztán 2-es típusú optimalizálás áll: a keretrendszerrel kapcsolatosak.
Mellesleg a számozás mögött nincs ok, és nem is elfogadott szabvány. Ezeket most kitaláltam. Kérem, soha ne idézzen engem, és ne mondja azt, hogy „3-as típusú optimalizálásra van szükségünk a szerverünkön”, különben a csapatvezető megöli Önt, megkeres, majd engem is megöl. 😀
És most végre megérkeztünk az ígéret földjére.
Tartalomjegyzék
Ügyeljen az n+1 adatbázis-lekérdezésekre
Az n+1 lekérdezési probléma gyakori probléma ORM-ek használatakor. A Laravelnek van egy erőteljes ORM-je, az Eloquent, ami annyira szép, olyan kényelmes, hogy gyakran elfelejtjük megnézni, mi történik.
Vegyünk egy nagyon gyakori forgatókönyvet: egy adott ügyféllista által leadott összes rendelés listájának megjelenítése. Ez meglehetősen gyakori az e-kereskedelmi rendszerekben és általában minden jelentéskészítő felületen, ahol meg kell jelenítenünk az egyes entitásokhoz kapcsolódó összes entitást.
A Laravelben elképzelhetünk egy vezérlő funkciót, amely a következőképpen látja el a feladatot:
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]);
}
}
Édes! És ami még fontosabb, elegáns, gyönyörű. 🤩🤩
Sajnos ez egy katasztrofális módja a kódírásnak a Laravelben.
Íme, miért.
Amikor megkérjük az ORM-et, hogy keresse meg az adott ügyfeleket, egy ehhez hasonló SQL lekérdezés generálódik:
SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);
Ami pontosan az elvárásoknak megfelelő. Ennek eredményeként az összes visszaadott sor a $customers gyűjteményben tárolódik a vezérlő függvényen belül.
Most egyenként körbejárjuk az egyes vásárlókat, és megkapjuk a rendeléseiket. Ez végrehajtja a következő lekérdezést. . .
SELECT * FROM orders WHERE customer_id = 22;
. . . ahányszor van vásárló.
Más szóval, ha 1000 vevő rendelési adatait kell lekérnünk, akkor a végrehajtott adatbázis-lekérdezések teljes száma 1 (az összes ügyfél adatának lekéréséhez) + 1000 (az egyes ügyfelek rendelési adatainak lekéréséhez) = 1001. innen származik az n+1 név.
Tudunk jobban csinálni? Biztosan! Az úgynevezett „eager loading” használatával rákényszeríthetjük az ORM-et, hogy JOIN-t hajtson végre, és egyetlen lekérdezéssel visszaadja az összes szükséges adatot! Mint ez:
$orders = Customer::findMany($ids)->with('orders')->get();
A kapott adatstruktúra természetesen beágyazott, de a rendelési adatok könnyen kinyerhetők. Az eredményül kapott egyetlen lekérdezés ebben az esetben a következő:
SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, . . .);
Egyetlen lekérdezés természetesen jobb, mint ezer extra lekérdezés. Képzeld el, mi történne, ha 10 000 ügyfelet kell feldolgozni! Vagy ne adj isten, ha minden rendelésben szereplő tételeket is ki akartuk rakni! Ne feledje, a technika neve buzgó betöltés, és ez szinte mindig jó ötlet.
Gyorsítótárazd a konfigurációt!
A Laravel rugalmasságának egyik oka a keretrendszer részét képező rengeteg konfigurációs fájl. Szeretné módosítani a képek tárolási módját/helyét?
Nos, csak módosítsa a config/filesystems.php fájlt (legalábbis az írás pillanatában). Több sor-illesztőprogrammal szeretne dolgozni? Nyugodtan írja le őket a config/queue.php fájlban. Most számoltam, és megállapítottam, hogy 13 konfigurációs fájl található a keretrendszer különböző aspektusaihoz, így biztosítva, hogy nem fog csalódni, bármit is szeretne változtatni.
Tekintettel a PHP természetére, minden alkalommal, amikor új webes kérés érkezik, Laravel felébred, mindent elindít, és elemzi ezeket a konfigurációs fájlokat, hogy kitalálja, hogyan lehet ezúttal másképp csinálni. Kivéve, hogy hülyeség, ha az elmúlt napokban nem változott semmi! A konfiguráció újjáépítése minden kérésre egy pazarlás, amelyet el lehet (valójában el kell kerülni), és a kiút egy egyszerű parancs, amelyet Laravel kínál:
php artisan config:cache
Ez azt jelenti, hogy az összes rendelkezésre álló konfigurációs fájlt egyetlen fájlba egyesíti, és a gyorsítótár található valahol a gyors visszakereséshez. Amikor legközelebb webes kérés érkezik, a Laravel egyszerűen elolvassa ezt az egyetlen fájlt, és elindul.
Ennek ellenére a konfigurációs gyorsítótárazás egy rendkívül kényes művelet, amely az arcába robbanhat. A legnagyobb baj az, hogy miután kiadtad ezt a parancsot, az env() függvény mindenhonnan meghív, kivéve a konfigurációs fájlokat, null értékkel tér vissza!
Van értelme, ha belegondolunk. Ha konfigurációs gyorsítótárat használ, azt mondja a keretrendszernek: „Tudod mit, azt hiszem, szépen beállítottam a dolgokat, és 100%-ig biztos vagyok benne, hogy nem akarom, hogy megváltozzanak.” Más szóval, elvárja, hogy a környezet statikus maradjon, erre valók az .env fájlok.
Ezzel együtt a konfigurációs gyorsítótárazás néhány vaskos, szent, megszeghetetlen szabálya:
Csökkentse az automatikusan feltöltött szolgáltatásokat
Hogy segítsen, Laravel rengeteg szolgáltatást tölt be, amikor felébred. Ezek a config/app.php fájlban érhetők el a „szolgáltatók” tömbkulcs részeként. Nézzük, mi van az én esetemben:
/*
|--------------------------------------------------------------------------
| 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,
],
Még egyszer megszámoltam, és 27 szolgáltatás van felsorolva! Lehet, hogy mindegyikre szüksége lesz, de nem valószínű.
Például jelenleg egy REST API-t építek, ami azt jelenti, hogy nincs szükségem a Session Service Providerre, a View Service Providerre stb. És mivel néhány dolgot a magam módján csinálok, és nem követem a keretrendszer alapértelmezett beállításait , letilthatom az Auth szolgáltatót, a lapozási szolgáltatót, a fordítási szolgáltatót stb. Összességében ezeknek majdnem a fele szükségtelen az én használati esetemben.
Vessen egy pillantást hosszasan, alaposan az alkalmazására. Szüksége van ezekre a szolgáltatókra? De az isten szerelmére, kérlek, ne vakon kommentáld ezeket a szolgáltatásokat és told a gyártásba! Futtassa le az összes tesztet, ellenőrizze a dolgokat manuálisan a fejlesztői és állomásozó gépeken, és legyen nagyon paranoiás, mielőtt meghúzza a ravaszt. 🙂
Legyen bölcs a köztes szoftververemekkel
Ha szüksége van a bejövő webkérés egyéni feldolgozására, egy új köztes szoftver létrehozása a megoldás. Csábító az app/Http/Kernel.php megnyitása, és a köztes szoftver beillesztése a web- vagy API-verembe; így elérhetővé válik az egész alkalmazásban, és ha nem csinál valami tolakodó dolgot (például naplózást vagy értesítést).
Az alkalmazás növekedésével azonban ez a globális köztesszoftver-gyűjtemény csendes terhet jelenthet az alkalmazás számára, ha ezek mindegyike (vagy többsége) minden kérésben megtalálható, még akkor is, ha ennek nincs üzleti oka.
Más szóval, ügyeljen arra, hogy hol ad hozzá/alkalmaz új köztes szoftvert. Kényelmesebb lehet globálisan hozzáadni valamit, de a teljesítménybüntetés hosszú távon nagyon magas. Tudom, hogy milyen fájdalmat kell átélnie, ha szelektíven alkalmazná a köztes szoftvert minden alkalommal, amikor új változás történik, de ezt a fájdalmat szívesen vállalnám és ajánlanám!
Kerülje az ORM-et (időnként)
Míg az Eloquent a DB interakció számos aspektusát kellemessé teszi, ennek a sebesség ára van. Leképezőként az ORM-nek nem csak rekordokat kell lekérnie az adatbázisból, hanem példányosítania kell a modellobjektumokat és hidratálnia (ki kell töltenie) oszlopadatokkal.
Tehát, ha egy egyszerű $users = User::all() műveletet hajt végre, és mondjuk 10 000 felhasználó van, a keretrendszer 10 000 sort fog lekérni az adatbázisból, és belsőleg elkészít 10 000 új User()-et, és kitölti a tulajdonságait a megfelelő adatokkal. . Ez hatalmas mennyiségű munka folyik a színfalak mögött, és ha az alkalmazás helye az adatbázis szűk keresztmetszetté válik, időnként jó ötlet az ORM megkerülése.
Ez különösen igaz az összetett SQL-lekérdezésekre, ahol sok karikát kell ugrani, és lezárásokat kell írnia, és így is hatékony lekérdezést kell kapnia. Ilyen esetekben előnyös a DB::raw() végrehajtása és a lekérdezés kézzel történő megírása.
Elhaladva ez teljesítménytanulmány, még egyszerű betéteknél is Az ékesszóló sokkal lassabb a rekordok számának növekedésével:
Használja a gyorsítótárat, amennyire csak lehetséges
A webalkalmazás-optimalizálás egyik legjobban őrzött titka a gyorsítótárazás.
Az avatatlanok számára a gyorsítótárazás azt jelenti, hogy előre kiszámítják és eltárolják a drága eredményeket (ezek költségesek a CPU- és memóriahasználat szempontjából), és egyszerűen visszaküldik őket ugyanazon lekérdezés megismétlésekor.
Például egy e-kereskedelmi üzletben szembesülhet azzal, hogy a 2 millió termék közül a legtöbbször azok érdeklik az embereket, amelyek frissen vannak raktáron, egy bizonyos árkategórián belül, és egy adott korosztály számára. Az adatbázisból ezeknek az információknak a lekérdezése pazarló – mivel a lekérdezés nem változik gyakran, jobb, ha ezeket az eredményeket olyan helyen tároljuk, ahol gyorsan elérhetjük.
A Laravel beépített támogatással rendelkezik számos típushoz gyorsítótárazás. A gyorsítótárazási illesztőprogram használatán és a gyorsítótárazási rendszer alapjaitól való felépítésén kívül érdemes néhány Laravel-csomagot használni, amelyek megkönnyítik modell gyorsítótárazás, lekérdezés gyorsítótárazásastb.
De ne feledje, hogy egy bizonyos egyszerűsített használati eseten túl az előre elkészített gyorsítótárazási csomagok több problémát okozhatnak, mint amennyit megoldanak.
Inkább a memórián belüli gyorsítótárazást részesítse előnyben
Amikor gyorsítótáraz valamit a Laravelben, több lehetősége is van arra, hogy hol tárolja a gyorsítótárba helyezendő számításokat. Ezeket a lehetőségeket más néven gyorsítótár-illesztőprogramok. Tehát bár lehetséges és teljesen ésszerű a fájlrendszer használata a gyorsítótár eredményeinek tárolására, a gyorsítótárazás valójában nem az, aminek a célja.
Ideális esetben egy memórián belüli (teljesen a RAM-ban élő) gyorsítótárat szeretne használni, mint például a Redis, a Memcached, a MongoDB stb., így nagyobb terhelés esetén a gyorsítótárazás létfontosságú hasznot jelent, nem pedig maga a szűk keresztmetszet.
Most azt gondolhatnánk, hogy egy SSD-lemez szinte ugyanaz, mint egy RAM-meghajtó használata, de még csak közel sem. Akár informálisan is benchmarkok azt mutatják, hogy a RAM 10-20-szor felülmúlja az SSD-t, ami a sebességet illeti.
A kedvenc rendszerem a gyorsítótárazás terén a Redis. ez van nevetségesen gyors (másodpercenként 100 000 olvasási művelet gyakori), és nagyon nagy gyorsítótár-rendszerek esetén továbbfejleszthető fürt könnyen.
Gyorsítótárazza az útvonalakat
Csakúgy, mint az alkalmazás konfigurációja, az útvonalak nem sokat változnak az idő múlásával, és ideális jelöltek a gyorsítótárazáshoz. Ez különösen igaz, ha nem bírod elviselni a nagy fájlokat, mint én, és a web.php és api.php fájlokat több fájlra osztja fel. Egyetlen Laravel-parancs összecsomagolja az összes elérhető útvonalat, és kéznél tartja őket a későbbi hozzáféréshez:
php artisan route:cache
Ha pedig végül hozzáad vagy módosít útvonalakat, egyszerűen tegye a következőket:
php artisan route:clear
Képoptimalizálás és CDN
A képek a legtöbb webalkalmazás szíve-lelke. Véletlenül ők a sávszélesség legnagyobb fogyasztói, és az alkalmazások/webhelyek lassúságának egyik legnagyobb oka. Ha egyszerűen csak naivan tárolja a feltöltött képeket a szerveren, és visszaküldi őket HTTP-válaszként, akkor hatalmas optimalizálási lehetőséget enged el.
Az első javaslatom, hogy ne tárolja helyben a képeket – meg kell küzdeni az adatvesztés problémájával, és attól függően, hogy az ügyfél melyik földrajzi régióban tartózkodik, az adatátvitel fájdalmasan lassú lehet.
Ehelyett keress olyan megoldást, mint pl Felhős amely automatikusan átméretezi és menet közben optimalizálja a képeket.
Ha ez nem lehetséges, használja a Cloudflare-hez hasonlót a képek gyorsítótárazására és kiszolgálására, miközben azok a szerveren vannak tárolva.
És ha még ez sem lehetséges, sokat változtat a webszerver szoftverén, hogy tömörítse az eszközöket, és irányítsa a látogató böngészőjét a dolgok gyorsítótárazására. Így nézne ki egy részlet az Nginx konfigurációból:
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";
}
}
Tisztában vagyok vele, hogy a képoptimalizálásnak semmi köze a Laravelhez, de ez egy olyan egyszerű és erőteljes trükk (és oly gyakran elhanyagolják), hogy nem tehetek róla.
Automatikus betöltő optimalizálás
Az automatikus betöltés egy ügyes, nem túl régi funkció a PHP-ben, amely vitathatatlanul megmentette a nyelvet a végzettől. Ennek ellenére a megfelelő osztály megtalálásának és betöltésének folyamata egy adott névtér-karakterlánc megfejtésével időt vesz igénybe, és elkerülhető olyan éles környezetben, ahol a nagy teljesítmény kívánatos. A Laravelnek ismét van egyparancsos megoldása erre:
composer install --optimize-autoloader --no-dev
Barátkozzon meg a sorokkal
Sorok hogyan dolgozza fel a dolgokat, ha sok van belőlük, és mindegyik néhány ezredmásodpercig tart. Jó példa erre az e-mailek küldése – a webalkalmazásokban széles körben elterjedt eset, hogy néhány értesítő e-mailt küldenek, amikor a felhasználó bizonyos műveleteket hajt végre.
Például egy újonnan bevezetett terméknél érdemes lehet a vállalat vezetőségét (mintegy 6-7 e-mail címet) értesíteni, ha valaki egy bizonyos érték felett rendel. Feltételezve, hogy az e-mail átjárója 500 ms-on belül válaszolni tud az SMTP-kérésére, jó 3-4 másodperces várakozásról beszélünk a felhasználónak, mielőtt a rendelés megerősítése beindul. Nagyon rossz UX darab, biztos vagyok benne, hogy meg fog egyetért.
A megoldás az, hogy a beérkező munkákat tárolja, közölje a felhasználóval, hogy minden rendben ment, és (néhány másodperccel) később feldolgozza azokat. Ha hiba történik, a sorba állított feladatokat néhányszor újra meg lehet próbálni, mielőtt sikertelennek nyilvánítanák őket.
Köszönetnyilvánítás: Microsoft.com
Míg a sorba állító rendszer kissé bonyolítja a beállítást (és némi felügyeleti költséget is növel), ez nélkülözhetetlen egy modern webalkalmazásban.
Eszközoptimalizálás (Laravel Mix)
A Laravel-alkalmazásban található bármely front-end eszköz esetében győződjön meg arról, hogy van egy folyamat, amely összeállítja és kicsinyíti az összes eszközfájlt. Akik kényelmesek az olyan bundler rendszerekkel, mint a Webpack, Gulp, Parcel stb., azoknak nem kell foglalkozniuk, de ha még nem csinálja, Laravel Mix szilárd ajánlás.
A Mix egy könnyű (és őszintén szólva!) csomagolóanyag a Webpack körül, amely gondoskodik az összes CSS, SASS, JS stb. fájlról a gyártáshoz. Egy tipikus .mix.js fájl ilyen kicsi is lehet, és még mindig csodákat művel:
const mix = require('laravel-mix');
mix.js('resources/js/app.js', 'public/js')
.sass('resources/sass/app.scss', 'public/css');
Ez automatikusan gondoskodik az importálásról, a minimalizálásról, az optimalizálásról és az egész shebangről, amikor készen áll a termelésre, és futtatja az npm futtatást. A Mix nem csak a hagyományos JS- és CSS-fájlokról gondoskodik, hanem a Vue és React összetevőiről is, amelyek az alkalmazás munkafolyamatában lehetnek.
Több információ itt!
Következtetés
A teljesítményoptimalizálás inkább művészet, mint tudomány – fontos tudni, hogyan és mennyit kell tenni, mint hogy mit kell tenni. Ennek ellenére nincs vége annak, hogy mennyit és mit tud optimalizálni egy Laravel alkalmazásban.
De bármit is tesz, szeretnék néhány tanácsot adni az elválásról – az optimalizálást akkor kell elvégezni, ha annak alapos oka van, és nem azért, mert jól hangzik, vagy mert paranoiás az alkalmazás 100 000+ felhasználó számára nyújtott teljesítménye miatt, miközben a valóságban. csak 10 van.
Ha nem vagy biztos abban, hogy optimalizálnod kell-e az alkalmazásodat vagy sem, nem kell kirúgnod a közmondásos hornet fészket. Egy működő alkalmazás, amely unalmasnak tűnik, de pontosan azt csinálja, amit kell, tízszer kívánatosabb, mint egy mutáns hibrid szupergéppé optimalizált, de időnként tönkremegy.
És ha újoncból Laravel mester szeretne lenni, nézze meg ezt online tanfolyam.
Fussanak alkalmazásai sokkal, de sokkal gyorsabban! 🙂