Un "RAM Cache" permet d'éviter la génération de certaines parties de documents dans Zope. Par exemple, sur LinuxFR, l'entête des pages est statique (ou presque, y'a quand même la date), mais il est quand même souhaitable de gérer les listes de liens autrement qu'à la main dans le code HTML... dans ce cas, on crée un document chargé de faire le rendu de cette partie de la page et on l'associe à un "RAM Cache" chargé de garder la page générée pendant x secondes (ce n'est qu'un exemple très très simpliste).
Un "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par pas_moi . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 4.
Un "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.