Hogyan lehet optimalizálni a PHP Laravel webes alkalmazást a nagy teljesítmény érdekében?

Laravel sok minden. De a gyors nem egy közülük. Tanuljunk néhány trükköt a kereskedelemről, hogy gyorsabbá váljon!


Egyik PHP fejlesztőt sem érinti Laravel ezek a napok. Vagy junior vagy középszintű fejlesztő, akik szeretik a Laravel által kínált gyors fejlődést, vagy egy idősebb fejlesztő, akiket a piaci nyomás miatt kénytelenek tanulni Laravelről.

Akárhogy is, nem tagadható, hogy Laravel újjáélesztette a PHP ökoszisztémát (biztosan én már régen elhagytam volna a PHP világát, ha Laravel nem lenne ott).

Laravel (kissé indokolt) önbecsülésrészlet

Mivel azonban Laravel hátrahajol, hogy megkönnyítse a dolgát, ez azt jelenti, hogy alatta rengeteg munkát végez annak érdekében, hogy fejlesztőként kényelmesen élhessen. A Laravel „varázslatos” tulajdonságai, amelyek csak úgy működnek, tartalmaznak rétegeket a kódrétegeken, amelyeket minden egyes funkció futtatásakor fel kell verni. Még egy egyszerű kivételnél is nyomon lehet követni, milyen mély a nyúl lyuk (figyelje meg, ahol a hiba kezdődik, egészen a fő kernelig):

Annak érdekében, amely az egyik nézetben fordítási hibának tűnik, 18 függvényhívás van nyomon követésre. Személyesen jöttem össze a 40 évvel, és egyszerűen más is lehet, ha más könyvtárakat és bővítményeket használsz.

Mivel alapértelmezés szerint ez a réteg a kódrétegekre esik, a Laravel lassul.

Mennyire lassú Laravel?

Őszintén szólva, ezt a kérdést több okból is lehetetlen megválaszolni.

Első, nincs elfogadott, objektív és ésszerű szabvány a webes alkalmazások sebességének mérésére. Mire gyorsabb vagy lassabb? Milyen feltételek mellett?

Második, egy webalkalmazás olyan sok dolgotól függ (adatbázis, fájlrendszer, hálózat, gyorsítótár stb.), hogy egyszerűen buta dolog beszélni a sebességről. Egy nagyon gyors webes alkalmazás, egy nagyon lassú adatbázissal, egy nagyon lassú webes alkalmazás. ��

De ez a bizonytalanság pontosan ezért teszi a referenciaértékeket népszerűvé. Annak ellenére, hogy semmit sem jelentenek (lásd ez és ez), biztosítanak némi referenciakeretet, és segítenek bennünket a megőrültségtől. Ezért több csipetnyi sóval készítve téves, durva elképzelést kapunk a sebességről a PHP keretek között.

Megy ez a meglehetősen tiszteletreméltó GitHub forrás, Íme a PHP keretrendszer felépítése összehasonlítva:

Lehet, hogy itt még a Laravel sem veszi észre (még akkor is, ha nagyon keményen foszlik), hacsak nem a farok végére dobja az ügyét. Igen, kedves barátaim, Laravel jön utoljára! Most elfogadható, hogy ezeknek a „kereteknek” a többsége nem túl praktikus vagy akár hasznos is, de megmondja nekünk, hogy milyen lassú a Laravel a többi népszerűbbhez képest..

Általában ez a „lassúság” nem jellemző az alkalmazásokban, mert mindennapi webalkalmazásaink ritkán érik el a magas számokat. De ha egyszer megteszik (mondjuk 200-500 egyidejűleg felfelé), a kiszolgálók elfojtják és elhalnak. Ez az idő, amikor még a hardver eldobása sem oldja meg a problémát, és az infrastrukturális számlák olyan gyorsan emelkednek, hogy a felhőalapú számítástechnika ideális eszközei összeomlanak..

De hé, felvidíts! Ez a cikk nem arról szól, hogy mit nem lehet megtenni, hanem arról, hogy mit lehet tenni. ��

