Drupal chez edipresse : bilan technique

La webfactory d'edipresse suisse vient de sortir un site d'annonces classées sous Drupal : edicom.ch. Il s'agit du 12éme site commercial sortis depuis 2 ans sous cette technologie chez Edipresse après femina.ch, nashagazeta.ch, lesquotidiennes.ch, lematin.ch, tdg.ch, 24heures.ch, kursus.ch, vivamea.com, annabelle.ch, swisster.ch et edipub.ch. La majorité des sites ont été réalisé en interne par la webfactory - cellule technique de 12 personnes que je dirige -, le site Swisster.ch a été réalisé en interne par l'équipe de Swisster, le site Edipub.ch a été réalisé par la société parisienne Adyax - société qui a réalisé des développements aussi pour les autres sites d'Edipresse concernant certains modules ou opérations commerciales -.
Notons aussi la refonte du site Corporate d'Edipresse à savoir http://www.edipresse.com sous Drupal aussi qui consisterait le 13éme site produit.

Les sites Edipresse sous Drupal réalisent actuellement environ 200'000 visites quotidiennes pour un peu plus de 35 millions de pages vues par mois. L'ensemble de l'infrastructure est partagé par les instances Drupal (une par site) au sein d'un hébergement dedié chez Infomaniak qui assure la mise à disposition et la gestion de la salle blanche. La Webfactory assure le day to day système sur l'ensemble du parc se reposant sur son prestataire systéme SCRT pour les opérations les plus sensibles et la sécurité.

Quel est le bilan technique de l'utilisation de Drupal au sein d'Edipresse depuis 2 ans ?

+ Bilan technique

Les drupal en version 5 et 6 ont connu une augmentation de trafic de l'ordre de 100 à 150 %. Cette augmentation de trafic a été gérée par une augmentation du parc matériel mais aussi par des ajustements applicatifs. Les 35 millions de pages vues mensuelles sont gérées par 8 serveurs frontaux, 3 bases et 1 NFS. L'ajout de 1 à 2 serveurs frontaux donnerait plus de latitude et serait plus confortable.

Nos drupals les plus sollicités fonctionnent sous des couples MySQL master / slaves pour les plus gros sites (24heures.ch, tdg,ch, lematin.ch). C'est un patch maison qui permet de gérer l'aiguillage des requêtes SQL vers les 8 slaves ou les 2 masters. L'utilisation de MemCache s'est révélée être aussi obligatoire ainsi que l'installation du compilateur PHP X-CACHE. Nous cumulons les slaves avec les frontaux afin d'optimiser au mieux nos machines.

La résistance à la charge donne globalement satisfaction avec des bémols sur le drupal "de base"comme le mix entre des tables MyISAM et InnoDB. En forte solliciation les MyISAM peuvent se bloquer (LOCK, DEADLOCK) et ainsi provoquer un empilement des requêtes qui amène à une saturation de l'ensemble du parc de machine. Il faut donc passer en innoDb l'ensemble des tables qui ne le sont pas pour éviter ces effets d'empilement (stack de requêtes).

Le module "view" par son moteur de requêtage puissant produit aussi des requêtes qui ne sont pas optimisées. Son utilisation intensive et unique amène de fait à un gaspillage d'energie matérielle. D'un autre coté il permet aussi d'accèlérer les développements. Un curseur est donc à trouver entre le "tout view" et le "custom SQL". Les sites à très fort trafic doivent se poser la question d'une utilisation minimale des vues.

Toutefois les périodes de crise sur la charge des bases de donnée font parties des crises de croissance successives quand on atteint des paliers d'utilisation du back office ou une forte audience sur le front office.

Ces crises sont récurrentes et arrivent maintenant par cycle tout les 2-3 mois quand les trafics et/ou l'utilisation du back et/ou la complexité des pages (le nombre d'objet que chaque page attaque) augmentent.

La richesse des modules ne se dément pas et leur qualité non plus. Drupal 6 (on verra le 7) propose un écosystéme sûr et stable surlequel une industrie peut se reposer.

+ Courbe d'apprentissage des développeurs

La webfactory d'edipresse a travaillé en 2010 avec 6 développeurs webs. Les courbes d'apprentissage sur Drupal restent rapides et efficaces. Un développeur est efficace au bout d'1 mois sur les problématiques de maintenance voir 1 à 2 semaines en ce qui concerne la configuration complexe, 2 mois pour commencer un nouveau projet. Toutefois Drupal en proposant des boites à outil prêtes à l'emploi ne permet pas pas de développer les compétences "algorythmiques" en masquant une part des problémes complexes au développeur. Sur ce point il n'existe aucun solution miracle mais on peut se rapprocher parfois de l'effet "clicodrome" où on configure plus qu'on programme. Attention donc de bien donner des tâches variées dont des tâches de développement module qui obligent à coder au sens propre du terme. L'outil reste sinon facile d'accès et aimé des développeurs qui se l'approprient vite.

+ Ergonomie Drupal pour les utilisateurs

Une enquête faite au sein des équipes online edipresse montre clairement que l'ergonomie de l'outil est plébiscitée. C'est plus sa simplicité qui séduit et sa faible complexité apparente. Tout nos utilisateurs utilisent les interfaces brutes de Drupal : peu sont configurées avec des besoins spécifiques en terme de layout et/ou d'ergonomie. Des ponts avec des outils métiers (SAP, Méthode, Guichet virtuel) ont été effectué sans souci majeur autre que ceux de traitement de flux XML que Drupal sait très bien gérer "nativement" même si php - et drupal - reste avec des performances médiocres en terme de rapidité de traitement de XML comparées à d'autres technologies (perl en particulier) plus proche de la machine et faites pour des traitements de chaine en masse.