Aujourd'hui, j'avais envie de revenir sur un point qui m'est particulièrement cher, l'optimisation. Malheureusement souvent négligé au profit du développement de toujours plus de nouvelles fonctionnalités, parfois mal intégrées en acceptant le rush imposé, ou totalement oublié car il n'apporte rien à la solution de base.

Et pourtant, ces petites millisecondes économisées sont cruciales pour un business Saas. Si votre page se charge en 5s ou 1.5s, le confort de vos utilisateurs s'en trouvera augmenté, et ils auront tendance à mieux utiliser votre plateforme. Mais surtout, une bonne gestion des performances vous permettra aussi de gérer les pics sur la même infrastructure, et de souvent simplifier celle-ci.

Pourquoi faire tourner un mastodonte sur un rack de 20 machines, alors qu'une seule pourrait suffire, réduisant du coup considérablement le rôle de l'admin système, et les problèmes éventuels. Et finalement, même considérant toutes les données traitées, toutes les stats générées, tout le trafic, la quasi-totalité tourne aujourd'hui avec une seule machine. Un monstre de guerre, mais ce n'est toujours qu'une seule machine.

On parle souvent de construire vite, et de faire le scaling après. Mais si on a construit trop rapidement, sans fondation, essayez d'y mettre une tour de 20 étages ! Et même si je suis partisan du principe de construire vite, ils ne faut pas oublier de garder un oeil sur la globalité, pour ne pas prendre un jour le sysadmin venant supplier pour encore plus de puissance.

Mais ... comment?

Cela doit être dans vos gènes. Dans mon développement, j'ai toujours, y compris avant Freedelity, passé quasi 25% de mon temps exclusivement dédié à surveiller les performances. A rechercher le maillon faible, à le remplacer, à le contourner, et surtout à essayer de comprendre.

Tout cela a commencé il y a bien longtemps, quand j'ai essayé de développer mon premier CMS en PHP. PHP était un rêve pour un développement rapide, mais comme j'avais tout écrit en orienté objet, et qu'on était à l'époque encore aux débuts de PHP4, les performances étaient tout simplement médiocre. J'ai donc abandonné le scripting pour passer à du pur compilé, et cela permets, toujours aujourd'hui, une différence pour un code similaire énorme en performance. Mais, cela ne suffit bien sûr pas, et passer à une plateforme à 100% compilée n'est pas non plus chose aisée.

Après la compilation, il a fallu optimiser tout le reste du système. A commencer par MySQL qui, bien que très sympathique, manque parfois un peu de puissance, et pour MySQL, la solution est simple, la machine qui héberge la base doit toujours avoir plus de mémoire que la taille de la base, pour pousser MySQL via sa configuration à tout laisser en mémoire. Vos disques vous en remercieront, et vous aurez encore gagné de précieuses millisecondes.

Puis on s'occupe du serveur web. Apache c'était bien... à l'époque. Aujourd'hui il n'a toujours pas évolué pour permettre de tenir une charge importante sans tuer complètement votre machine. De nombreuses alternatives permettent de gagner considérablement de charge. Mais il ne faut pas s'arrêter à cela, dès que vous avez votre serveur web, il faut le pousser au maximum en forçant par exemple un cache côté client pour tout ce qui est statique. Aucun besoin pour vos visiteurs de venir rechercher à chaque fois votre image ou jQuery, il y a peu de chances que cela ait changé entre 2 pages, et pourtant quasi aucun site ne configure proprement la manière dont est gérée le cache client.

Ne pas oublier de déporter un maximum du traitement côté client. Nous générons par exemple des gigas de statistiques, tout cela chaque nuit pour profiter des heures creuses, et éviter la charge en pleine journée. Certes on génère beaucoup de données (de 20 à 30gb) chaque nuit, dont 2 à 3gb utile, mais ces 3gb utiles auraient plombés la plateforme en pleine journée, alors que tout ceci pouvait être précalculé. Nous ne générons pas des gigabytes de statistiques vers une base de données, pas besoin d'encombrer la mémoire ici avec cela, mais nous séparons chaque morceau utile dans un fichier javascript différent. Et de ce fait, pour chaque statistique il suffit alors de combiner une série de scripts pour calculer ce qui est utile, tout en profitant du processeur du visiteur pour les derniers calculs.

Il y a encore plein d'autres astuces, comme l'utilisation de sprites, le regroupement de css, de js, etc, et l'utilisation massive de caches en mémoire, mais je ne vous dévoilerai pas tous les secrets non plus.

Juste quelques chiffres pour terminer, imaginez que sur une seule machine, vous puissiez générer plus de 1M de requêtes par jour, avec un load oscillant entre 1 et 1.5 au maximum (sur une machine à 2 Xeon), et des pages générées entre 10 et 50ms en moyenne.

Et pourtant, je suis sûr qu'il reste encore des centaines optimisations possibles! Alors, vous aussi, il est peut être temps de s'y plonger, non?

Sébastien