3.3. Optimalizálási lehetőségek azonosítása

Foglaljuk most össze, hogyan is lehet azonosítani azokat a pontokat programjaink futása során, amelyek erőforrásigénye csökkenthető:

Függvények optimalizálása:

• A hívások számának csökkentése: lehet, hogy nem minden esetben kell meghívni egy függvényt a cikluson belül, mert az általa előállított kimenetet nem használjuk fel minden esetben. Példa: kilistázzuk a felhasználókat, s a 18 évesnél öregebbek mellé odaírjuk, hogy hány napja születtek. Fölösleges tehát mindenkinél kiszámolni, hogy hány napja született, elég csak az adott felhasználói körnél. Általánosságban mindez akkor használható, ha a feltételvizsgálat nem igényel több számítási kapacitást, mint az adott művelet felesleges elvégzése.
• Sokszor meghívott függvények működésének optimalizálása: ha ciklusban hívunk függvényeket, akkor a hívott függvényben tudunk a legkisebb erőfeszítéssel használható eredményt elérni. Könnyen találhatunk belül felesleges függvényhívást, vagy egy ciklust, ami nem áll le, ha megtalálta az eredményt, hanem végigfut.
• Ne használjunk feleslegesen sok változót amiatt, hogy mindig beszédes változókkal dolgozhassunk. Kevés gyorsulást eredményez az átlagos méretű kódoknál, mégis úgy tekinteni rájuk, mint a típusos nyelvekben, ahol deklarálni kell őket a függvény elején (és jobban látszik, ha túl sok változót használunk).
• Ha arra leszünk figyelmesek, hogy egy beépített függvény lassú, gondoljuk végig, hogy jól paramétereztük-e, illetve végső esetben nézzünk utána a vonatkozó tapasztalatoknak, alternatív függvény vagy módszer után kutatva.

Adatbázis-lekérdezések optimalizálása

• Lekérdezéseinkben mindig csak azok a mezők szerepeljenek, amelyekre valóban szükségünk van, a csillagot (SELECT * FROM) ne használjuk.
• A lekérdezéseket szépen tagoljuk, mivel így később is egyből észrevesszük, ha egy már szükségtelenné vált mezőt is lekérdezünk.
• Ha az adatbázisból jövő adatokat szűrni kell, vagy plusz mezőket, értékeket kell kalkulálnunk, bízzuk a feladatot az adatbázisra. Ne az adatokat lehozó ciklusban számoljuk ki ezeket, mivel egyrészt nem ide tartoznak ezek a számítások, másrészt pedig általában lassabbak is.
• Lekérdezéseinkhez határozzunk meg LIMIT-et, és kezeljük azt az esetet, amikor a megjelenített adatokat több lapra kell tördelni. Kerüljük a sok elem listázását például fórumhozzászólások megjelenítésekor, mivel amellett, hogy nem praktikus, a felhasználók számára is átláthatatlan, s feleslegesen sok memóriát és processzoridőt igényelhet.

Az erőforrás-szempontból problémás egységek azonosítása alapvetően intuitív feladat, amennyiben egy profiler eszközzel meg tudtuk határozni, hogy mely függvénnyel vagy programrésszel van a probléma. Némi kísérletezés után egyből láthatjuk, hogy sikerült-e a jó irányba elmozdulni, s ha esetleg nem, még mindig visszatérhetünk egy korábbi verzióra.
Ha a lassúság olyan szintű, hogy már döntő mértékben befolyásolja a szerver terhelését (például nagy látogatottságú oldalak esetében), akkor gondolkodjunk el azon, hogy valóban szükséges-e a megjelenített adatokat minden oldalletöltéskor kiszámítani. Amennyiben nem, készíthetünk az adatokból egy kimutatást, vagyis egy összesítő táblát például óránkénti futással időzítve, vagy viszonylag ritkán változó tartalmak esetén változáskor vagy időzítve generálhatunk HTML fájlokat, kikerülve ezzel az oldalletöltésenkénti dinamikus lapgenerálást (és az adatbázisból való lekérdezéseket).

3.4. Terheléses teszt a profilkészítés támogatására