Jó hír az, hogy sokat tehetünk a Laravel alkalmazás gyorsabbá tételéhez. Többször gyors. Igen, nem viccelek. Ugyanazt a kódbázist ballisztikus célúvá teheti, és havonta több száz dollárt takaríthat meg az infrastrukturális / tárhelyszámlákra. Hogyan? Menjünk hozzá.

Négyféle optimalizálás

Véleményem szerint az optimalizálást négy különálló szinten lehet elvégezni (amikor a PHP alkalmazásokról van szó, azaz):

  1. Nyelv-szint: Ez azt jelenti, hogy a nyelv gyorsabb verzióját használja, és elkerüli a nyelv speciális funkcióit / stílusát, ami lassítja a kódot.
  2. Framework-szint: Ezekre a kérdésekre fogunk kitérni ebben a cikkben.
  3. Infrastruktúra-szint: A PHP folyamatkezelő, a webszerver, az adatbázis stb. Hangolása.
  4. Hardver-szint: Áttérés egy jobb, gyorsabb, erősebb hardver-tárhely szolgáltatóra.

Az optimisták mindegyik típusának megvan a maga helye (például a php-fpm optimalizálás elég kritikus és hatékony). De a cikk középpontjában a pusztán a 2. típusú optimalizálás áll: a kerettel kapcsolatosak.

Mellesleg, a számozás mögött nincs értelme, és ez nem egy elfogadott szabvány. Én csak ezeket csináltam. Kérjük, soha ne idézzen nekem, és ne mondja: „Szükségünk van a 3. típusú optimalizálásra a szerverünkön”. Ellenkező esetben a csapat vezetése megöl, megtalál és engem is megöl. ��

És most végre végre megérkeztünk az ígért földre.

Legyen tisztában az n + 1 adatbázis-lekérdezésekkel

Az n + 1 lekérdezési probléma általános, ha ORM-eket használnak. A Laravel rendelkezik az Eloquent nevű erőteljes ORM-szel, amely olyan szép, olyan kényelmes, hogy gyakran elfelejtjük megnézni, mi folyik itt.

Vegyünk egy nagyon általános forgatókönyvet: megjelenítjük az adott ügyféllista által leadott összes rendelés listáját. Ez nagyon gyakori az e-kereskedelmi rendszerekben és általában az összes jelentési felületen, ahol meg kell jeleníteni az egyes entitásokkal kapcsolatos összes entitást.

Laravelben elképzelhetünk egy olyan vezérlőfunkciót, amely így működik:

osztály OrdersController kiterjeszti a Vezérlőt
{
// …

getAllByCustomers nyilvános funkció ($ kérés kérése, tömb $ id) {
$ ügyfelek = Ügyfél :: findMany ($ id);
$ megrendelések = gyűjtés (); // új kollekció

foreach ($ ügyfelek $ ügyfelekként) {
$ megrendelések = $ megrendelések->egyesítés ($ ügyfél->megbízás);
}

visszatérési nézet (‘admin.reports.orders’, [‘order’ => $ Rendelések]);
}
}

Édes! És ami még fontosabb: elegáns, gyönyörű. ����

Sajnos katasztrofális módszer a kód írására Laravelben.

Itt van miért.

Amikor arra kérjük az ORM-et, hogy keresse meg az adott ügyfelet, akkor létrejön egy ilyen SQL lekérdezés:

VÁLASZT * ÜGYFELEIT, HOGY ID (BE) (22, 45, 34, …);

Ami pontosan a vártnál van. Ennek eredményeként az összes visszaküldött sor tárolásra kerül a gyűjtemény $ ügyfelekben a vezérlő funkción belül.

Most minden egyes ügyfelet egyenként áthidalunk, és megkapjuk a megrendeléseiket. Ez végrehajtja a következő lekérdezést . . .

VÁLASZT * A megrendelések közül, ahol customer_id = 22;

. . . annyiszor, amennyire vannak vásárlók.

