Szóval az alkalmazásunknak van egy halom backendje amiket igen frekventáltan használ (cms meg satöbbi), főleg (de nem kizárólag) web services alapú dolgok. Egy nagy közös jellegzetességük van: döglassú mind. Főleg a network delay sok, mert amikor meghívok egy remote objektumon egy metódust az általában egy még távolabbi metódust hív. Nem túl szerencsés, de ez van.
Erre persze már a kezdetek kezdetén gondoltak a fejlesztők, és egy tucat helyre betettek a hívás elé valamilyen cache-t.
Ez is megoldotta a teljesítmény problémákat, viszont az ilyen kód mennyisége igen szép volt sor-számban mérve, ezért keresni kezdtem más lehetőséget. Az igazából alapötlet volt, hogy a cache és a tulajdonképpeni kód az legyen egymástól elválasztva, azaz pl egy aop interceptor. Van a springmodules cucc, de abban nem találtam meg mindent kellene, úgyhogy összedobtam egy saját AOP interceptort, amit a read-only szolgáltatások elé be lehet szúrkálni a spring applicationcontext-ben.
Ilyeneket tud:
- Persze független attól az komponenstől, amire ráhúzzuk.
- Lehessen konfigurálni hogy mire lockoljon. Például egyes szolgáltatások teljesen befordulnak, ha egynél több kéréssel traktáljuk őket, úgyhogy konfigurálható hogy a hívás paramétereire, vagy az egész instance-re, vagy egyáltalán ne is lockoljon.
- Felhasználók speciális felületen keresztül ki is törölhetik, hogy lássák a változtatásaik eredményét. Nagyon türelmetlen népek.
- Konfigolható hogy melyik hívás eredménye meddig érvényes a memóriában.
- Egy szál ellenőrzi a "már majdnem" elévült adatokat és frissíti - azaz újra hívja a döglassú backendet, így a néha végrehajtott frissítés nem blokkol le egy user request kiszolgálását és nem rajzol cikk-cakkokat a terhelési teszt egyébként kellemes eredményeire.
- Terhelési teszt közben történt is egy kis baleset: rosszul konfigoltam egy cache-t és megtekertem vele egy szolgáltatást, amiből csak egy van. Azaz live. Ez ilyen szent tehén rendszer, tilos hozzányúlni, szóval nem arattam vele osztatlan sikert.