Ha szeretnénk életszerűbb körülmények között megvizsgálni rendszerünket annak érdekében, hogy a gyenge pontokat még könnyebben azonosítani tudjuk, két lehetőségünk kínálkozik. Az első lehetőség, hogy asztali környezetben készítünk egy alkalmazást, ami beépített böngészőjével egy listába felvett URL-halmazon megy végig véletlenszerű időközönként. Ha van még néhány órányi időnk, akkor szálakba is tehetjük az alkotásunkat, így virtuális felhasználóink is lehetnek.
Ha azonban egy komolyabb eszközre vágyunk, választhatjuk a Webserver Stress Tool-t (http://www.paessler.com/webstress), amellyel virtuális felhasználóink kattinthatnak az alkalmazás listájába korábban felvett URL-ekre. Ha egy komplett honlapmotort szeretnénk tesztelni, érdemes modulonként rögzíteni az URL-eket és a beállításokat, így a teszteset reprodukálhatóvá válik, alkalmassá téve tesztrendszerünket a kódmódosítások eredményének figyelemmel kísérésére.

Az alkalmazás demó verziója 10 virtuális felhasználóra korlátozza a tesztelést; a teljes verzió pedig 200 dollárba kerül. A Webserver Stress Tool a felhasználói felülete szempontjából korántsem kényelmes, de tökéletesen teljesíti feladatát anélkül, hogy túl nagy töbletterhelést okozna. A processzor-kihasználást figyelemmel kísérhetjük, így ha bármikor elérné a 100%-ot a teszt során, módosíthatunk a beállításokon (a virtuális felhasználók számán, a kattintások között eltelt átlagos időtartamon), hogy hiteles teszteredményeket állítsunk elő. Érdemes figyelni a szabad memória mennyiségét is, nehogy emiatt torzuljanak teszteredményeink az ismétlődő tesztelések során.

A projekt méretétől függően használhatunk professzionális eszközöket is, amilyen a Mercury Winrunner és Loadrunner, ezekkel azonban hiába lehet szinte bármilyen feladatot megoldani, áruk rendkívül magas.

4. Összefoglalás

Korábban láttuk, hogy a profilkészítés célja az, hogy segítsen alkalmazásainkat hatékonyabbá tenni úgy, hogy a kódbeli változtatások hozadéka az egyes tesztfuttatások során nyomon követhető legyen. Ehhez biztosítanunk kell a teszteset reprodukálhatóságát, ami speciálisan erre a célra készült alkalmazás nélkül sajnos nehézkesen oldható meg, hiszen ha a rendszer válaszidejét is mérni akarjuk, a teszt okozta terhelésnek ? és így magának a profilnak ? következetesnek kell lennie.
A bemutatott Xdebug és Webserver Stress Tool alkalmazások és a vázolt módszerek egy lehetséges megközelítést képviselnek, s nem tekinthetők minden körülmények között megfelelő megoldásnak. Amennyiben úgy érezzük, hogy a felállított tesztkörnyezet alkalmazása nem eredményez érzékelhető javulást, de mégis vannak gyenge pontok a rendszerben, érdemes kipróbálni a többi említett szoftvert is. Ha viszont így sem találjuk meg a hiba okát, érdemes egy szintet lejjebb épni, és a szerveralkalmazások háza táján szétnézni (Apache, PHP, MySQL) ? de az is lehet, hogy az operációs rendszeren kell még hangolnunk valamit.
A profilkészítés másik hatalmas előnye, hogy segít fejleszteni, hatékonyabbá tenni programozási technikánkat, hiszen erőfeszítéseink pozitív vagy negatív hozadékáról egyből értesülhetünk.

Összességében ajánlott minden rendszerről egy profilt készíteni mielőtt élesbe állnánk, mivel a tesztelésre fordított idő még kisebb, néhány tucat embernapos fejlesztések esetén is elfogadható. Ha pedig több száz embernapos projekteket tekintünk, arányaiban kevés erőforrást igényel a tesztelés folyamata, legalábbis a tervezéshez vagy a programozáshoz viszonyítva. Nem beszélve arról sem, hogy az ügyfélnek átadott profillal elejét vehetjük annak, hogy később minket (illetve rendszerünket) vádoljanak, amennyiben a hosztolásra szánt szerver nem tudja kiszolgálni a kívánt mennyiségű felhasználót (amiben esetleg korábban megegyeztünk).

Általános szabály itt is, hogy a körültekintő tervezés és dokumentálás rengeteg problémától kímélhet meg minket a továbbiakban.