Más szavakkal, ha meg kell szerezni a megrendelési adatokat 1000 ügyféltől, akkor a végrehajtott adatbázis-lekérdezések száma 1 (az összes ügyfél adatainak beolvasása) + 1000 (az egyes ügyfelek megrendelési adatainak beolvasásakor) = 1001. Ez ahonnan az n + 1 név származik.

Meg tudunk-e csinálni jobban? Biztosan! A lelkes betöltés használatával arra kényszeríthetjük az ORM-et, hogy végezzen JOIN-ot, és egyetlen lekérdezéssel adja vissza az összes szükséges adatot! Mint ez:

$ megrendelések = Vevő :: findMany ($ ID)->A (megbízások)->kap();

A kapott adatstruktúra biztosan beágyazott, de a rendelési adatok könnyen kinyerhetők. A kapott egyetlen lekérdezés, ebben az esetben a következő:

KIVÁLASZT * ÜGYFELEKBŐL INNER CSATLAKOZÁSOK megrendelések az customers.id = order.customer_id HOGY kliens.id IN (22, 45, …);

Egyetlen lekérdezés természetesen jobb, mint ezer extra lekérdezés. Képzelje el, mi történne, ha 10 000 vásárló lenne feldolgozható! Vagy Isten tiltja, ha a rendeléseket is meg akarjuk jeleníteni! Ne feledje, hogy a technika neve lelkesen tölt be, és ez szinte mindig jó ötlet.

Gyorsítótárban a konfigurációt!

A Laravel rugalmasságának egyik oka a rengeteg konfigurációs fájl, amely a keret része. Meg szeretné változtatni a képek tárolási módját / helyét?

Nos, csak változtassa meg a config / filesystems.php fájlt (legalább az írástól kezdve). Több sorvezérlővel szeretne dolgozni? Nyugodtan írja le őket a config / queue.php fájlban. Csak kiszámoltam és megállapítottam, hogy 13 konfigurációs fájl van a keret különféle aspektusaira, biztosítva, hogy nem fog csalódni, függetlenül attól, hogy mit szeretne megváltoztatni.

A PHP jellegére való tekintettel minden új webes kérés beérkezésekor Laravel felébred, mindent elindít, és elemzi ezeket a konfigurációs fájlokat, hogy kitalálja, hogyan lehet másként tenni a dolgokat. Kivéve, hogy ostoba, ha semmi sem változott az elmúlt napokban! A konfiguráció újjáépítése minden kérésre hulladék, amelyet el lehet kerülni (valójában ki kell kerülni), és a kijátszás egy egyszerű parancs, amelyet a Laravel kínál:

php kézműves konfiguráció: gyorsítótár

Ezzel összekapcsolja az összes elérhető konfigurációs fájlt egyetlen fájlba, és a gyorsítótár a gyors letöltés helyén van. A következő alkalommal, amikor webes kérés érkezik, Laravel egyszerűen elolvassa ezt az egyetlen fájlt, és elindul.

A konfiguráció gyorsítótárazása rendkívül kényes művelet, amely felrobbanthat az arcán. A legnagyobb dolog az, hogy amint kiadta ezt a parancsot, az env () függvény mindenütt felhívja a konfigurációs fájlokat kivéve, ha null!

Ennek van értelme, ha gondolkodik rajta. Ha a konfigurációs gyorsítótárat használja, akkor ezt a keretet mondja: “Tudod mit, azt hiszem, jól beállítottam a dolgokat, és 100% -ban biztos vagyok benne, hogy nem akarom, hogy megváltoztassák őket.” Más szóval, arra számít, hogy a környezet statikus marad, erre az .env fájlok vonatkoznak.

Ennek kapcsán a vasbetonolt, szent, törhetetlen szabályok a konfigurációs gyorsítótárban vannak:

  1. Csak gyártási rendszeren csinálja.
  2. Csak akkor tegye meg, ha valóban-nagyon biztos abban, hogy befagyasztja-e a konfigurációt.
  3. Ha valami nem sikerül, vonja vissza a beállítást a php artisan cache segítségével: törölje
  4. Imádkozzatok, hogy az üzletnek okozott kár nem volt jelentős!

