Directive ASP.NET @OuputCache "Inheritance"

Question

Comme je le mentionne dans un earlier question, j'ai des problèmes avec les performances d'un site web ... Certaines requêtes SQL sont en train de tuer le serveur. Mais, comme le titre de ce post le mentionne, j'ai regardé la directive page OutputCache pour améliorer les performances du site.

Bien, je suis tombé sur quelques questions concernant cette directive: 1- Si j'ai un contrôle utilisateur Web qui déclare une directive OuputCache dans une page qui a un aussi, que l'on va « gagner »? 2- Quelle est la meilleure pratique concernant la durée? J'aimerais avoir une fenêtre coulissante aussi.

Merci pour votre aide et s'il vous plaît visitez http://www.developerit.com

Answer 1

Sur demande où ne sont mises en cache, la page et le contrôle sera créé, puis ajouté au cache de sortie. Si la page est mise en cache, le contrôle ne sera pas créé, qu'il soit dans le cache ou non - son balisage est contenu dans la copie mise en cache de la page. Si la page n'est pas mise en cache et que le contrôle est activé, le balisage mis en cache du contrôle sera utilisé dans la page.

Answer 2

Voici un bon article sur la mise en cache de sortie: http://www.4guysfromrolla.com/articles/121306-1.aspx.

Généralement, vous semblez regarder la mise en cache des pages et des fragments. Ce que vous voulez faire est de mettre en cache la page, si vous le pouvez, car cela vous donnera le meilleur avantage de performance. Mais, si vous avez des régions sur la page qui doivent changer dynamiquement par utilisateur, par exemple: vous dites 'Bonjour {nom d'utilisateur}' en haut de la page, alors vous devez regarder la mise en cache des fragments.

La mise en cache des fragments n'est pas aussi efficace que la mise en cache des pages, car la sortie doit être assemblée à partir des informations mises en cache et des informations dynamiques, mais généralement beaucoup mieux que la mise en cache!

C'est un peu un art de modifier la mise en cache en fonction de ce que fait la page et de la charge sur la base de données, mais cela peut rendre une page chargée plus rapidement que non mise en cache. FYI - Si les requêtes db détruisent le site, vous pouvez également essayer de les apprivoiser et/ou mettre en cache leur sortie individuellement, de sorte que vous n'ayez pas besoin de continuer à utiliser la même base de données. Comprendre aussi le 'varyByParam' pour la mise en cache est très utile aussi - disons que vous avez une page en 3 langues, vous pouvez mettre en cache une page pour chaque langue en utilisant le varyByParam, aussi longtemps que votre Url une sorte de composant de langue le varyByParam peut ramasser.

HTH, Lance