Je pense que c'est plus prévu pour les caches du coté des clients.
Personnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.
Dans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!
[^] # 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é à 2.
Personnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.
Dans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!