ASP.NET MVC Caching-Szenario

Question

Ich bin immer noch auf der Suche nach einer anständigen Lösung für mein Szenario. Grundsätzlich habe ich eine ASP.NET MVC-Website, die ein bisschen Datenbankzugriff hat, um die Ansichten (2-3 Abfragen pro Ansicht) zu machen, und ich möchte Caching nutzen, um die Leistung zu verbessern.

Das Problem besteht darin, dass die Ansichten Daten enthalten, die sich unregelmäßig ändern können, z. B. 2 Tage lang, oder die Daten könnten sich mehrmals in einer Stunde ändern.

Die Abfragen sind ziemlich einfach (wählen Sie ... von wo ...) und nicht riesige Joins, jeder gibt im Durchschnitt 20-30 Zeilen von Daten zurück (mit etwa 10 Spalten).

Die Abfragen sind ziemlich einfach auf der aktuellen Stufe der Websites, aber im Laufe der Zeit wird der Besitzer mehr Daten hinzufügen und die Besucherzahlen werden zunehmen. Sie sind im Moment sehr groß und ich würde nach Caching suchen, da der Traffic hauptsächlich von Google AdWords usw. kommen wird und schnelle Lade-Seiten (anscheinend) ein Vorteil sein werden.

Die Website wird auf einer Microsoft SQL Server 2005-Datenbank gehostet (kann aber bei Bedarf auf 2008 aktualisiert werden).

Muss ich entweder:

1. das Caching auf die minimale Zeit ein Element ändert sich nicht für (zB Cache für etwa 3 Minuten) Stellen und die Eigentümer sagen, dass alle Änderungen bis zu 3 Minuten dauern wird erscheinen?

2. einen Weg finden, den Cache zu zwingen, und auf Änderungen erneut verarbeiten zu löschen (zB wenn der Eigentümer fügt im Administrations-Bereich ein Element, um es den entsprechenden Cache-Speicher löscht)

3. Vergessen Sie alle zusammen Cachen

4. Oder gibt es eine Option, die zu diesem Szenario passt?

Answer 1

Wenn Sie SQL Server verwenden, gibt es auch eine andere Option zu prüfen:

Verwenden Sie die SqlCacheDependency Klasse Cache zu haben, für ungültig erklärt, wenn die zugrunde liegenden Daten aktualisiert wird. Offensichtlich erreicht dies ein ähnliches Ergebnis wie Option 2.

Ich könnte Agileguy tatsächlich zustimmen müssen - Ihre Abfragebeschreibungen scheinen ziemlich simpel zu sein. Nachdenken und Caching im Hinterkopf behalten, während Sie entwerfen, ist eine gute Idee, aber haben Sie bewiesen, dass Sie tatsächlich es jetzt brauchen? Option 3 scheint viel besser zu sein als Option 1, wenn man davon ausgeht, dass Sie gerade keine signifikanten Leistungsprobleme haben.

Answer 2

Vorzeitige Optimierung ist die Wurzel allen Übels;)

Das heißt, wenn Sie Cache gehen ich eine Lösung um Option basierend verwenden würde, 2.

Sie haben weniger Gelegenheit für "schmutzige" Daten auf diese Weise.

Güte,

Dan

Answer 3

2. Option ist das Beste. Sollte nicht so schwer sein, wenn die gleiche App Daten bearbeitet/zwischenspeichert. Kann schwieriger sein, wenn es mehr als eine App gibt.

Wenn Sie nicht so gehen können, könnte auch 1st akzeptabel sein. Mit einigen Optimierungen (d. H. Ich würde versuchen, den Cache bei einem Timeout automatisch auf einen anderen Thread zu aktualisieren) könnte es gut genug funktionieren (wenn die Daten etwas alt sein dürfen).

Niemals Caching löschen, wenn es möglich ist. Jeder kennt "verfrühte Optimierung", aber Caching ist eines der Dinge, die die Skalierbarkeit/Performance der Anwendung dramatisch erhöhen können.