Agenda Opnåede resultater Logging af backendkald Analyse af logs

Download Report

Transcript Agenda Opnåede resultater Logging af backendkald Analyse af logs

Agenda

Opnåede resultater

Logging af backendkald

Analyse af logs

Implementering af caching

Demo af prototype

Videre arbejde i praksis

Logging og analyse i praksis

Caching i praksis

Eksempel på anden analyse
Resultater for logging

En væsentlig bedre placering af ansvaret for
logging i forhold til ad-hoc logging




Bedre kvalitet i logging (flere detaljer)
Mindre arbejde ved at implementere i eksisterende
applikationer
Minimalt performance impact
Erfaring med dynamic proxy til håndtering af
”cross-cutting concerns”
Resultater for analyse



Bedre og mere automatisk analyse af ”duplicate
invocations” end en ad-hoc analyse (fokus på
de to ”cases” fra ad-hoc analyserne)
Opbygning af CallSimulator – der giver et
grundlag for test af caching
Skabt arkitektonisk grundlag for andre analyser
(mere om det senere)
Resultater for caching



Bedre kendskab til caching ”fundamentals”
både generelt og i en Java kontekst
En arkitektur der transparent indskyder en
central caching for backendkald og isolerer
caching implementationen
En effektiv caching af duplicate invocations,
som var fokus for prototypen
Demo af prototype



CallSimulator med/uden cache
Skift af strategi/size (learning tests af
konfiguration)
Coverage for prototypen
Logging og analyse i praksis


InvocationLogger ville kunne gøres ”stateless”
ved fx at logge til Log4J (fx til systemout.log)
Forskellige reporters ville fortsat kunne være
observers på InvocationLogger:



En SlowResponseReporter, der fx logger
langsomme kald i forhold til et threshold
DuplicateInvocationReporter, ville selv skulle holde
state – fx baseret på en intern cache af invocations
med timeout på 10 min (en netbank ”session”)
LogAnalyzer er ikke brugbar (kræver state) –
men var driver for test og design af Reporters
Caching i praksis

Klassifikation af levetid i cache – data der
opdateres løbende fx aktiekurser

En løsning kunne være et CacheableDao interface
med en getCacheTimeToLive metode
Caching i praksis (fortsat)

Filtrering af CUD i forhold til caching



En regularexpression filtrering af ”standard”
metodenavne (get.*, hent.* delete.*, update.* osv.)
Evt. en metode på CacheableDao –
getNoCacheMethodNamePattern
Evt. flere interfaces NonCacheableDao – som
efterfølgende kunne anvendes til at vælge en
caching strategi i DaoInvocationHandler
Caching i praksis (fortsat)

LiveCacheStatistics (fra Ehcache)



Overvågning af størrelse i memory – kunne bruges
til dynamisk at regulere op og ned i størrelse (for fx
at beskytte heap)
getCacheMissCountExpired – kunne måske bruges
til at styre størrelse på en LFU cache
API til LiveCacheStatistics
Eksempel på anden analyse

Analyse af ”næsten” identiske kald

Motivation – stort spild af ressourcer

Målet – bedre design af ”backend” interfaces

Mulige løsning

gennemløb af indhold på return object med reflection,
hvor der laves en simpel optælling af antal ”equals”, der
er true i forhold til antal værdier