Production performance optimalizáció

A tünet

A napi működés egyik legfontosabb riportja 306 másodperc alatt töltődött be. Öt perc nem egyszerűen lassú: operatív környezetben azt jelenti, hogy az emberek nem használják a riportot. Inkább telefonálnak, külön listát vezetnek vagy emlékezetből döntenek.

A kézenfekvő magyarázat a növekvő adatmennyiség vagy a kevés szerverkapacitás volt. A végrehajtási terv viszont mást mutatott.

Mit mutatott a végrehajtási terv

A lekérdezés logikailag jól elkülönített építőelemekből állt, de több ponton ugyanazokra a költséges köztes eredményekre támaszkodott. A végrehajtási tervből kiderült, hogy az adatbázismotor ezeket nem egyszer számította ki és használta fel újra: több végrehajtási ágon ismételten elvégezte ugyanazokat a kapcsolásokat, szűréseket és összesítéseket.

A forráskód ezért áttekinthetőnek látszott, a tényleges végrehajtás mégis sokszorosan elvégezte ugyanazt a munkát. A szűk keresztmetszet nem egyetlen hibás utasítás volt, hanem a lekérdezés egészének végrehajtási szerkezete.

A változtatás

Az üzleti szabályokhoz nem nyúltunk. A lekérdezést egyértelmű végrehajtási fázisokra bontottuk:

1. A költséges, többször használt köztes eredményeket egyszer állítottuk elő, majd indexelhető struktúrában használtuk tovább.
2. A szűréseket a lehető legkorábbi biztonságos pontra helyeztük.
3. Az indexeket a tényleges összekapcsolási és szűrési mintákhoz igazítottuk.
4. Minden módosításnál összevetettük az eredeti és az új eredményhalmazt.

Az optimalizálás legfontosabb korlátja az volt, hogy a riport jelentése nem változhat. A gyors, de mást számoló lekérdezés nem optimalizálás, hanem hiba.

Az eredmény

Nem kellett nagyobb szerver, adatbáziscsere vagy új riporting-platform. A megoldás a végrehajtási terv helyes értelmezése és a lekérdezés szerkezetének megváltoztatása volt.

Ha a kimutatása öt percig tölt, az sokszor nem a szerver hibája, hanem a lekérdezés szerkezete — és ez a rendszer cseréje nélkül is javítható.