En dehors de ce petit FUD, je dois dire que ce que tu dis correspond à *tous* les logiciels fonctionnant de manière dynamique.
Le but de Zope est d'utiliser ses fonctionnalités *applicatives* telles que les workflows, la gestion de la sécurité, la génération dynamique de contenu adapté à tout un ensemble de paramètres/autres objets. Tout logiciel qui fonctionne de cette manière est vulnérable à des dénis de services si quelqu'un fait des requêtes en masse (quoique, ça fait plus de hits :-).
Mettre un Apache ou un Squid ne servira à rien dans ce cas, puisque les pages sont supposées être générées différemment (quasiment) à chaque fois). Si ce n'est pas le cas, alors n'utilise pas Zope, utilise un Templeet ou équivalent.
Pour éviter ces problèmes, faire de la répartition de charge est une solution, ou faire de la qualité de service sur le firewall devant, sont quelques-unes des possiblités qui me viennent en tête. Mais mettre un Apache, non, pas vraiment.
[^] # Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Luc Stepniewski (site web personnel) . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 1.
Le but de Zope est d'utiliser ses fonctionnalités *applicatives* telles que les workflows, la gestion de la sécurité, la génération dynamique de contenu adapté à tout un ensemble de paramètres/autres objets. Tout logiciel qui fonctionne de cette manière est vulnérable à des dénis de services si quelqu'un fait des requêtes en masse (quoique, ça fait plus de hits :-).
Mettre un Apache ou un Squid ne servira à rien dans ce cas, puisque les pages sont supposées être générées différemment (quasiment) à chaque fois). Si ce n'est pas le cas, alors n'utilise pas Zope, utilise un Templeet ou équivalent.
Pour éviter ces problèmes, faire de la répartition de charge est une solution, ou faire de la qualité de service sur le firewall devant, sont quelques-unes des possiblités qui me viennent en tête. Mais mettre un Apache, non, pas vraiment.