Nous avons choisi le petit framework Phalcon - l'un des plus rapides du moment - dans l'un de nos projets Drupal 8. Voici pourquoi... Et un peu comment !
Drupal en 2017
Le temps des projets motorisés par des outils "monolytiques" a vécu. Aujourd'hui, il y a du javascript partout - nodeJS dans le backend, une collection de frameworks pour les front-ends -, nous connectons les sites à de nombreux services externes, nous travaillons avec plusieurs versions de sites, qui font l'objet d'amélioration et livraison continues... En 2017, nous produisons un code qui réunit souvent plusieurs applications.
Drupal 8 et symfony nous permettent de répondre, le plus souvent, à ce type de problématiques... On s'appuie alors sur son API. Mais nombre d'entre nous font désormais appel, en fonction des contraintes, à des outils et langages tiers.
Nous vous invitons, au passage, à ré-écouter l'excellente présentation de @cbourgeaux au meetup de Paris de janvier dernier.
Drupal ne résout pas tous les problèmes
Dans le cadre d'un projet très récent, nous devons accoster un site Drupal 8 à une collection de flux de données, dans des volumes conséquents, en garantissant une vitesse d'affichage record. Nous nous sommes posés la question de l'utilisation, ou non, de Drupal dans ce cas de figure.
Drupal est un CMS, ce qui signifie que sa fonction première est de gérer du contenu, la réalité est que c’est ce qu’il sait faire de mieux. Nous allons donc l’utiliser pour cet aspect et substituer les fonctions qu’il fait de manière moins performante par des solutions plus légères et rapides.
Rappelons que nous sommes dans le cas d’un site à très fort trafic - comprenant des pics de trafic important, sur des périodes très localisées - Le trafic peut être multiplié par 30 pendant 1 heure.
La solution retenue : Phalcon !
Qu’est-ce que c’est ?
Phalcon est un framework PHP codé en langage C. Il s'agit d'une sorte de bibliothèque de classes C pré-configurées et prêtes à l’emploi. Le fait que ces classes soient pré-compilées permettra de gagner du temps lors de l’exécution de chaque tâche, ce qui aura pour effet de répondre aux requêtes plus rapidement, et donc de pouvoir répondre à un nombre de requêtes plus élevé.
Dans le cadre du site à très fort trafic, chaque centième de seconde est important et chaque retard de réponse à une requête se répercutera sur la requête suivante. Vous l’aurez compris, dans le cas où il y aurait plusieurs milliers de requêtes par minutes, les temps de chargement peuvent rapidement s’avérer très importants.
Phalcon nous sert ici d'intermédiaire entre une source de données brutes au format XML que nous devons traiter, agréger, nettoyer des éléments non utiles au site en amont et Drupal. Phalcon se comporte vis à vis de Drupal comme une API REST au format JSON.
Si nous avions directement utilisé Drupal (voir Symfony) pour traiter ces XMLs, les temps de traitement auraient été beaucoup trop longs.
Comment fonctionne Phalcon ?
Lorsque l'internaute souhaite afficher une page, il déclenche l'appel d'une méthode au webservice "Phalcon".
Ce dernier traite le XML en cours, et renvoie les données à Drupal au format JSON, avec juste le nécessaire à l'affichage. Bien entendu, nous utilisons du cache pour limiter les traitements entre 2 requêtes peu espacées dans le temps.
Après tout dépend du type de page sur laquelle on se trouve :
- Soit les données sont injectées dans le template Twig de la page en question ;
- Soit directement transmise à un widget (VueJS pour ne pas le citer) qui prend le relais sur l'affichage.
Plus concrètement, Phalcon sera installé sur le serveur du site sur lequel nous souhaitons travailler. Contrairement aux autres frameworks PHP, celui-ci est une sorte d’extension, plus difficile à installer.
Pourquoi Phalcon ?
Comme mentionné plus tôt, la problématique principale de ce site est d’être capable de traiter un nombre considérable de requêtes par minute sans allonger les temps de réponse... Tout en optimisant au maximum le ratio coûts/performances.
Phalcon nous permet également une séparation plus clair entre l'affichage (Drupal) et le traitement de ces données métiers.
En se fiant à une analyse comparative produite par Blog A Way Out, nous pouvons constater que Phalcon est bel et bien capable de gérer notre problématique.
Phalcon vu du côté système
Il est difficile de fournir un retour d’expérience complet concernant la l’utilisation de Phalcon, nous en sommes seulement au début du projet. L’optimisation des performances d’un site internet est une problématique qui est au cœur des préoccupations "Système". Chaque projet est traité sous un nouvel angle afin de fournir la meilleure solution selon le profil du site du client. Dans notre cas, la contrainte d’optimisation a été poussée au plus loin avec Phalcon qui a su dépasser (et de loin) toutes les solutions similaires. Ces performances sont dues à son langage de programmation, orienté bas niveau, qui permet au serveur de traiter les requêtes de manière beaucoup plus rapide.
Lors du développement d’un site internet, il y a une balance à équilibrer concernant le bas et le haut niveau. Lorsque le développement est effectué en bas niveau, le développement sera plus lent, mais la vitesse d’exécution sera beaucoup plus rapide. Concernant le haut niveau, le développement sera plus rapide, au détriment de la performance, car le code devra être interprété, ce qui prend du temps - beaucoup plus qu’un code bas niveau directement exécuté dans le langage du serveur.
De plus, lors de la création d’un site Drupal, de nombreux modules sont utilisés et combinés les uns avec les autres. Les modules n’étant pas codés spécifiquement pour fonctionner les uns avec les autres, il arrive que ceux-ci causent des ralentissements dans l’exécution de certaines tâches, en plus du temps d’exécution lié à Drupal lui-même.
Nous avons décidé de rentre Drupal headless car son front-end est très « haut niveau », pour atteindre nos exigences de performances. Nous avons donc besoin de déployer du code plus bas niveau, c’est ce qui sera fait avec Phalcon. Dans le cas de ce site, Phalcon sera utilisé pour développer le backend-hub et le front Ajax.
Nous avons en outre créé un site Drupal "anonyme" qui est dédié à la gestion de contenu. Il ne gérera aucun cookie, aucune session, aucun utilisateur. Lorsque Drupal aura besoin d’une information, il passera par une API pour demander cette information au back-end de Phalcon.
Finalement, Drupal va agir comme une surcouche, lorsque l'utilisateur s’identifiera - il s’identifiera sur le site codé avec Phalcon, et c’est Phalcon qui gèrera sa requête. Lorsque des informations variables doivent être diffusées sur le site, elles seront envoyées depuis le Hub du site vers le front-end Phalcon qui s’occupera de les afficher de manière automatique à l’utilisateur final.
Comme cité précédemment dans l’article, Drupal est utilisé seulement dans le domaine où il excelle : La gestion de contenus.
En conclusion, que penser de Phalcon ?
Il est encore trop tôt pour porter une conclusion définitive sur les capacités du couple Phalcon/Drupal à supporter de très nombreuses requêtes en condition réelles. Cependant, les tests de montée en charge que nous avons mis en place ont permis de constater qu’il y a effectivement une amélioration drastique du temps de réponse aux requêtes, en comparaison avec les frameworks "classiques".
Il convient de relativiser quant à l’utilisation de Phalcon. Codé en langage de bas niveau, sa mise en place et son utilisation s’avèrent plus longs et plus compliqués, ce qui implique un budget plus important. La question à se poser est très simple : Mon site internet montre-t-il des signes de faiblesses lors de montées du nombre de connexion ?
Pour aller plus loin : https://phalconphp.com/fr/