Csökkentse az automatikusan feltöltött szolgáltatásokat

Hasznosnak tartja, hogy a Laravel egy csomó szolgáltatást tölt fel, amikor felébred. Ezek a config / app.php fájlban érhetők el a ‘szolgáltatók’ tömb kulcsának részeként. Vessünk egy pillantást arra, amit nekem van:

/ *
|————————————————————————–
| Automatikusan feltöltött szolgáltatók
|————————————————————————–
|
| Az itt felsorolt ​​szolgáltatók automatikusan betöltődnek a
| kérjen jelentkezését. Nyugodtan vegye fel saját szolgáltatásait
| Ez a tömb kibővített funkcionalitást biztosít az alkalmazásokhoz.
|
* /

‘szolgáltatók’ => [

/ *
* Laravel Framework szolgáltatók…
* /
Illuminate \ Auth \ AuthServiceProvider :: class,
Illuminate \ Broadcasting \ BroadcastServiceProvider :: class,
Illuminate \ Bus \ BusServiceProvider :: class,
Illuminate \ cache \ CacheServiceProvider :: class,
Illuminate \ Foundation \ Providers \ ConsoleSupportServiceProvider :: class,
Illuminate \ Cookie \ CookieServiceProvider :: class,
Illuminate \ Database \ DatabaseServiceProvider :: class,
Illuminate \ Encryption \ EncryptionServiceProvider :: class,
Illuminate \ fájlrendszer \ FilesystemServiceProvider :: class,
Illuminate \ Foundation \ Providers \ FoundationServiceProvider :: class,
Illuminate \ hash \ HashServiceProvider :: class,
Illuminate \ Mail \ MailServiceProvider :: class,
Illuminate \ Értesítések \ NotificationServiceProvider :: class,
Illuminate \ Pagination \ PaginationServiceProvider :: class,
Illuminate \ Pipeline \ PipelineServiceProvider :: class,
Illuminate \ Sor \ QueueServiceProvider :: class,
Illuminate \ Redis \ RedisServiceProvider :: class,
Illuminate \ Auth \ jelszavak \ PasswordResetServiceProvider :: class,
Illuminate \ Session \ SessionServiceProvider :: class,
Illuminate \ Translation \ TranslationServiceProvider :: class,
Illuminate \ Validation \ ValidationServiceProvider :: class,
Illuminate \ nézet \ ViewServiceProvider :: class,

/ *
* Csomagszolgáltatók…
* /

/ *
* Alkalmazás-szolgáltatók…
* /
App \ Providers \ AppServiceProvider :: class,
App \ Providers \ AuthServiceProvider :: class,
// App \ Szolgáltatók \ BroadcastServiceProvider :: osztály,
App \ Providers \ EventServiceProvider :: class,
App \ Providers \ RouteServiceProvider :: class,

],

Ismét számoltam, és 27 szolgáltatás van felsorolva! Most szüksége lehet mindegyikre, de ez nem valószínű.

Például, véletlenül éppen egy REST API-t építek, ami azt jelenti, hogy nincs szükségem Session szolgáltatóra, View szolgáltatóra stb. És mivel néhány dolgot megteszek, és nem követem a keret alapértelmezett beállításait , Letilthatom az Auth szolgáltatót, a Pagination Szolgáltatót, a Fordítási Szolgáltatót stb. Összességében ezeknek csaknem fele felesleges a használati esetemben.

Vessen egy hosszú, kemény pillantást az alkalmazásra. Szüksége van ezekre a szolgáltatókra? De Isten kedvéért kérjük, ne vakon kommentálja ezeket a szolgáltatásokat, és ne mozduljon el a termelés felé! Futtasson minden tesztet, ellenőrizze a dolgokat kézzel a fejlesztőgépeken és az átmeneti gépeken, és nagyon paranoiás legyen, mielőtt meghúzza a ravaszt. ��

Legyen bölcs a köztes szoftverekkel együtt

