Twig et comment optimiser son API Symfony2

Twig, le composant de gestion de templates par défaut dans Symfony est intégré mais est désactivable pour une API par exemple.

Quand j'ai dit que je travaillais avec Symfony2 pour mon API, le premier commentaire a été : "mais pourquoi tu utilises Symfony ?". On peut évidemment se demander pourquoi, sachant qu'une API est souvent RESTFul. Je vais donc vous expliquer pourquoi nous utilisons Symfony2 chez Wanadev.

Symfony2 et ses outils

Avant tout, lorsque l'on m'a confié ce projet, celui-ci était déjà développé avec Symfony, et cela parce que l'API n'était pas RESTFul au départ. Celle-ci retournait des iframes. L'héritage était donc là et Symfony offre de nombreux outils pour « packager » ce type d'application. Gestion de la sécurité, des templates… Parfait à ce moment !

Avec le temps, nous avons voulu rendre plus light notre service et donner à notre API une véritable image d'API en la rendant progressivement RESTFul. Cela n'est pas un travail aisé, car tous les services rattachés doivent suivre le « mouvement » et s'adapter. Lorsque cette opération a été terminée, nous avions alors deux possibilités qui se présentaient à nous :

1. Réécrire l'API avec un framework plus léger comme Silex
2. Garder le code existant et tenter d'alléger les modules utilisés par Symfony (ça, on sait faire chez Wanadev)

Un choix a rapidement été fait. Nous avons déjà développé une API Silex, un framework léger et rapide, mais qui au fil du temps à tendance à grossir considérablement de par l'ajout des modules non natif. Si Silex possède le défaut d'être complètement vide initialement (mais c'est également sa marque de fabrique), Symfony possède l'inconvénient inverse d'embarquer de nombreux modules nativement. Il suffit de regarder le composer.json de Symfony pour faire ce constat.

Nous avons donc préféré Symfony, de par la possibilité de développer rapidement tout notre code métier, mais aussi par sa communauté en perpétuel agrandissement.

Choix des composants essentiels

Dans Symfony, pour tous ceux qui hésiteraient encore, sachez que de nombreux modules sont utiles. Certains pourront être désactivés et d'autres sont intégrés dans le core et sont par conséquent indétachables.

Twig, le composant de gestion de templates par défaut dans Symfony est intégré et il est donc impossible de l'enlever. Le framework requiert Symfony/TwigBundle qui requiert à son tour Twig/Twig, le moteur de template a proprement parlé. Comme je viens de le dire, Twig ne donc pas être enlever, de plus certains composants très utiles comme symfony/web-profiler-bundle requiert l'engine pour générer la « debug bar » qu'on apprécie lors de nos développements.

Mais ne perdons pas espoir ! Il existe tout de même une solution pour désactiver Twig. Le web profiler est acif uniquement lorsqu'il a été chargé pour un environnement donné. De base, Symfony propose deux environnements, dev et prod. Le premier ajoute quelques modules. Voici ceux qui sont présents initialement :

• WebProfilerBundle
• SensioDistributionBundle
• SensioGeneratorBundle

Ils nous proposent des outils uniquement pour l'environnement de développement. Ce qui va permettre de ne pas surcharger l'environnement de production que l'on veut rapide.

Désactiver Twig dans Symfony

Comme nous l'avons vu plus haut, le web profiler requiert Twig, nous allons simplement l'activer pour l'environnement de développement.

public function registerBundles()
{
    $bundles = array(
        …
    );

    if (in_array($this->getEnvironment(), array('dev', 'test'))) {
        $bundles[] = new Symfony\Bundle\TwigBundle\TwigBundle();

        $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
        $bundles[] = new Sensio\Bundle\DistributionBundle\SensioDistributionBundle();
        $bundles[] = new Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle();
    }

    return $bundles;
}

De cette manière, Twig sera désactivé pour l'environnement de production.

Ensuite, nous allons supprimer la configuration de Twig qui se trouve dans app/config/config.yml et l'ajouter dans app/config/config_dev.yml.

# app/config/config_dev.yml
twig:
    debug:            "%kernel.debug%"
    strict_variables: "%kernel.debug%"

Pour finir, vous devez indiquer au SensioFrameworkExtraBundle (si vous l'utilisez) que votre moteur de template n'est plus Twig mais qu'il s'agit du moteur PHP.

Benchmark

Personnellement, lorsque je lis un article sur l'optimisation d'un composant j'aime bien avoir des preuves de la véracité des affirmations avancées. Pas de soucis, j'ai effectué un petit siege sur ma machine dans des conditions similaires et comparé le nombre de « hits » réalisés.

Avant chaque siège, j'ai effectué un cache:clear et un cache:warmup pour mettre en cache un peu de code et attaquer immédiatement dans le vif du sujet. J'ai bien évidemment testé en appelant l'environnement de production, et en appelant une page retournant un JSON. Le siège a été effectué en lancant 50 threads concurrents pendant 60 secondes (siege -b -c 50 -t60s url).

[caption id="attachment_739" align="aligncenter" width="605"] Benchmark - Symfony2 sans TwigBundle[/caption]

Je pense que le constat est sans appel, ne vous fiez pas à la taille des barres mais plutôt aux nombres de transactions. Avec TwigBundle, notre API a répondu à 1154 requêtes alors que sans TwigBundle, ou plutôt en le désactivant, notre code a répondu à 1258 transactions dans le même temps imparti.

Avec un bref calcul, cela nous donne un coefficient de 1.09 (1258/1154). Notre API est donc 9% plus rapide sans TwigBundle. Le peu de changement à effectuer comparé au gain réalisé est important. Dès lors qu'on ne sert pas de ce module, il y aurait donc peu d'intérêt de s'en passer.

Conclusion

Utiliser Symfony pour réaliser une API peut être un choix tout à fait sensé. De plus, le fait de désactiver Twig pour l'API n'empêche pas d'utiliser Twig. Ce dernier sera toujours installé avec l'installation de Symfony et vous pourrez tout de même générer des templates simples pour des parties particulières.