Caching in einer Web-App. An welcher Stelle?

[Thomas B.]

Hallo zusammen.

Gegeben ist eine einfach gestrickte Web-Anwendung (UI, Business- und
Datalayer, mehr nicht), in der es Caching zu implementieren gilt. In
Frage kommen dafür ja theoretisch alle drei Schichten, zumindest ließe
sich für jede ein Argument finden.

Wo würdet ihr es implementieren? Und warum?

Hintergrund: ich bin eben am Refactoring über einer Web-App, bei der
ich es im Business-Layer realisiert habe. Je mehr ich allerdings
darübre nachdenke, desto mehr preferiere ich dafür, die
Implementierung dem UI, in dem Fall den MVC-Controllern, zu
überlassen. Allerdings werde ich mir da mit mir selbst nicht ganz
einig ;)

[Thomas B.]

Ei, sorry für das gar fürchterliche Deutsch. habe den letzten Satz
mehrfach umgeschrieben ;)

[Stefan Lieser]

Hallo Thomas,

wo treten denn die Performanceprobleme auf? Hast du schonmal mit einem
Profiler geschaut wo das Problem liegen könnte?


Grüße
Stefan

[Thomas Bandt]

Hi,

On 2 Jul., 14:17, Stefan Lieser <ste...@lieser-online.de> wrote:
> wo treten denn die Performanceprobleme auf? Hast du schonmal mit einem  
> Profiler geschaut wo das Problem liegen könnte?

klar. Aber je komplexer so eine datengetriebene App wird, desto mehr
Zugriffe auf das Repository und damit die Datenbank werden dann auch
unvermeidlich. Das heißt ums Cachen komme ich nicht herum, die
Frage ist dann nur, wo ich es mache.

Thomas

[Stefan Lieser]

Na wenn die DB der Flaschenhals ist könntest du in den Repositories
cachen. Aber wie schon angedeutet solltest du vor einer Optimierung
herausfinden wo genau der Engpass ist.

Viele Grüße
Stefan Lieser
--
http://lieser-online.de

[Steve Wagner]

Ich hab relativ gute Erfahrungen mit NHibernate und Syscache gemacht. Es
kommt aber wirklich darauf an wie gut man die Daten Cachen kann. Auch
bei den anderen Layern ist es ganz davon Abhängig was genau du für eine
Anwendung hast. Wenn sich deine Seite fast nie ändert für eine Url, dann
macht eine Kombi aus Client und Outputcache sinn. Wenn die Seite sich
aber bei jedem Abruf ändert, dann bringt dir das wieder wenig.

-Steve

Thomas Bandt schrieb:

[Thomas B.]

Okay, dem entnehme ich, dass es keine Glaubenskämpfe in dieser
Frage gibt und das jeder recht pragmatisch für sich löst, wie er
meint.

Dann packe ich es ins UI :).

[Erich Eichinger]

Nur so als Hinweis zum Nachdenken: Wo sind deine
Synchronisationspunkte in der Applikation? D.h. wie sieht es aus, wenn
du den Cache aufgrund einer Datenänderung ausleeren mußt? Meiner
Erfahrung nach eignet sich da das Cachen im UI nicht unbedingt, da
sich hinter jedem Use Case im UI verschiedenste Daten verbergen, die
dabei benutzt werden. Ich versuche Caching daher meist möglichst nahe
am Persistenzmechanismus zu implementieren weil ich dort
(üblicherweise DAOs) ziemlich genau und übersichtlich kontrollieren
kann, welche Daten wann abgerufen bzw. verändert werden. Dadurch lässt
sich auch der Cache entsprechend ausleeren und ich habe die Cache-
Logik nicht allzusehr über die Anwendung verteilt. In jedem Fall ist
das genau eine der Anwendungen, wo AOP seine Stärke ausspielen kann.

hth,
Erich

[Thomas B.]

Hallo Erich,

du hast natürlich völlig Recht. Ich hatte es bis jetzt nur beim
Überfliegen des Codes belassen, bei dem dann meine Frage aufkam
("Warum hab' ich das damals so gemacht?"), geändert habe ich noch
nichts. Zum Glück, denn das Invalidieren der Daten im Cache habe ich
in dem Zusammenhang bei meiner Überlegung völlig außer Acht gelassen,
zum Glück aber nicht als ich es damals impelementiert habe. Denn in
diesem (architektonisch sozusagen sehr, sehr simplen) Konstrukt ist
damit das Cache-Handling im Business Layer doch am besten aufgehoben,
weil ich natürlich Methoden meiner Services, in denen ich Daten aus
den Repositories hole und ggf. cache, vom UI aus mehrfach verwende und
auch "für mehrere Stellen" wieder invalidieren muss und das ganze hier
am besten steuern kann, ohne mich wiederholen zu müssen.

Gruß, Thomas