sessionmeter

Tipikus eset, mint amikor a miliomost holtan találják a vitorlásán, Kolombó már onnantól kezdve csak az örökösével beszélget a filmben, mert tudja, hogy ő ölte meg. Ugyanez a helyzet a cluster teljesítménnyel is, az esetek nagyon magas százalékában a session a tettes. Ezt azért bizonyítani is kell általában, erről szokott szólni a hátralevő unalmas akárhány perc.
Gondoltam lerövidítem a következő bizonygatás hosszát és csináltam egy filtert, ami összediffeli a session-öd a kiszolgálás elötti és utáni állapotát.
Megjegyzések:

1. Nem túl processzor-barát, mert ahhoz hogy meg tudja saccolni, hogy változott-e a session attribútum, ki is kell szerializálnia. Ezt a container-ek másként csinálják, megjegyzik, amikor egy adatot elmentessz a session-be és akkor utána a teljes bean-t újra le kell majd replikálni a többi node-ra, csak ezt persze nem kötik az orrunkra. Régen tipikus hiba volt az, hogy valaki módosított egy session változót és aztán nem tette be a session-be újra. Ilyenkor az appszerver nem replikálta le, mert nem tudta hogy kell. 1 node-on elmegy, clusteren furcsa problémákat okoz.
   
2. Simán standard outra írja a kimenetet. Így csak 1 db jart kell bedobni a WEB-INF/lib alá.
3. Ami érdekes az egész kimenetből, az az hogy mennyi adat változott a session-ben, igazából az fogja a teljesítményt. Valami ilyesmit találtam ki neki, hogy minden attribútumra írja ki, az állapotát
   
   • NEW - a request kiszolgálása alatt jött létre,
     
   • DEL - azaz a request alatt a gondviselés megszabadított tőle
     
   • CHG - már megvolt, de változott
   • NOP - megvolt, de nem változott
     
   És persze az objektum kiszerializált méretét az egyszerűség kedvéért csak a kiszolgálás után, kivétel ha DEL persze.
4. Public domain, de igérd meg hogy soha nem felejted benne egy éles alkalmazásban! :-D
5. Még kitapasztalom és kitalálom hogy mi lenne mégjobb...
   

Forrás, konfig, bináris, satöbbi