Tippek a php-scriptek optimalizálására
Az internetes erőforrások sikerének egyik fő feltétele a működés sebessége, és minden évben egyre nagyobb követelményeket támasztanak e kritérium. A php-ugrások működésének optimalizálása az egyik módszer, amely biztosítja a rendszer sebességét.
Ebben a cikkben szeretném bemutatni a nyilvánosság számára a szkriptek optimalizálására vonatkozó tippeket és tényeket. A gyűjteményt régóta gyűjtöttem össze, több forrásból és személyes kísérletből áll.
Miért tanácsok és tények gyűjteménye, nem pedig merev szabályok? Mert, mint láttam, nincs "teljesen helyes optimalizálás". Sok technika és szabály ellentmondásos, és lehetetlen teljesíteni őket. Olyan módszert kell választania, amely elfogadható a biztonság és a kényelem veszélyeztetése nélkül. Vettem egy ajánlástervezetet, ezért tanácsom és tények vannak, amelyeket követhet, vagy esetleg nem.
Bármi is volt az összetévesztés, minden tippet és tényt három csoportba osztottam:- Optimalizálás a logika szintjén és az alkalmazás szervezésében
- Kódoptimalizálás
- Hasznos optimalizálás
A csoportokat feltételesen hozzárendelik, és egyes elemek közvetlenül többnek tulajdoníthatók. A számok az átlagos kiszolgálóra (LAMP) vonatkoznak. A cikk nem foglalkozik a különböző, harmadik fél technológiáinak és kereteinek hatékonyságával kapcsolatos kérdésekkel, mivel ez az egyéni viták témája.
Optimalizálás a logika szintjén és az alkalmazás szervezésében
Az optimalizálási csoporthoz kapcsolódó tippek és tények közül sok nagyon fontos és nagyon nagy nyereséget biztosít az időben.
- Folyamatosan profilozza a kódot a kiszolgálón (xdebug) és az ügyfélen (firebug), ami feltárja a kód szűk keresztmetszetét
Meg kell jegyeznünk, hogy mind a kiszolgáló, mind a kliens részt kell profilozni, mivel nem minden kiszolgálóhiba található a szerveren. - A felhasználói funkciókban használt szám nem befolyásolja a sebességet
Ez lehetővé teszi, hogy végtelen számú felhasználó által meghatározott funkciót használjon a programban. - Aktívan használhatja az egyéni funkciókat
A pozitív hatást azért érik el, mert a művelet funkciói csak helyi változókon végezhetők el. Ennek hatása nagyobb, mint a felhasználó által meghatározott funkciók hívásának költsége. - A "kritikusan nehéz" funkciókat lehetőleg egy harmadik fél programozási nyelvén kell végrehajtani a PHP kiterjesztése formájában
Ehhez programozási készségekre van szükség egy harmadik fél nyelvén, ami nagymértékben növeli a fejlesztési időt, ugyanakkor lehetővé teszi a PHP képességeken kívüli technikák használatát. - A statikus html fájl feldolgozása gyorsabb, mint egy értelmezett php fájl
Az ügyféllel szembeni különbség kb. 1 másodperc lehet, ezért érthető, hogy egyértelműen elkülönül a statika és a PHP által generált oldalak. - A feldolgozandó fájl (plug-in) mérete befolyásolja a sebességet
Körülbelül minden 2 KB feldolgozás 0,001 másodpercet tölt. Ez a tény arra kényszerít minket, hogy minimálisra csökkentsük a forgatókönyvi kódot, amikor a gyártókiszolgálóra kerülnek. - Próbálkozzon nem mindig a require_once vagy a include_once használatával
Ezeket a függvényeket akkor kell használni, ha újra olvashatja a fájlt, különben kívánatos a használat igénybevétele és bevitele. - Algoritmus elágazásakor, ha vannak olyan konstrukciók, amelyek nem képesek feldolgozni, és méretük körülbelül 4 KB vagy annál nagyobb, akkor célszerűbb az is, hogy összekapcsoljuk azokat.
- Kívánatos az ügyfélnek küldött adatok ellenőrzése
Ennek az az oka, hogy az ügyfél oldalán végzett adatok ellenőrzésekor a helytelen adatokkal rendelkező kérelmek száma drasztikusan csökken. Az ügyfelek adatellenőrzési rendszereit elsősorban a JS és a merev alakelemek (kiválasztás) segítségével állítják elő. - Kívánatos nagy DOM konstrukciókat készíteni az adatkészletekre az ügyfél számára
Ez egy nagyon hatékony módja az optimalizálásnak, amikor nagy mennyiségű adat megjelenítésével dolgozik. A lényege a következő: a kiszolgálón egy sor adat áll rendelkezésre, és az ügyfélnek továbbítódik, a DOM-konstrukciók megépítése pedig a JS-funkciók számára biztosított. Ennek eredményeképpen a terhelés részben újrafelosztásra kerül a szerverről az ügyfélre. - Az AJAX technológiára épülő rendszerek sokkal gyorsabbak, mint azok a rendszerek, amelyek nem használják ezt a technológiát
Ez annak köszönhető, hogy csökken a kimeneti mennyiségek és a terhelés újraelosztását az ügyfélnek. A gyakorlatban az AJAX rendszerek sebessége 2-3-szorosa. Megjegyzés: Az AJAX viszont számos korlátozást hoz létre más optimalizálási módszerek használatával, például a pufferrel való együttműködésben. - Amikor megkapja a kérést, mindig küldjön valamit, akkor is helyet foglalhat
Ellenkező esetben az ügyfelet egy több kilobájt súlyú hibaoldalt küldenek. Ez a hiba nagyon gyakori az AJAX technológiát használó rendszereknél. - Adatgyűjtés gyorsabban, mint egy adatbázisból
Ez nagyrészt az adatbázisba való bekötés költségeinek köszönhető. Meglepetésemre, a programozók óriási hányada manuálisan tárolja az összes adatot az adatbázisban, még akkor is, ha a fájlok használata gyorsabb és kényelmesebb. Megjegyzés: a fájlok olyan adatokat tárolhatnak, amelyeket nem kerestek, különben adatbázisokat használhat. - Ne csatlakozzon az adatbázishoz szükség szerint
Bizonyos ok miatt ismeretlen számomra, hogy sok programozó csatlakozik az adatbázishoz a beállítások leolvasása közben, bár tovább nem kérhetnek az adatbázisra. Ez egy rossz szokás, amely átlagosan 0,002 másodperc. - Használjon állandó kapcsolatot az adatbázishoz kis számú, egyidőben aktív klienssel
Az idõbeli hasznot az adatbázishoz való csatlakozás költségeinek hiánya okozza. Az időeltolódás körülbelül 0,002 másodperc. Megjegyzés: nagyszámú felhasználó számára az állandó kapcsolatok nem kívánatosak. Ha tartós kapcsolatokkal dolgozik, létre kell hozni egy mechanizmust a kapcsolatok teljesítéséhez. - Az összetett adatbázis-lekérdezések használata gyorsabb, mint néhány egyszerű használat
Az időeltolódás sok tényezőtől függ (adatmennyiség, adatbázis-konfiguráció stb.), És ezer, esetenként század, másodperc. - A DBMS oldalán végzett számítások használata gyorsabb, mint a PHP oldalán az adatbázisban tárolt adatok számításai
Ez annak köszönhető, hogy a PHP oldalon ilyen számításokhoz két adatbáziskérelemre van szükség (adatvisszafejezés és módosítás). Az időeltolódás számos tényezőtől függ (adatmennyiség, adatbázis beállítás stb.), És másodpercenként ezredmásodpercenként méri. - Ha az adatbázisból származó mintaadatokat ritkán változtatják meg, és sok felhasználó hozzáfér az adatokhoz, érdemes menteni a mintaadatokat egy fájlba
Például a következő egyszerű megközelítést alkalmazhatja: mintaadatok lekérése az adatbázisból, és fájlok sorba rendezett tömbként történő mentése, majd bármely felhasználó az adatokat használja a fájlból. A gyakorlatban ez az optimális módszer többszörös növekedést eredményezhet a parancsfájl végrehajtásának sebességében. Megjegyzés: Ha ezt a módszert használja, meg kell adnia az eszközöket a fájlban tárolt adatok létrehozásához és módosításához. - Gyorsítótár adat, amely ritkán változik a memcached
Az idő nyeresége nagyon jelentős lehet. Megjegyzés: a gyorsítótár a statikus adatokra hatásos, dinamikus adatok esetén a hatás csökken, és negatív lehet. - Az objektumok nélküli munka (OOP nélkül) gyorsabb, mint a tárgyakkal való munka, körülbelül háromszor
A memória "elfogyasztott" is. Sajnos a PHP-tolmács nem tud olyan gyorsan együttműködni az OOP-val, mint a rendszeres funkciók. - Minél többrétegesebb a tömbök, annál lassabban dolgoznak
Az időveszteség a fészkelő szerkezetek feldolgozásából származik.
Ezek a tippek és tények jelentéktelen sebességnövekedést jelentenek az előző csoporthoz képest, de összességükben ezek a technikák jó időt nyerhetnek.
A gyakorlatban számos optimalizálási módszer nem nagy hatással van a szkriptek végrehajtásának sebességére (az idő-nyereség kevesebb, mint 0,000001 másodperc). Ennek ellenére az ilyen optimalizálás gyakran ellentmondássá válik. Idézem ezeket a "haszontalan" tényeket, hogy ne fordítsanak különös figyelmet a későbbi kódírásra.
Végezetül ismételten emlékeztetni szeretném arra, hogy az általam említett tanácsok és tények nem feltétlenek, és alkalmazásuk jelentősége az adott helyzeten múlik. Nem szabad megfeledkeznünk arról, hogy a szkriptek optimalizálása csak egy kis része az egész optimalizálási eljárásnak, és gyakran lehetséges, hogy csendben éljenek a fenti tippek nélkül.