a legjobb teljesítmény titka
sziasztok!
szerintetek mi befolyásolja leginkább a php alkalmazások sebességét és milyen mértékben az alábbi tényezők közül:
1. fájlok includeolása:
mennyit lassit a többszöri lemezről olvasás, ha sok kicsi fájlra tagoljuk a progit?
2. memóriában tartott kód mennyisége:
érdemes-e kevés fájlban sok kódot tartani lecsökkentve a lemezhez fordulások számát, cserébe viszont a memóriába kerül sok dolog, aminek csak töredéke fut le adott esetben. ilyenkor a php benn is tartja azokat a memóriában, vagy mindent felszabadít azonnal?
3. sql lekérdezések / fájlokból olvasások száma:
az előző kettőhöz képest szűk vagy tág keresztmetszet ez? gyorsabb e a lemezről olvasni, vagy sokkal gyorsabb mindent amit csak lehet adatbázisban tartani?
4. hívási "verem", egymásbaágyazott adatszerkezetek:
vagyis ha sok rövid függvényem / metódusom van, és emiatt sokszoros "mélységű" egymásból való hívások történnek rendszeresen az mennyire lassit? adatszerkezeteknél sokkal lassabb egy nagy több dimenziós tömbbe szervezni mint több kisebbe? (persze ilyenkor azok feltöltése, elérése lesz gyakoribb)
mennyire nyomnak ezek a latban egymáshoz képest? mivel lehet a legtöbbet nyerni? a drupal 6 bemutatásakor például ki is van emelve hogy tudatosan csökkent az egyszerre memóriában tartott kód mennyisége.
ez lenne a legfontosabb szempont?
■ szerintetek mi befolyásolja leginkább a php alkalmazások sebességét és milyen mértékben az alábbi tényezők közül:
1. fájlok includeolása:
mennyit lassit a többszöri lemezről olvasás, ha sok kicsi fájlra tagoljuk a progit?
2. memóriában tartott kód mennyisége:
érdemes-e kevés fájlban sok kódot tartani lecsökkentve a lemezhez fordulások számát, cserébe viszont a memóriába kerül sok dolog, aminek csak töredéke fut le adott esetben. ilyenkor a php benn is tartja azokat a memóriában, vagy mindent felszabadít azonnal?
3. sql lekérdezések / fájlokból olvasások száma:
az előző kettőhöz képest szűk vagy tág keresztmetszet ez? gyorsabb e a lemezről olvasni, vagy sokkal gyorsabb mindent amit csak lehet adatbázisban tartani?
4. hívási "verem", egymásbaágyazott adatszerkezetek:
vagyis ha sok rövid függvényem / metódusom van, és emiatt sokszoros "mélységű" egymásból való hívások történnek rendszeresen az mennyire lassit? adatszerkezeteknél sokkal lassabb egy nagy több dimenziós tömbbe szervezni mint több kisebbe? (persze ilyenkor azok feltöltése, elérése lesz gyakoribb)
mennyire nyomnak ezek a latban egymáshoz képest? mivel lehet a legtöbbet nyerni? a drupal 6 bemutatásakor például ki is van emelve hogy tudatosan csökkent az egyszerre memóriában tartott kód mennyisége.
A Drupal 6-ban a legtöbb modult kisebb fájlokra bontottuk szét, csak azt betöltve, amire éppen szükség van, így kevesebb PHP kóddal kell foglalkoznia a szervernek.
ez lenne a legfontosabb szempont?
korai optimalizálás
Az én tesztemben eléggé egyértelműen az jött ki, hogy opcode cache használata mellett célszerű nagyobb egységekben betölteni a kódokat. A memória vonzatát nem néztem a dolognak, de érzésem szerint az esetlegesen fölöslegesen include-olt kód nem fogja számottevően befolyásolni a memória foglalást. Plusz tapaszalatom szerint sohasem volt a memória a szűk keresztmetszet nagyobb terhelésű oldalak esetében.
Viszont a memóriához képest mind a fájl, mind a DB egy csiga, szóval a kulcs, hogy amit csak tudsz, azt cache-eld, és csak akkor nyúlj a háttértárhoz, ha nagyon muszáj. Plusz köss kompromisszumokat, 5 legfrissebb hírt elég percenként lekérdezni, nem kell full real time változzon stb..
Üdv,
Felhő
Teljesítmény vs skálázhatóság
Ezzel szemben a skálázhatóság azt jelenti, hogy alá lehet tenni 100 szervert úgy, hogy értelmesen el tudod osztani a terhelést és ebből nem lesz probléma.
További szempont az optimalizálásban, hogy vajon a Te munkaidőd kerül többe a cégnek vagy egy erősebb gép? Mert ez sem elhanyagolható.
Skálázhatósági tutorial
nem egy cikknyi téma
Az alapelv az kb. annyi, hogy mindig úgy próbálj meg gondolkodni minden funkció esetén, hogy ha kevésnek bizonyul egy gép a feladat ellátására, akkor bármikor tudj betenni mellé egy másikat, és az alkalmazásodon ehhez ne kelljen változtatni. Általában a legmacerásabb a DB skálázhatósága, mert pl. MySQL esetében nincs igazi master-master replikáció, ezért általában alkalmazás szinten kell megoldani az adatok particionálását, erre viszont nincs recept, mindig az adott rendszernek megfelelően lehet elvégezni.
Üdv,
Felhő
Thx maxime
azért kitalálhatóak ;)
Üdv,
Felhő
Lehetne...