Agenda  Opnåede resultater  Logging af backendkald  Analyse af logs  Implementering af caching  Demo af prototype  Videre arbejde i praksis  Logging.

Præsentationer af emnet: "Agenda  Opnåede resultater  Logging af backendkald  Analyse af logs  Implementering af caching  Demo af prototype  Videre arbejde i praksis  Logging."— Præsentationens transcript:

1 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

2 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”

3 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)

4 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

5 Demo af prototype  CallSimulator med/uden cache  Skift af strategi/size (learning tests af konfiguration)  Coverage for prototypen

6 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

7 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

8 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

9 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 API til LiveCacheStatistics

10 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