A gyűjtemény a tippeket és tények optimalizálásához php-script
Habrahabr kiderült, hogy nem csak egy nagyszerű cikket a PHP optimalizálás.
Az egyik fő szempont a siker minden internetes forrás a sebessége és a felhasználókkal egyre igényesebb ennek a kritériumnak. Optimalizálása a php-skiptov - az egyik módszer, hogy biztosítsa a sebesség a rendszer.
Ebben a cikkben szeretném bemutatni a nyilvánosság gyűjteménye tippeket és tények scriptek optimalizálás. Összegyűjtött rólam elég hosszú, ez alapján több forrás és a személyes kísérletek.
Miért van egy gyűjtemény a tippeket és a tények, hanem kemény és gyors szabályokat? Mert, mint Meggyőződésem, hogy van „abszolút korrekt optimalizálás”. Sok a módszerek és szabályok ellentmondásosak és megvalósíthatatlannak őket. Ki kell választani egy sor olyan módszereket, amelyek alkalmazása elfogadható a biztonság veszélyeztetése nélkül és kényelmes. Vettem a helyzetét ajánló, ezért én tippeket és tények, amelyek lehet megfigyelni, és nem tudja betartani.
A félreértések elkerülése érdekében osztottam a tippeket és tények 3 csoportba:
- Optimalizálása a szint a logika és a szervezet alkalmazások
- kód optimalizálása
- haszontalan optimalizálás
Csoportok vannak jelölve próbaidőt, és néhány elem annak tudható be, több, mint egy ezek közül. A számok az átlagos szerver (LAMP). A cikk nem foglalkozik kapcsolatos kérdések hatékonyságát a különböző külső technológiák és keretek, mivel ez a téma egy másik vita.
Optimalizálása a szint a logika és a szervezet alkalmazások
Sok a tippeket és tényekkel kapcsolatos optimalizálása a nevében, nagyon fontos, és ad egy nagyon nagy nyereség az időben.
- Folyamatosan profilalkotás a kódot a szerveren (Xdebug) és a kliens (gyújtogató), amely felfedi a szűk térben kódot
Meg kell jegyezni, hogy szükség van a profil és a szerver és a kliens részéről, mivel nem minden szerver hiba észlelhető a szerveren. - Az összeg a programban használt felhasználói funkció nincs hatással az arány
Ez lehetővé teszi, hogy a program számtalan felhasználó által definiált függvények. - Aktívan használják az egyedi funkciók
A pozitív hatás érhető el annak a ténynek köszönhető, hogy a funkciók a műveleteket végzik csak lokális változók. Ennek hatása nagyobb, mint a hívások költségét a felhasználó által definiált függvények. - „Kritikusan súlyos” funkció, kívánatos, hogy végre egy idegen nyelvet, mint egy kiterjesztése a PHP programozás
Megköveteli programozási ismeretek egy idegen nyelvet, ami jelentősen megnöveli a fejlesztési időt, de ugyanakkor lehetővé teszi, hogy a technikák használatára PHP lehetséges. - Feldolgozás statikus html fájl gyorsabb, mint értelmezett php fájl
A különbség az időalapú ügyfél lehet körülbelül 1 másodpercig, így van értelme, egyértelmű szétválasztása statikus és PHP generált oldalak segítségével. - A méret a feldolgozott (csatlakoztatva) fájl befolyásolja azt a sebességet
Körülbelül 2 Kb feldolgozás minden 0.001 másodperc töltött. Ez a tény arra kényszerít bennünket, hogy végezze el a minimalizálás script kódot át a termelést kiszolgáló. - Lehetőleg ne használja folyamatosan require_once vagy include_once
Ezeket a funkciókat kell használni, ha van lehetősége újra a fájl olvasása, más esetben kívánatos, hogy használja a szükség, és tartalmazza. - Amikor elágazás algoritmus, ha vannak tervek, amelyeket nem lehet feldolgozni, és az összeg nagyságrendileg 4 KB vagy több, optimálisan össze őket a közé.
- Kívánatos, hogy az adatokat az ügyfél által küldött
Ez azért van, mert amikor ellenőrzi az adatokat a kliens oldalon, élesen csökkent a kérelmek száma helytelen információt. vizsgálati adatok a kliens felépített rendszer elsősorban használatával JS és merev formában elem (kiválasztás). - Kívánatos, hogy a nagy DOM struktúrák adathalmazok építeni az ügyfél
Ez egy nagyon hatékony módszer optimalizálására, amikor dolgozik kijelző nagy mennyiségű adat. Ennek lényege a következő: a szerver előkészíti az adatokat tömb és továbbítjuk az ügyfél, valamint az építőiparban DOM struktúrákat JS funkciókat. Ennek eredményeként a terhelést részben újra elosztják a szerver a kliens. - Alapuló rendszerek AJAX technológia, sokkal gyorsabban, mint azok a rendszerek, amelyek nem használják ezt a technológiát
Ez annak köszönhető, hogy csökken a termelés volumene és újraelosztását az ügyfél terhelést. A gyakorlatban az a sebesség, AJAX rendszerek 2-3-szor nagyobb. Megjegyzés: AJAX, viszont létrehoz egy sor korlátozást az egyéb optimalizálási módszerek, például dolgozni a puffert. - Kézhezvételét követő lekérdezés mindig vissza semmit, akkor is szakadék
Ellenkező esetben az ügyfél fog küldeni egy hiba oldalt, amely súlya néhány kilobyte. Ez a hiba nagyon gyakori az AJAX rendszereket. - Adatok visszakeresése fájl gyorsabb, mint az adatbázisból
Ez főként annak köszönhető, hogy a költségek az adatbázis kapcsolat. Meglepetésemre egy nagy százalékban programozók mániás tárolja az összes adatot az adatbázisban, akkor is, ha a fájlok gyorsabb és udobnee.Zamechanie: fájlokat tárolhat adatokat, amelyek nem végeztek a keresést, különben az adatbázist kell használni. - Ne hozzuk létre a kapcsolatot az adatbázis, anélkül, hogy
Okokból számomra ismeretlen, sok programozó csatlakozni az adatbázishoz a szakaszában beállítás az olvasás, bár lehet, továbbra is ezt az adatbázis lekérdezések. Ez egy rossz szokás, mely költségek átlagosan 0,002 másodperc. - Használja tartós kapcsolatot egy adatbázis egy kis számú egyidejűleg aktív ügyfelek
Idő haszon által okozott költségek hiánya az adatbázis kapcsolat. Az időeltolódás körülbelül 0,002 másodperc. Megjegyzés: a nagy számú felhasználó állandó kapcsolatot nem kívánatos. Ha állandó kapcsolatokat kell lennie egy olyan mechanizmust, hogy véget kapcsolatokat. - A fejlett adatbázis-lekérdezések gyorsabb, mint néhány egyszerű
Az időeltolódás sok tényezőtől függ (az adatok mennyisége, az adatbázis konfigurációs és így tovább.), És mérjük ezred és századok néha másodperc. - A számítások oldalán DBMS gyorsabb számítási PHP oldali adatok az adatbázisban tárolt
Ez okozza tényező, hogy a számítási oldalán PHP szükséges két kéréseket DB (Adatlekérdezés és frissítés). A időkülönbség sok tényezőtől függ (az adatok mennyisége, adatbázis konfigurációs és így tovább.), És mérjük ezrelékben és századmásodperc alatt. - Ha a minta adatokat az adatbázis ritkán változnak, és az ezen adatok húzott sok felhasználó, akkor van értelme, hogy mentse a minta adatok fájlba
Például, ha az alábbi egyszerű megközelítés: megszerezni minta adatokat az adatbázisból, és mentse el a szerializált tömb egy fájlt, akkor minden felhasználó az adatokat a fájlból. A gyakorlatban ez optimalizálási technikát tud adni egy többszörös növekedést a sebesség a szkript. Megjegyzés: Amikor ezt a módszert kell írniuk az eszközöket építeni, és módosítani az adatokat tárolt fájl. - Cache adat, amely ritkán változik, a memcached
időmegtakarítás jelentős lehet. Megjegyzés: hatékonyan caching statikus adatok dinamikus adatokat a hatás csökken, és lehet negatív. - Munka nélkül tárgyak (nincs OOP) gyorsabb, mint a munka tárgyak, nagyjából háromszor
Memory „megesznek”, és így tovább. Sajnos, a PHP értelmező nem tud dolgozni a PFSZ-szel, amilyen gyorsan csak közönséges funkciókat. - A nagyobb méret tömbök, annál lassabban működnek
Időveszteség keletkezik feldolgozásából származó beágyazott struktúrák.
kód optimalizálása
Ezek a tények adnak tanácsot és jelentéktelen, mint az előző csoport sebesség növelése, hanem együttesen, ezek a technikák egy jó végeredmény időben.
haszontalan optimalizálás
Számos optimalizálási módszerek a gyakorlatban nincs nagy hatással a gyorsaság a szkriptek (egyszeri nyereség kevesebb, mint 0.000001 másodperc). Ennek ellenére ezt az optimalizálási gyakran vita tárgya. Hoztam ezeket a „haszontalan” a tényeket, hogy akkor majd nem fizet nekik nagy figyelmet írásakor kódot.
Végezetül szeretném megismételni, hogy a tippeket és tények A megadott nekem nem abszolút, és annak fontosságát, hogy azok használatát függ a konkrét helyzetet. Nem szabad elfelejteni, hogy a script optimalizálás csak egy kis része az egész eljárás és optimalizálása gyakran lehet békében élni anélkül, hogy a fenti tanácsokat.