Ha a bejövő webes kérés egyéni feldolgozására van szüksége, a válasz egy új köztes szoftver létrehozása. Kísértésnek tűnik megnyitni az app / Http / Kernel.php fájlt, és a köztes szoftvert ragasztani az interneten vagy az api veremben; Ilyen módon az alkalmazásban elérhetővé válik, és ha nem zavaró tevékenységet végez (például naplózza vagy értesíti).

Az alkalmazás növekedésével azonban a globális köztes szoftverek e gyűjteménye csendes teherré válhat az alkalmazás számára, ha ezek mindegyike (vagy többsége) jelen van minden kérésben, még akkor is, ha erre nincs üzleti ok..

Más szavakkal, vigyázzon az új köztes szoftver hozzáadására / alkalmazására. Kényelmesebb lehet valami globális hozzáadása, de a teljesítménybüntetés hosszú távon nagyon magas. Tudom, hogy milyen fájdalmat kell szenvednie, ha minden alkalommal, amikor új változás történik, szelektíven alkalmazza a köztes szoftvert, de fájdalmat szívesen vállalok és ajánlom.!

Kerülje az ORM-et (időnként)

Noha az Eloquent a DB-interakció számos aspektusát kellemessé teszi, a sebesség árán jár. Mapperként az ORM-nek nemcsak be kell szereznie rekordjait az adatbázisból, hanem el kell készítenie a modellobjektumokat és hidratálnia (kitölteni őket) oszlopadatokkal.

Tehát, ha egyszerű $ user = User :: all () felhasználót használ, és mondjuk, 10 000 felhasználó van, akkor a keretrendszer 10 000 sort fog lehívni az adatbázisból, és belsőleg 10 000 új felhasználót () készít, és tulajdonságait kitölti a vonatkozó adatokkal . Ez a színfalak mögött hatalmas munkát végez, és ha az adatbázis az, ahol az alkalmazásod 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 karika fölé kell ugrania, és bezárásokat kell írni bezáráskor, és mégis eredményes lekérdezéssel kell végeznie. Ilyen esetekben a DB :: raw () készítése és a lekérdezés kézzel történő írása előnyös.

Megyünk ez teljesítménytanulmány, még egyszerű beszúrások esetén is, az Eloquent sokkal lassabb, ahogy a rekordok száma növekszik:

A lehető legnagyobb mértékben használja a gyorsítótárat

A webes alkalmazások optimalizálásának egyik legjobban őrzött titka a gyorsítótárazás.

Az inicializálás nélküli gyorsítótárazás a drága eredmények előzetes kiszámítását és tárolását jelenti (a CPU és a memóriahasználat szempontjából drága), és egyszerűen visszaadja azokat, amikor ugyanaz a lekérdezés megismétlődik.

Például egy e-kereskedelmi áruházban előfordulhat, hogy a 2 millió termékkel találkozunk, az embereket általában az érdekli, hogy frissen készletesek, egy bizonyos árkategórián belül és egy adott korosztály számára. Ebből az információból az adatbázis lekérdezése pazarlás – mivel a lekérdezés nem változik gyakran, jobb ezeket az eredményeket olyan helyre tárolni, ahova gyorsan hozzáférhetünk..

A Laravel többféle típusú beépített támogatást nyújt caching. A gyorsítótárazási meghajtó használatán és a gyorsítótárazási rendszer alapjaktól való felépítésén kívül érdemes lehet néhány Laravel csomagot használni, amelyek megkönnyítik modell gyorsítótárazása, lekérdezés gyorsítótárazása, stb..

De ne feledje, hogy egy bizonyos egyszerűsített használati eseten túl az előre beépített gyorsítótár-csomagok több problémát okozhatnak, mint megoldják.

Előnyösebben a memóriában lévő gyorsítótárat

Ha gyorsítótáraz valamit a Laravel-ben, akkor számos lehetősége van arra, hogy hol tárolja a kapott gyorsítótárazott számítást. Ezeket a lehetőségeket más néven is ismert gyorsítótár-illesztőprogramok. Tehát, bár lehetséges és teljesen ésszerű használni a fájlrendszert a gyorsítótár eredményeinek tárolására, nem igazán az, ami a gyorsítótárazás.

