Rails - etags vs page cache (cache de fichier)

Question

Quels seraient certains avantages de l’utilisation de etags / stale? / fresh_when? au lieu de la mise en cache des pages (sur un cache de fichiers)?

Apache gère automatiquement les balises etags pour les fichiers statiques, mais même si ce n'était pas le cas, la mise en cache des pages serait encore meilleure, car l'application Rails n'est même pas appelée.

Alors, dans quels cas utiliserais-je les méthodes fournies par Rails (obsolète? / fresh_when?)?

Answer 1

Ils sont vraiment complémentaires. Etags / fresh_when, etc. vous aident à bien jouer avec les caches en aval (comme vos propres instances Varnish / Squid ou Rack :: Cache ou le cache du navigateur ou les serveurs proxy ISP & # 8230;)

La mise en cache des pages vous évite de frapper votre pile de rails entièrement parce qu'Apache / votre serveur Web servent le fichier, ainsi aucune recherche de base de données n'est effectuée. Mais vous devez faire face à l'expiration du cache pour le garder à jour.

Avec etags / conditionnel get, vous ne gagnez pas beaucoup de temps de traitement car vous devez toujours obtenir tous les enregistrements utilisés sur la page:

def show
  @article = Article.find(params[:id])
  @feature = Feature.current
  fresh_when :etag => [@article, @feature] 
end

dans le cas où l'utilisateur a une page en cours, cela vous fait gagner du temps de rendu et la bande passante nécessaire pour envoyer la page.

Answer 2

Une autre utilisation qui m'est venue à l'esprit était que vous pouviez toujours traiter certaines informations avant de laisser Rails distribuer le "304 non modifié". entête. Par exemple, si vous souhaitez enregistrer des résultats sur une page.

Answer 3

Une chose qui me vient à l’esprit est que fresh_when vous épargnera tout de même un rendu, même si vous avez effacé tout le cache de la page. Ici, vous utiliseriez les deux en tandem.

Je suis également curieux d’autres réponses.