Archive

Articles taggués ‘php’

Patch exec_dir pour php-5.3.4

23/12/2010 Comments off

Bonjour à tous,
Voici le patch exec_dir pour PHP 5.3.4

php-exec-dir.5.3.4.patch
MD5SUM: f6974e6702819dbebe8c464dc4906307

Categories: Général Tags: , , , , ,

Patch exec_dir for php-5.3.4

22/12/2010 2 commentaires

Hello,
This is the patch to enabled exec_dir on PHP 5.3.4.

php-exec-dir.5.3.4.patch
MD5SUM: f6974e6702819dbebe8c464dc4906307

Categories: Général Tags: , , , ,

Pourquoi migrer vers PHP 5 ?

26/08/2010 Comments off

Un peu d’histoire

PHP est un langage de script orienté web, et massivement utilisé avec le serveur web apache et la base de données MySQL ; cet ensemble de technologies est connu sous le nom de AMP ou lorsqu’il est basé sur un système d’exploitation à base Linux, LAMP.

C’est la version 3 qui a amorcé la popularité de PHP, mais c’est à la version 4 qu’il a réellement été adopté en masse. Ces versions sorties en 1998 et 2000 ont aujourd’hui plus de 10ans, mais sont encore très utilisées, en particulier la 4. Certes cette dernière a subi de nombreuses mises à jour jusqu’en Août 2008 avec la version 4.4.9 mais elle n’est aujourd’hui plus maintenue officiellement (http://www.php.net/archive/2007.php#2007-07-13-1), et la dernière version date donc de plus de deux ans, une « éternité » en informatique.

PHP 5 est né le 13 juillet 2004 et a introduit la notion d’objet, cette version est mise à jour régulièrement. La version 5.2 a été considérée par la communauté comme une version mature (2006) et une version 5.2.14 est d’ailleur sortie il y a quelques semaines . La version 5.2.x est donc actuellement la version recommandée par de nombreux experts.

Plus récemment, l’équipe de PHP a sorti la version 5.3 qui apporte de nombreuses nouveautés, en particulier les espaces de nommage ou encore les archives PHP (phar). Cette dernière version signe aussi l’arrêt de la compatibilité avec PHP4. Et oui, car jusqu’à la branche 5.2.x, PHP permettait d’exécuter des applications PHP4 avec PHP5, mais avec PHP 5.3 ceci est révolu.

PHP 5 une maturité accrue

Il faut dire que les spécialistes attendaient cela depuis un moment. En effet PHP4 est moins rapide que PHP5, ensuite il utilise une ancienne version du langage qui permet des directives qui lorsqu’elles sont mal utilisées provoquent des failles de sécurité (le fameux « register globals » par exemple). C’est bien là tout l’enjeu du passage à PHP5, mais au delà de failles de sécurité et d’options de PHP mal utilisées, il y a la façon de programmer. Je l’ai dit tout à l’heure PHP4 à eu un franc succès, et de nombreux développeurs se sont lancés dans la création de sites internet, il ne faut pas oublier qu’à ce moment-là on était au début des années 2000 et qu’Internet était en plein essor ; beaucoup d’entreprises moyennes et grandes voulaient avoir une visibilité sur internet, c’était aussi le début du e-commerce et de la démocratisation des achats en ligne.

Un manque de formation à la sécurité et à PHP

Mais les développeurs ne sont pas réellement formés à ce genre de langage ou du moins aux types d’attaques et de failles auxquelles les sites et programmes peuvent être exposés. On citera par exemple la technique dite « SQL Injection » dont le célèbre site « thepiratebay.org » a été la cible il y a quelques semaines (http://www.pcinpact.com/actu/news/58165-the-pirate-bay-pirate-donnees-utilisateurs-e.htm), ou encore cette université indienne (Sikkim Manipal University http://portal.smude.edu.in/ , http://seclists.org/fulldisclosure/2010/Jul/258).

PHP 5 propose PDO qui permet non seulement de s’abstraire du type de base de données (mysql, sqlite, postgresql…), mais surtout incorpore un système d’échappement permettant d’éviter ce genre d’attaques.

Avec PHP 5 le style de programmation a évolué, le langage PHP s’est nettement inspiré de Java, et la notion d’objet permet au développeur de concevoir son site ou son application, comme il le ferait pour une application dite « lourde ». Cela apporte normalement un gage d’évolutivité incontestable et évite le bien connu « plat de spaghettis » (http://fr.wikipedia.org/wiki/Syndrome_du_plat_de_spaghettis).

Un langage mort encore très utilisé

On l’a vu PHP 4 est un langage mort depuis plusieurs années (2007) et pourtant de nombreuses applications et sites internet continuent à se baser dessus, citons par exemple osCommerce (http://www.oscommerce.com/), outil permettant de déployer un site de vente en ligne rapidement. De plus les applications PHP4 sont souvent très mal programmées exposant les sites et applications à des failles de sécurité importantes. Enfin PHP 5.3 signe la fin de la compatibilité avec PHP4.

Il est donc nécessaire, presque vital maintenant, de migrer les applications PHP4 vers la version PHP5. Il existe pour cela deux approches que nous allons exposer juste après.

Rafistoler ou repenser

La première consiste à rafistoler le code PHP4 pour le rendre compatible PHP5, c’est une tâche qui nécessitera de comprendre le fonctionnement de l’application et de corriger le code, c’est un travail long, d’analyse et d’optimisation, cela pourra convenir pour un site ou une application de moins de 10 000 lignes de code, mais c’est une solution que je qualifierai de temporaire.

La deuxième solution est plus radicale et consiste à reprendre les choses entièrement, d’abord en évaluant les besoins, les applications PHP4 ayant logiquement au moins 5 ans, les besoins ont sans doute changé. Ensuite parce que refaire tout depuis le début permet de concevoir l’application correctement en utilisant des méthodes de modélisation (UML) et de programmer en Objet. Enfin il est paradoxalement plus rentable de tout recommencer depuis zéro, le rafistolage peut prendre plus de temps que de tout refaire pour des projets dépassant 10 000 lignes de code et surtout ne pas être sur d’aboutir à quelque chose de viable, d’où les couts supplémentaires « cachés ».

La programmation objet offre des avantages indéniables par rapport à la programmation procédurale, le code est mieux ordonné, on peut plus facilement représenter l’application sous forme de schémas, et cela permet de rationaliser l’application. Cela passe par une phase d’étude qui permettra de déterminer les besoins et de réaliser diverses représentations telles que les bien connus diagramme de classe ou encore cas d’utilisations.

PHP 5 offre de nombreuses fonctionnalités pour la programmation objet (SPL) encore une fois inspirées du monde Java.

Urgent et vital, mais couteux

Il est donc urgent de migrer les applications PHP4 vers des versions PHP5 plus robustes, mieux pensées, sécurisées et plus facilement évolutives. Cela a évidement un cout, mais il ne sera pas possible de repousser cette migration indéfiniment. De plus PHP4 n’est plus maintenu, les éventuelles failles de sécurité ne sont donc plus corrigées, et continuer à l’utiliser implique une prise de risque loin d’être négligeable. Le code est généralement obsolète et mal conçu ce qui pose des problèmes pour son évolution. PHP5 offre des avantages non négligeables (objets, SPL, PDO) et une sécurité accrue. Il est clair que c’est un investissement, si votre site est un site vitrine, cela pourra peut-être encore attendre un tout petit peu, mais pensez à prévoir un budget pour le refaire à moyen terme et surtout assurez-vous que votre prestataire a les compétences techniques pour réaliser un site bien conçu. Si votre application est du type intranet/extranet et que des données y sont traitées, il est urgent de migrer vers PHP5, assurez-vous que votre prestataire informatique a de l’expérience dans la conception et dans la réalisation d’une telle application, car même en PHP5 il est possible de faire du mauvais travail, c’est donc primordial de s’assurer de votre prestataire dans la réalisation d’applications bien conçues et sécurisée.

Smarty 2.6, 3.0beta and Dwoo Performances

25/03/2010 un commentaire

UPDATE : July 20, 2010
New tests on Smarty 3.0 : RC1, RC2 and RC3 shows same performances as Smarty 3.0b9, no major change. These Release Candidate fix some bug and security issue and give a better stability.

Smarty 2.6, 3.0beta and Dwoo Performances

The aim of this test is to evaluate which template engine is the more efficient in professionnal environment. I selected only Smarty and Dwoo. Smarty is the template engine which we use at Emisfr since 3 years, we know it and we have many application working with. Dwoo is a Smarty « fork » but with a great Oriented Objet improvement. Smarty 3.0 is currently in developpement and one of its aim is to bring Smarty totaly Object and support Objet inside template, Smarty 2.x is likely PHP4 oriented, functional not really object. There is some other template engines like Template Lite (it’s also a Smarty « fork »).

Test environment

dual core Athlon 4200+
3.3Gb RAM
Apache : 2.2.13
Mod_PHP : 5.2.11 + APC
Apache Bench : 2.3

Tested versions

Smarty 2.6.26 : current stable
Smarty 3.0b7 : previous beta, usefull to compare evalution between betas
Smarty 3.0b8 : current beta
Dwoo 1.1.1 : current stable

The tests

Display of a template with and without template engine cache. We are talking about Template engine cache, not APC. When template engine cache is enable, the template engine have not to re-generate PHP code from Template file (tpl).
We will have a look on Memory peak and display time.

Cache enabled
Optimized Site
Force compile
Only to get performances
but this configuration never use
in production
Force Compile Check
Developpment configuration
no cache
No Compile Check
Production Site
most common configuration
cache_lifetime=-1
caching=1
force_compile=false
cache_lifetime=0
caching=0
force_compile=true
cache_lifetime=0
caching=0
check_compile=true
cache_lifetime=0
caching=0
check_compile=false
KINDTEST s3b8_rps s3b8_tpr s3b7_rps s3b7_tpr s2_rps s2_tpr dwoo_rps dwoo_tpr
cache_enabled 167,98 29,77 186,67 26,79 247,05 20,24 187,85 26,62
force_compile 16,33 306,24 16,72 299,05 62,38 80,15 37,2 134,41
force_checkcompile 126,96 39,38 131,83 37,93 187,37 26,69 108,49 46,09
no_checkcompile 127,39 39,25 132,69 37,68 184,89 27,04 111,99 44,65
Libraries Size
Template Engine Size (ko) File count
Smarty 2.6.26 223Ko 69 files
Smarty 3.0b7 627,8Ko 177 files
Smarty 3.0b8 635,4Ko 103 files
Dwoo 1.1.2 396,2Ko 101 files

Next we will test performances with hight access to the test page. For theses tests I will use « ab » (apache bench) with the following parameters : 1000 requests, 5 concurrency. We shall study requests per second, time per request and failed requests.

Execution time for the test page

Execution time

Execution time

When the cache is enable the results are closed, Smarty 2.6 have an advantage over others. But all are above 50ms. Smarty 2.6 and Smarty 3.0beta are very closed, with less than 15ms, it’s the best score.

When force compile is enabled, we can see Dwoo and Smarty 2.6 are the better, above 60ms. But Smarty 3.0beta is 3times slower than Smarty 2.6 with an execution time higher than 110ms. Don’t forget Template Engine force compile option is never enabled in production, this is a test to know « who is the best ».
In « developpment » configuration, result are good, lower than 15ms for evryones, Smarty 2.6 keeps head with 8ms.
In « common production » (no compile check), results looks like « developpment ». The deferencies between them are insignifiant.

Memory print

Memory

Memory

Previously we see that Smarty 2.6 is the faster Template Engine, now what is there memory prints.
Dwoo and Smarty 2.6 are below than 1,7Mo is a good score.
But like execution time the more important is when the cache is enabled. The template engines are below than 850 Ko, Smarty 2.6.26 is about 590 Ko this is the better score Smarty 3.0beta and Dwoo are about 800Ko.

When a Template Engine is configured in « force compile » mode, the Engine have to compile the templates files each time. We can see Smarty 3.0beta consum 2 times more than Smarty 2.6 : 2,4 Mo. Dwoo is juste behind Smarty 2.6 with 1,5Ko

When force check compile is enabled all are above 760ko (the bests scores), why Smarty use less memory than « cache enabled » ? I have no response yet.

When force compile si disabled, results are exactly sames.

Request per seconde

Request per second

Request per second

To simulate a high traffic on the test page I use apache bench, first when force compile is enabled, the results are likely Execution time test above. We can see Smarty 2.6 is the faster Template Engine with about 60 request per second, Dwoo is behind with 40 request per second and Smarty 3.0beta lag behind with 20 requests per seconde (3 time slower than Smarty 2.6).
When the Template Engine Cache is enabled all performances are satisfactory with more than 160 request per second. Smarty 2.6 is still the better with 247 request per second. Dwoo and Smarty 3.0beta are closed with 180 request per second.
In « force check compile » results are good, with more than 125 request per second. But Smarty 2.6 is 30% Faster than Smarty 3.0b. There is no major differencies when « No check compile » is enabled.

Theses results are the reflection of the previous Execution time test

Time per request

Time per request

Time per request

To finish this study, we have a look to the average time per request. Like others tests, When force compile is enabled, Smarty 2.6 is still the faster, with 80ms per request, dwoo is behin with about 135ms per request, Smarty 3.0beta are in the dust with more than 290ms per request.
When cache is enabled all competitor are closed, with a good score below than 30ms per request, Smarty 2.6 takes head with less than 21ms per request.
In force check compile configuration, the results are good with less than 40ms for Smarty, but Smarty 2.6 is the better. When check compile is disabled, the results are close with « force check compile », no major differencies.

To conclude, Smarty 2.6.26 is the better, faster and lighter template engine. Dwoo is a good alternative but its performances are worst than Smarty 2.6.26 and it’s not totally compatible with current Emisfr Software. Smarty 3.0 is good, but is a consume some more memory, but it’s very good score for a beta. The results of Smarty 3.0b are very close with Smarty 2.6.26. The developpment team do a good job ! But, don’t forget Smarty 3.0 is beta, may be some improvement will come.
This test will be updated with Template Engine evolution and release.
Emisfr is using Smarty 2.6.x but hope switch to Smarty 3.0 when it will be released as stable.

Test Files :
Smarty Test Files Package

Follow discution about this test on Smarty forum

Performances de Smarty 2.6, 3.0beta et Dwoo

23/03/2010 un commentaire

MISE A JOUR : 22 juillet 2010
les tests des versions de smarty 3.0 : RC1, RC2 et RC3 montre les mêmes performances que smarty 3.0b9, aucune changement notable. Ces Release Candidate apporte essentiellement de la stabilité et corrige des problèmes de sécurité.

Performances de Smarty 2.6, 3.0beta et Dwoo

Le but de ce test est d’évaluer quel moteur de template est le plus adapté dans un environnement professionnel. Ici je m’intéresse exclusivement à Smarty et Dwoo. Smarty est le gestionnaire de template que nous utilisons depuis déjà 3 ans, avec lequel l’équipe Emisfr est à l’aise. Dwoo quant à lui est un « fork » de Smarty mais orienté Objet. Smarty 3.0 est la version en cours de développement et qui a pour but de passer Smarty en PHP Objet, Smarty 2.x étant encore assez orienté PHP4, cette version 3.0 est la réponse aux problématiques PHP5 et PHP Objet. D’autres moteurs de template existent, comme Template Lite, également dérivé de Smarty.

Environnement :

dual core Athlon 4200+
Ram : 3.3Go
Apache : 2.2.13
Mod_PHP : 5.2.11 + APC
Apache Bench : 2.3

Les versions testées seront les suivantes :

Smarty 2.6.26 : actuellement stable
Smarty 3.0b7 : version beta précédente, elle nous permettra de voir l’évolution d’une beta à l’autre
Smarty 3.0b8 : dernière version beta
Dwoo 1.1.1 : actuellement stable

Les tests :

Rendu d’une page sans le cache du moteur de template activé. On ne parle pas ici de APC ou autre, mais bien du moteur de cache du moteur de template. Son but est de transformer le code « tpl » en code PHP.
On ressortira la mémoire maximum consommée (memory peak), et également le temps de rendu de cette page.

Cache activé
Site a forte charge
Force compilation
jamais utilisé en production
juste pour avoir une idée
des performances
Vérification de la compilation
configuration en développement
Pas de vérification de la compilation
configuration en production
la plus utilisée
cache_lifetime=-1
caching=1
force_compile=false
cache_lifetime=0
caching=0
force_compile=true
cache_lifetime=0
caching=0
check_compile=true
cache_lifetime=0
caching=0
check_compile=false
KINDTEST s3b8_rps s3b8_tpr s3b7_rps s3b7_tpr s2_rps s2_tpr dwoo_fail dwoo_rps dwoo_tpr
cache_enabled 167,98 29,77 186,67 26,79 247,05 20,24 1 187,85 26,62
force_compile 16,33 306,24 16,72 299,05 62,38 80,15 569 37,2 134,41
force_checkcompile 126,96 39,38 131,83 37,93 187,37 26,69 866 108,49 46,09
no_checkcompile 127,39 39,25 132,69 37,68 184,89 27,04 121 111,99 44,65

Ensuite on testera la montée en charge des moteurs, toujours avec et sans cache. Le test est effectué avec « ab » (apache bench) dont les paramètres sont : 1000 requêtes, 5 requêtes concurrentes. On ressortira le nombre de requêtes servies par seconde, le nombre de requêtes ayant amené à une erreur (Fail), et le temps moyen pour une requête.

Analyse du temps d’exécution

Execution time

Execution time

Analysons le comportement des moteurs lorsque le cache est activé. On peut voir qu’à l’exeption de Dwoo, les moteurs sont en dessous de 15ms, avec un avantage pour Smarty 2.6 qui est à 9ms ce qui constitue le meilleur temps, mais suivis de très près par Smarty 3.0beta avec 13ms. La question qui se pose est pourquoi une fois compilé les pages PHP générées par Smarty 2.6 sont-elles plus rapides à charger. Pour avoir la réponse à cette question il faudra regarder dans le code source. On peut en déduire que c’est certainement le chargement du moteur en lui même qui est le plus long sur Dwoo et Smarty 3.0b.

Voyons quels sont les résultats lorsque l’on force la compilation. On peut voir que Dwoo et Smarty 2.6 sont les meilleurs avec respectivement 55ms et 27ms. Par contre les deux versions de Smarty 3.0b, sont trois fois plus lentes avec un temps supérieur à 100ms. On peut donc penser que l’équipe de Smarty n’a pas encore fait de phase d’optimisation sur la génération de template. Ces chiffres sont à relativiser, car la génération sans cache n’intervient qu’une seule fois : lors du premier accès à la page en question, ceci n’est donc pas problématique en soi, mais il faudra penser à ne pas forcer la compilation des templates (ce qui est normalement jamais le cas).

C’est danse les configuration « développement » et « production commune » que l’on obtien les meilleures temps avec moins de 15ms pour l’ensemble des participant. On peut alors se demander pourquoi avec le cache activé les performances ne sont pas les meilleures.

Taille des bibliothèques :
Smarty 2.6 : 74,7 Ko (2classes) + 44,1 (22 sysplugins) + 104.6Ko (45 plugins) = 223,4Ko (69 fichiers)
Smarty 3.0b7 : 19Ko (1 classe) + 511 Ko (134 sysplugins) + 97,8 Ko (42 plugins) = 627,8Ko (177 fichiers)
Smarty 3.0b8 : 26,6Ko (1 classe) + 511Ko (60 syspluigns) + 97,8Ko (42 plugins) = 635,4Ko (103 fichiers
Dwoo 1.1.1 : 42,5 (1 classe) + 223Ko (37 syspluigns) +130,7Ko (63 plugins) = 396,2Ko (101 fichiers)

On peut voir que Smarty 2.6 est la bibliothèque la plus légère. Et Smarty 3.0b la plus lourde (plus de 2 fois plus lourde). Dwoo est quand à lui 50% plus lourd que Smarty 2.6, cela explique certainement la différence de temps d’affichage d’un template compilé mais pas seulement. Le nombre de fichiers à lire est également important pour Dwoo est Smarty 3.0b, le temps d’accès au disque peut expliquer également cela. Il existe des versions « compilées » de Smarty et Dwoo (non utilisé pour ces tests) qui permettent le chargement d’un seul fichier, le temps d’accès disque ainsi que le parsing sont réduits. Cependant Smarty 2.6 restera plus rapide compte tenu de son faible poids.

Analysons maintenant l’empreinte mémoire de ces moteurs de template

Memory

Memory

Précédemment nous avons pu voir que l’avantage allait indéniablement à Smarty 2.6 qui s’avère être le plus rapide, voyons maintenant ce qu’il en est pour l’empreinte mémoire.

Quelle est la consommation de mémoire lorsque le cache est activé ? Lorsqu’une application est en production le cache est activé pour éviter de compiler les templates à chaque appel, cette valeur à donc une certaine importance.
Dans cette configuration, tous les moteurs sont en dessous de 850Ko, ce qui est un bon point, on remarquera que Smarty 2.6 est à 585Ko ce qui constitue le meilleure score. Dwoo et Smarty 3.0beta ont une consomation un peut supérieur à celle de Smarty 2.6 mais rien d’alarmant.

Lorsque le moteur de template est configuré sans cache, le moteur doit compiler entièrement le fichier template, pour cela il passe par plusieurs phases, comme l’analyse syntaxique, puis la transformation en code php à proprement parler. On peut voir que Smarty 3.0b consomme deux fois plus de mémoire que Smarty 2.6 avec 2,4Mo utilisés. L’explication est assez simple, lors de la compilation, le moteur analyse le code qui peut potentiellement utiliser des plugins, nous avons vu plus haut que Smarty 3.0b a une centaine de fichiers « plugins » et « sysplugins » qu’il doit charger pour compiler les templates ; ils représentent environ 600Ko, contre 140Ko pour Smarty 2.6 et 350Ko pour Dwoo. Intéressons nous maintenant aux bons élèves que sont Dwoo et Smarty 2.6. Dwoo est à 1,5Mo ce qui constitue un bon score, mais qui évidement s’il est revu à la baisse sera un atout. Smarty 2.6 est le moteur qui consomme le moins de mémoire avec 1,0 Mo. On peut expliquer cela par son faible poids, et des optimisations plus poussée.
Comme pour les tests sur le temps tout à l’heure, la consommation de mémoire lorsque le cache est désactivé n’est pas la valeur la plus importante car en production le cache est activé et on arrive dans cette situation uniquement lors du premier appel à la page.

En mode « développement » et « production commune », la consomation de mémoire est strictement identique. avec des valeurs en dessous de 760Ko. Comme toujours Smarty 2.6 est le plus légé avec 525Ko.

Dans cette première partie de tests nous avons pu voir que Smarty 2.6 est le meilleur moteur de template aussi bien en terme de consommation mémoire qu’en terme de rapidité de traitement, que le cache soit activé ou non. Dwoo est bien placé également. Smarty 3.0b a des résultats assez proches de ceux de son grand frère Smarty 2.6, mais il n’est malheureusement pas meilleur et a une consommation mémoire trop importante lorsque l’on force la compilation. Dwoo quant à lui a des résultats corrects et se situe entre Smarty 2.6 et Smarty 3.0.

Nombre de requêtes servies par seconde

Request per second

Request per second

Voyons maintenant comment ces moteurs supportent la charge. En environnement de production certains sites à forte charge peuvent recevoir des milliers de requêtes il est important de connaitre le comportement de ces moteurs de template dans ce cas précis.

Nous allons nous intéresser dans un premier temps au nombre de requêtes servies par seconde, tout d’abord lorsque la compilation est forcée. Les courbes reflètent les résultats que nous avons pu analyser précédemment sur le temps d’exécution. Encore une fois Smarty 2.6 est en tête avec environ 60 requêtes par secondes. Dwoo le talonne avec environ 40 requêtes par seconde suivi de Smarty 3.0b avec moins de 20 requêtes par seconde.
Lorsque le cache est activé, on obtient des performances satisfaisantes, avec plus de 165 requêtes par seconde pour l’ensemble des concurrents. Smarty 2.6 est encore une fois le meilleur élève avec près de 250 requêtes par seconde. Dwoo et Smarty 3.0 sont à peu près équivalents aux alentours de 180 requêtes par seconde.
En mode « développement » (force check compile), les performances sont satisfaisantes avec environ 130 requêtes par seconde pour Smarty 3.0beta, mais Smarty 2.6 tire son épingle du jeu avec plus de 185 requêtes par secondes. Les résultats sont similaires lors que la vérification de compilation est désactivée. On peut d’ailleur se demander si elle a vraiment un intérêt.

Ces résultats reflètent donc exactement les mesures relevées lors de l’étude des temps d’exécution.

Temps moyen de traitement pour une requête

Time per request

Time per request

Pour finir étudions le temps moyen nécessaire pour servir une requête.
Lorsque le la compilation est forcée, Smarty 2.6 est fidèle à lui même et prend la tête avec environ 80ms, il est suivi par Dwoo avec environ 135ms. Smarty 3.0b est largement à la traine avec plus de 290ms pour servir une requête soit près de 4 fois plus lent que son grand frère.
Lorsque le cache est activé les tendances sont bonnes avec un score inférieur à 30ms pour l’ensemble des concurrents. Smarty 2.6 est toujours en tête avec moins de 21ms pour générer une page, Smarty 3.0b et Dwoo sont à peu près équivalents avec 30ms environ.
Dans la configuration de « développement » avec la vérification de la compilation activé, les performances sont bonnes avec moins de 40ms pour l’ensemble des moteurs testé, Smarty 2.6 est toujours en tête. lorsque la vérification de la compilation est désactivé, les performances restent similaire à la configuration en « développement ».

Pour conclure, Smarty 2.6.26 est actuellement le meilleur moteur de template parmi ceux testés ici. Il est à la fois celui qui consomme le moins de mémoire et le plus rapide, que le cache soit activé ou non. Dwoo est une bonne alternative puisque ses performances talonnent très souvent Smarty 2.6. Smarty 3.0b est assez décevant en terme de consommation de mémoire lors de la compilation, mais mis à part celà, ses performances sont très bonnes et sont proches de celle de Smarty 2.6. N’oublions pas que c’est une version beta et que l’équipe de développement travaille activement, puisque l’on a droit à une nouvelle version beta toutes les trois à quatre semaines environ. Espérons qu’il feront une grosse passe d’optimisation en particulier sur la consommation mémoire. Ce test sera mis à jour au fil des évolutions de ces trois moteurs de template. A ce jour EmisFR continue d’utiliser Smarty 2.6.x en attendant de pouvoir passer sur Smarty 3.0. Dwoo est pour le moment écarté car non compatible avec les logiciels déjà produits, de plus le langage de template est un peu différent et étant donné que ses performances sont moins bonnes que celles de Smarty 2.6.x il présente peu d’intérêt de changer.