Ideális esetben a memóriába (teljes RAM-ban élve) gyorsítótárat szeretne használni, például Redis, Memcached, MongoDB stb., Így nagyobb terhelések esetén a gyorsítótárazás létfontosságú felhasználást szolgál, nem pedig szűk keresztmetszetgé válhat..

Most azt gondolhatja, hogy az SSD lemezzel rendelkezik majdnem ugyanaz, mint RAM memóriakártyával, de még csak nem is zárja be. Még informális is referenciaértékek mutassuk meg, hogy a RAM 10-20-szor jobbkal teljesíti az SSD-t, amikor a sebességről van szó.

Kedvenc rendszerem a gyorsítótárazáshoz a Redis. ez nevetségesen gyors (Másodpercenként 100 000 olvasási művelet gyakori), és nagyon nagy gyorsítótárrendszerek esetén a fürt könnyen.

Gyorsítótárban tárolja az útvonalakat

Csakúgy, mint az alkalmazás konfigurációja, az útvonalak az idő múlásával sem változnak, és ideális jelölést jelentenek a gyorsítótárazáshoz. Ez különösen igaz, ha nem tudja elviselni olyan nagy fájlokat, mint én, és a web.php és api.php fájlokat több fájlra osztja. Egyetlen Laravel-parancs csomagolja az összes elérhető útvonalat és megőrzi őket a későbbi hozzáféréshez:

php kézműves út: gyorsítótár

És amikor végül hozzáadja vagy megváltoztatja az útvonalakat, egyszerűen csak tegye:

php kézműves út: tiszta

Képoptimalizálás és CDN

A képek a legtöbb webes alkalmazás szívét és lelkét jelentik. Véletlenleg ők is a legnagyobb sávszélesség-fogyasztók, és a lassú alkalmazások / webhelyek egyik legnagyobb oka. Ha egyszerűen naiv módon tárolja a feltöltött képeket a szerveren, és HTTP-válaszként küldi vissza, akkor hatalmas optimalizálási lehetőséget engedhet megcsúszni.

Első javaslatom az, hogy ne tároljam a képeket helyben – felmerül az adatvesztés problémája, és attól függően, hogy melyik földrajzi régión van az ügyfél, az adatátvitel fájdalmasan lassú lehet..

Ehelyett keressen egy hasonló megoldást Cloudinary amely automatikusan átméretezi és optimalizálja a képeket menet közben.

Ha ez nem lehetséges, használjon valami hasonlót a Cloudflare-hez a gyorsítótár tárolására és a képek kiszolgálására, amíg azokat a szerveren tárolják.

És ha ez még nem lehetséges, sok különbséget jelent a webszerver szoftverének kicsit finomítása az eszközök tömörítéséhez és a látogató böngészőjének a gyorsítótárba helyezéséhez. A következőképpen nézne ki az Nginx-konfigurációrészlet:

szerver {

# fájl csonkítva

# gzip tömörítési beállítások
gzip tovább;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied bármilyen;
gzip_vary tovább;

# böngésző gyorsítótár vezérlése
hely ~ * \. (ico | css | js | gif | jpeg | jpg | png | woff | ttf | otf | svg | woff2 | eot) $ {
lejár 1d;
access_log off;
add_header Pragma public;
add_header Cache-Control "nyilvános, maximális életkor = 86400";
}
}

Tudom, hogy a képoptimalizálásnak semmi köze nincs Laravelhez, ám ez egy egyszerű és erőteljes trükk (és ezt gyakran elhanyagolják), amely nem tudott segíteni.

Autoloader optimalizálás

Az automatikus töltés egy ügyes, nem túl régi szolgáltatás a PHP-ben, amely vitathatóan megmentette a nyelvet a végzettől. Ennek ellenére a megfelelő osztály keresése és betöltése egy adott névtér karakterláncának megfejtésével időt vesz igénybe, és elkerülhető a termelési telepítésekben, ahol a nagy teljesítmény kívánatos. A Laravel ismét egyutas parancsú megoldást kínál erre:

