Je reprendrai la même remarque qu'un autre intervenant : certes Templeet est vainqueur et largement. Mais pour obtenir le même niveau de performances avec un autre outil (même cette grosse daube de PHP-Nuke, oui oui), il suffit de... mettre un proxy devant. C'est en effet ni plus ni moins le fonctionnement de Templeet. Ce qui n'enlève rien à son mérite, d'ailleurs, si c'est ce que l'on cherche : témoin les stats faramineuses de linuxfr, sur une machine relativement modeste ; je pense que SPIP, sur une machine équivalente, commencerait à avoir du mal (néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus).
Sur les chiffres absolus, je suis un peu surpris, mais il est vrai que le processeur d'un OpenBrick ne doit pas être un foudre de guerre (pour ma part, sur un Athlon XP 2000 avec PHPAccelerator, j'obtiens une centaine de requêtes par seconde sous SPIP, et probablement plus de mille avec Apache/Templeet). Néanmoins, l'utilisation d'une plateforme légère ne me semble pas pertinente pour une solution à base de cache (que ce soit SPIP, Templeet ou autre) où la disponibilité de la machine est surtout cruciale lors du recalcul d'une page - il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site. De plus, l'expérience semble montrer (d'après le retour sur les listes de discussion) que le problème pour certains utilisateurs "moyens" est la durée de recalcul lorsqu'une page n'est pas en cache - certains hébergeurs très lents du type Free ou Online ont tendance à dépasser le délai imparti à PHP - plutôt que le débit en pages par seconde une fois que l'on passe par le cache. Mais ça dépend bien sûr des applications.
Sur le fond, il est évident que les performances sont du côté des solutions intégralement statiques type Apache ou Templeet (il aurait été intéressant d'ajouter un PHPNuke, pour admirer le carnage ;-)). Maintenant il faut ajouter que ces solutions n'apportent pas forcément un niveau d'intégration très poussé des fonctionnalités désirées par le webmestre. Tout dépend si l'on a envie de coder soi-même des choses à la main, ou si Templeet propose des frameworks plus "haut niveau".
Pour SPIP, j'ajouterai que le niveau de performances dépend des fonctionnalités activées, à savoir : syndication automatique, moteur de recherche. En effet ces fonctionnalités entraînent des calculs réguliers indépendamment de la mise en cache des pages retournées par le serveur.
# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick
Posté par Antoine . En réponse à la dépêche Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick. Évalué à 10.
Je reprendrai la même remarque qu'un autre intervenant : certes Templeet est vainqueur et largement. Mais pour obtenir le même niveau de performances avec un autre outil (même cette grosse daube de PHP-Nuke, oui oui), il suffit de... mettre un proxy devant. C'est en effet ni plus ni moins le fonctionnement de Templeet. Ce qui n'enlève rien à son mérite, d'ailleurs, si c'est ce que l'on cherche : témoin les stats faramineuses de linuxfr, sur une machine relativement modeste ; je pense que SPIP, sur une machine équivalente, commencerait à avoir du mal (néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus).
Sur les chiffres absolus, je suis un peu surpris, mais il est vrai que le processeur d'un OpenBrick ne doit pas être un foudre de guerre (pour ma part, sur un Athlon XP 2000 avec PHPAccelerator, j'obtiens une centaine de requêtes par seconde sous SPIP, et probablement plus de mille avec Apache/Templeet). Néanmoins, l'utilisation d'une plateforme légère ne me semble pas pertinente pour une solution à base de cache (que ce soit SPIP, Templeet ou autre) où la disponibilité de la machine est surtout cruciale lors du recalcul d'une page - il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site. De plus, l'expérience semble montrer (d'après le retour sur les listes de discussion) que le problème pour certains utilisateurs "moyens" est la durée de recalcul lorsqu'une page n'est pas en cache - certains hébergeurs très lents du type Free ou Online ont tendance à dépasser le délai imparti à PHP - plutôt que le débit en pages par seconde une fois que l'on passe par le cache. Mais ça dépend bien sûr des applications.
Sur le fond, il est évident que les performances sont du côté des solutions intégralement statiques type Apache ou Templeet (il aurait été intéressant d'ajouter un PHPNuke, pour admirer le carnage ;-)). Maintenant il faut ajouter que ces solutions n'apportent pas forcément un niveau d'intégration très poussé des fonctionnalités désirées par le webmestre. Tout dépend si l'on a envie de coder soi-même des choses à la main, ou si Templeet propose des frameworks plus "haut niveau".
Pour SPIP, j'ajouterai que le niveau de performances dépend des fonctionnalités activées, à savoir : syndication automatique, moteur de recherche. En effet ces fonctionnalités entraînent des calculs réguliers indépendamment de la mise en cache des pages retournées par le serveur.
Amicalement
Antoine.