Caching in ASP.net-Webapplication (Webseite, Webshop,...)

Ich hätte Grundsatzfragen zum Thema Caching...

Wie ist das mit dem Caching...

Ist es eine Technologie die man eigentlich immer oder so viel wie möglich einsetzen sollte (wie etwa auch Unit-Tests, DI, Repositories,...)?

Gehört es also zum "guten Ton" oder ist es nur eine Technologie mit der man eventuell später auftretende Performance-Probleme "leicht" abfangen kann.

Ich plane gerade eine neue Version unserer Lösung und bin am Überlegen ob ich das Thema Caching gleich von Anfang an miteinplanen soll oder erst wenns "notwendig" wird...

Wie seht ihr das...

Caching ist keine Technologie. Das ist ein Feature und ist dafür da, dass statischer Content nicht dauernd neu generiert werden muss, sondern im Speicher liegt, sodass die Requests schneller bearbeitet werden können.

Daher gibt es auch dynamischen Cache (dynamische Seiten mit einer begrenzten, zeitlichen Gültigkeit) und einen statischen Cache (Resource Files, Bilder...).

Und Caching plant man nicht ein, sondern kann man später einfach aktivieren bzw. durch bestimmte Attribute in MVC die gewünschten Seiten deklarieren.
Da gibts auch gar nichts zu planen, sofern es keine Serverfarm gibt; ähnlich ist es mit Content Compression.

Überhaupt mal das Thema Caching bei MSDN gesucht?
Da steht nämlich genau so etwas drin - sogar mit Konffigurationsbeispielen!

Hi Abt,

dass man bei "statischen" Seiten nichts planen muss bzw. das Caching dann einfach aktiviert ist klar.

Aber vor allem bei einem Webshop gibts eben schon ein paar Dinge zu beachten. Es gibt z.B. die Warenkorbinfo oder die Info ob man eingeloggt ist oder nicht, da kann man das Caching nicht so ohne weiteres aktivieren.

Macht man etwas falsch wenn man Caching einsetzt bzw. einsetzen muss?
Ist Caching ein Mittel zur Behandlung von Ursachen oder Symptomen? (Zahnarzt oder Schmerzmittel 😉 )

Du hast durch falsches Caching halt negative Symptome.
zB sollte man Rechte oder Sessons nicht Cachen - dazu gehört eine Login-Info und auch der Warenkorb sollte nicht direkt im Cache liegen.

Sowas liegt im dynamischen Cache, der quasi die HTML-Elemente im Cache hat, aber die Platzhalter aus dem Controller für die Entity-Objekte noch einpflanzt. Es muss aber eben nicht mehr die ganze View neu generiert werden; sondern nur noch die Platzhalter.

Wenn Du MVC nutzt schau Dir das an:
http://www.slideshare.net/rudib/aspnet-mvc-performance da wird neben ASP Cache Performance auch RouteCache und Compression angesprochen.

Oder auch How To Improve the Performance of ASP.NET MVC Web Application

Danke,

ich werd mir die Links mal durchlesen...

Meinst du mit "dynamischem Cache" die Sache mit Response.WriteSubstitution...?

Ähm nein. Response ist ein direkter Zugriff auf den Stream und das finde ich mehr als unschön.
Ich mein damit u.a. den OutputCache; wobei man hier bestimmte Parameter vom Cache explizit ausschließen kann.