zeneszerző telepítése –optimize-autoloader –no-dev

Barázzon a sorokkal

A várólisták hogyan dolgozza fel a dolgokat, ha sok ilyen van, és mindegyik néhány milliszekundum alatt elkészül. Jó példa az e-mailek küldése – a webes alkalmazásokban széles körben elterjedt eset az, ha néhány értesítési e-mailt lő le, amikor a felhasználó valamilyen műveletet végrehajt..

Például egy újonnan bevezetett termékben érdemes lehet a cég vezetését (kb. 6-7 e-mail címet) értesíteni, ha valaki egy bizonyos értéket meghaladó megrendelést ad. Feltételezve, hogy az e-mail átjáró 500 ms-ban képes válaszolni az SMTP kérésére, jó 3-4 másodperces várakozásról beszélünk, amíg a megrendelés megerősítése be nem lép. Egy igazán rossz UX-elem, biztos vagyok benne, egyetért.

A megoldás az, hogy a feladatokat a beérkezésük után tárolja, mondja el a felhasználót, hogy minden jól ment, és később (néhány másodpercig) dolgozza fel őket. Hiba esetén a sorban lévő feladatokat megismételhetjük néhányszor, mielőtt sikertelennek nyilvánítanánk.

Kredit: Microsoft.com

Míg a sorba rendező rendszer egy kicsit bonyolítja a beállítást (és némi felügyeleti terhet jelent hozzá), elengedhetetlen egy modern webes alkalmazásban.

Eszköz optimalizálás (Laravel Mix)

A Laravel alkalmazásban lévő összes előtér-eszköz esetében kérjük, győződjön meg arról, hogy van-e egy csővezeték, amely összeállítja és minimalizálja az összes eszközfájlt. Azoknak, akik kényelmesek a csomagolórendszerre, például a Webpack, a Gulp, a Parcel stb., Nem kell zavarniuk, de ha még nem csinálják ezt, Laravel Mix szilárd ajánlás.

A Mix egy könnyű (és tisztességesen, és őszintén szólva!) Csomagolóeszköz a Webpack körül, amely gondoskodik az összes CSS, SASS, JS stb. Fájl létrehozásáról. Egy tipikus .mix.js fájl lehet ilyen kicsi, és még mindig csoda:

const mix = igényelni (‘laravel-mix’);

mix.js (‘erőforrások / js / app.js’, ‘public / js’)
.sass (‘erőforrások / 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 shebang-ről, ha készen állsz a termelésre és futtatsz az npm run produkciót. A Mix nem csak a hagyományos JS és CSS fájlokkal foglalkozik, hanem a Vue és React összetevőkkel is, amelyek az alkalmazás munkafolyamata során előfordulhatnak..

Több információ itt!

Következtetés

A teljesítmény optimalizálása inkább művészet, mint tudomány – fontos, hogy megismerjük, hogyan és mennyit kell tennünk, mint amit tennünk. Ennek megfelelően nincs vége annak, hogy mekkora és mit lehet optimalizálni egy Laravel alkalmazásban.

De bármit is csinál, szeretnék néhány elválási tanácsot adni neked – az optimalizálást akkor kell megtenni, ha van egy megalapozott oka, és nem azért, mert jól hangzik, vagy mert paranoidnak tartja az alkalmazás teljesítményét 100 000+ felhasználó felett, míg a valóságban csak 10 van.

Ha nem biztos abban, hogy optimalizálnia kell-e alkalmazását, nem kell rúgnia a közmondási hornetek fészkét. Egy működő alkalmazás, amely unalmasnak érzi magát, de pontosan azt teszi meg, amire szüksége van, tízszer kívánatosabb, mint egy olyan alkalmazás, amelyet mutáns hibrid szupergépgé optimalizáltak, de időnként lassan esik le..

És hogy az newbiew Laravel mesterré váljon, nézd meg ezt online tanfolyam.

Az alkalmazások sokkal, sokkal gyorsabban futhatnak! ��

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