ugrás a tartalomhoz

a legjobb teljesítmény titka

kalamona · 2008. Feb. 23. (Szo), 16.14
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.

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?
 
1

korai optimalizálás

Hodicska Gergely · 2008. Feb. 23. (Szo), 19.43
Pont a Drupal hír kapcsán lett egy ilyen: http://drupal.org/node/222884.

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.

SQL vs fájl
Szerintem erre nem lehet egyértelmű választ adni. Egyrészről maga a DB is a végén egy fájl, és az ebben a fájlban lévő adatot a DB keresztül egy lényegesen bonyolultabb protokolon keresztül éred el, mintha csak simán beolvasnád a fájlból. Mégis nem véletlenül van DB, sok esetben jobban jársz vele (lényegesen okosabb lockolási algoritmusok vannak pl. benne, mint amit amagadnak csinálnál, plusz a funkcionalitás), de azért lehet olyan feladat, ahol jobban jársz egy jól szervezett fájlstruktúrával.

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..

hívási "verem", egymásbaágyazott adatszerkezetek:
Itt szerintem csak valami nagyon extrém túlhasználat esetén lehetne az, hogy a jól szervezettség lassítja jelentősen a kódot. Írj könnyen karbantartható, átlátható, flexibilis kódot, majd ha a profile során találsz olyan pontokat, ahol gond van, akkor ott érdemes agyalni, hogy hogyan lehetne gyorsítani. Általában a korai optimalizáció nem jó tanácsadó. Persze ha van egy kis időd, akkor kitalálhatsz jól bevált formulákat, és méricskélhetsz, hogy két ekvivalens megoldás közül melyiket érdemes használni.

ez lenne a legfontosabb szempont?
Egyrészt szerintem nem is teljesen jó irány ez (pl. az ő tesztjükben is opcode cahce esetén alig volt változás, és szerintem egy IO terhelt gép esetén még rosszabb is lett volna), másrészt egy a teljes futási idő csak egy kis szeletén belül optimalizációról szól, ezáltal elég kicsi a hatása a teljes futási időre nézve. Kb. talán elmondható, hogy alapvetően az adatok kezelésén (DB, fájl, bármi) múlik leginkább a dolog, illetve arról, hogy skálázható megoldásokat alakítasz-e ki.


Üdv,
Felhő
2

Teljesítmény vs skálázhatóság

janoszen · 2008. Feb. 23. (Szo), 21.38
Kérdés hogy mi a fontos. Lehet egy alkalmazás kibe*********szott gyors, ha egy vason hajlandó csak futni és nem tudod szétszedni értelmes darabokra, akkor nem lesz soha képes nagy látogató közönséget ellátni.

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ó.
3

Skálázhatósági tutorial

szaky · 2008. Feb. 24. (V), 09.54
Tééényleg, nincs erről valami cikk, hogy milyen módszerekkel lehet skálázhatóvá tenni egy php-s rendszert? Vagy: nem akar valaki ilyet írni? :)
4

nem egy cikknyi téma

Hodicska Gergely · 2008. Feb. 24. (V), 11.38
Rengeteg anyag van erről a neten, kezdj el keresgélni, olvasgatni. Tudom ajánlani ezt a két könyvet: http://www.amazon.com/Scalable-Internet-Architectures-Developers-Library/dp/067232699X , http://www.oreilly.com/catalog/web2apps . Szintén nagyon kiinduláis alap a http://www.highscalability.com weboldal, ezen kívül vannak a témával kapcsolatos konferenciák, de bármelyik MySQL vagy PHP konfon is előjön ez a téma, elég divatos manapság.

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ő
5

Thx maxime

szaky · 2008. Feb. 24. (V), 13.36
Bár az első két link 404, a harmadig nagyon jónak tűnik, köszönöm a segítséget.
6

azért kitalálhatóak ;)

Hodicska Gergely · 2008. Feb. 24. (V), 14.52
Köszi, javítottam.


Üdv,
Felhő
7

Lehetne...

janoszen · 2008. Feb. 25. (H), 08.21
Akár lehetne is, legalább az alapfogalmakról, de én még amúgy is lógok egy cikkel, úgyhogy inkább hallgatok. :)