Anti-patterns: Cache Cows

 
31 augustus 2009

Omschrijving
Een stuk software is ontwikkeld met een heel duidelijk uitgangspunt: database interactie is langzaam, dus we cachen zoveel mogelijk. De optimalisatie gaat zelfs zo ver dat er diverse pointerstructuren en anderszins curieuze implementaties van collecties gemaakt zijn om maar zo snel mogelijk gegevens te kunnen oplepelen. Helaas is het wel zo dat de software nu toch wel eens gemigreerd moet worden naar die nieuwe versie van het ontwikkelplatform, of nog liever: laten we de decenniumswitch volgend jaar maar eens plannen.

Symptomen
Pointerstructuren, extreme optimalisaties op de millimeter. Extreem low-level programmeerwerk.

Oplossingen

  • De interface van de cachestructuren behouden en implementeren met bewezen framework(s)
  • Gebruik van caching volledig uitfaseren en overlaten aan de database. Quering doet geen pijn. Echt niet.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags:


Reacties (5)

  • Stephan Eggermont schreef:

    Ik kom vaker het omgekeerde probleem tegen: wat heeft die database eigenlijk in die architectuur te zoeken. Minder dan 4G aan data, een enkele applicatie met enkele tientallen gebruikers en geen noemenswaardige rapportagekoppelingen.

    Geplaatst op 08 september 2009 om 15:18 Permalink

  • Paul van Dam schreef:

    Zie ook: http://martinfowler.com/bliki/TwoHardThings.html :)

    Geplaatst op 31 augustus 2009 om 20:47 Permalink

  • Leuke naam! Ik had wel een ander idee hierbij: van applicaties met performance problemen waar als ‘quick fix’ maar een caching oplossing ingeduwd is. Soms gecombineerd met load balancing, waarbij de caching dan natuurlijk ook nog distributed.

    Omschrijving: gebruik van caching (en load balancing) voor het oplossen van structurele problemen in het onderliggende model in de software (als dat model er al is).

    Problemen: caching lost niet echt de problemen op (de structureel verkeerde queries blijven gewoon traag, hoogstens 2 keer zo snel bijvoorbeeld), maakt andere queries wel iets sneller.

    De nadelen van caching doen deze beperkte voordelen ruimschoots teniet: extra vertraging bij verlopen cache, soms optredende en daarmee lastig te debuggen problemen als gevolg van cache inconsistenties en de extra complexiteit in ontwikkelen en deployment (to name a few).

    Geplaatst op 31 augustus 2009 om 16:03 Permalink

    • Hoi Rick,

      Dat is inderdaad ook een goeie (en bekende). Misschien een apart anti-pattern?

      Wat ik bij deze voor ogen had is eigenlijk een vorm van de bekende uitspraak van Knuth: “Early optimization is the root of all evil”. Het vroeg wegoptimaliseren van mogelijke problemen, waardoor je zulke ingewikkelde structuren krijgt dat je vervolgens weer performanceproblemen in de uiteindelijke software kan verwachten.

      Geplaatst op 06 september 2009 om 7:23 Permalink

      • Ik denk dat forgetting about the optimum in optimization misschien beter beschrijft wat je hierboven uit de doeken doet. Want caching is maar 1 van de vormen van overdreven (dwz meer kosten dan baten) optimalisatie. Komt goed uit, dan kun je cache cows gebruiken voor wat ik hierboven beschreef. :)

        Geplaatst op 08 september 2009 om 15:37 Permalink