A ne pas s’y tromper, les performances de votre solution SaaS sont cruciales pour votre startup:

• d’un point de vue front, l’application est fluide, dynamique, il n’y a pas de chargements de pages intempestifs, quand il y en a cela se fait rapidement, sur ordinateur comme sur tablette ou smartphone
• du côté back, chaque utilisateur sur votre application ne consome pas grand chose comme ressources serveur, et 1000 (voire 100 000) utilisateurs connectés simultanément ne font pas tomber ou ralentir votre infrastructure

Il s’agit là du cas parfait, ne nous leurrons pas. C’est rarement ainsi au début de votre startup, car il y a bien d’autres combats à mener qu’améliorer les perfs (débugger par exemple?) et de toutes façons pas autant d’users sur la solution (ou alors vous êtes vraiment très forts!)

La question est donc la suivante: doit-on se soucier des performances de son application? Si oui, quand et comment s’en soucier? 

Bon, je vais casser le suspens et répondre de suite, car la réponse me parait sans équivoque: oui il faut y penser, mais ne pas s’en soucier de suite! Allez circulez, y’a plus rien à voir, la question est traitée! ;)

Plus sérieusement, la recherche des performances s’effectue au quotidien, mais à différents niveaux. Si vous pensez dès l’instant 0 comment construire votre architecture cloud, comment scaler en 10 minutes de 1 à 50 instances, comment mettre du sharding sur vos bases de données, comment load balancer, comment cacher.. je pense sincèrement que c’est faire fausse route, non pas que ces questions ne seront pas à se poser à un moment donné, mais certainement pas au début de votre aventure. C’est consacrer du temps et des forces inutiles à ce moment là alors que vous avez certainement mieux à faire alors.

Voila selon moi et d’après ce que j’ai essayé de mener au sein de Balloon, une relativement bonne approche je pense pour approcher de bonnes perfs sans réellement s’en soucier (en tout cas, sans encore avoir à mener d’importants chantiers purement perfs)

• Soignez votre architecture / code, tout le temps: c’est clairement le point primordial à mon sens, et cela rejoint mes derniers articles Ne codez pas de la merde et Utilisez des frameworks. Le plus important est de bien séparer les concerns: utilisez une couche Modèle (interaction avec vos bases, vos objets), une couche Business (vos actions, vos controleurs), une couche Vue (utilisez un moteur de template performant). Bien découpler, séparer, semble peut-être au premier abord plus gourmand en ressources, mais vous remercierez plus tard ce découpage lorsqu’il faudra mettre du cache ou effectuer des restructurations

• Pensez en terme de couches, et rajoutez des couches de caching: le découpage du point précédent fait clairement apparaitre 3 couches. Chacune son rôle, sa logique, mais aussi chacune son cache! Dans mon cas sous Symfony2 / Doctrine / Twig, je dispose de plusieurs layers de cache: le cache de Doctrine, qui utilise apc / memcache pour rendre rapidement les requêtes SQL déjà calculées et mises en cache, économisant ainsi du CPU, de la RAM et du temps d’attente en soulageant ma base de données. Twig se charge de cacher les templates compilés afin de les rendre plus rapidement à l’exécution. Enfin, l’utilisation du cache HTTP permet de mettre en cache le tout (page html générée mise en cache et rendue sans aucun traitement aux utilisateurs durant toute sa durée de cache). Attention, en aucun cas la logique du cache doit venir altérer la logique des autres couches, le cache doit se greffer par dessus, et la logique de chaque couche agnostique du cache. Cela permet non seulement d’y voir plus clair niveau logique, et de ne traiter à ce niveau que ce qui est relatif à votre application, mais aussi de pouvoir changer de cache facilement car votre logique n’en est pas dépendante.

• Identifiez les contenus qui sont dynamiques, et ceux qui le sont moins: c’est là de la  véritable magie, les ESI (Edge Side Includes) ou cache par fragments! Il est possible désormais de cacher différemment plusieurs blocs d’une même page. Cette flexibilité permet par exemple de ne jamais cacher la topbar de votre application dans laquelle se trouve des infos relatives à l’utilisateur connecté, ou alors de la passer en cache privé, tandis que le reste de la page est massivement caché en cache public et partagé par tous les visiteurs. Vous voila donc capables en séparant bien la logique de chaque bloc (rappelez vous le premier point, ça devrait être facile car déjà découplé! Regardez le point précédent, cela ne devrait pas altérer votre logique et votre fonctionnel! ;) ) et en identifiant les différents besoins de chacun, maitrisez le caching à merveille. Dans le cas de Balloon, nous utilisons cette fameuse topbar, mise en cache privé par utilisateur, pour mettre à disposition de notre applicatif javascript les data essentielles de l’utilisateur et de l’événement dans lequel il se trouve, tout le reste de la page étant massivement caché en cache public et rendu à l’identique à tous les utilisateurs. Le javascript va alors puiser dans nos APIs le nécessaire avec le caching approprié (par user, par event).

• Utilisez des APIs, partagez le traitement des données entre vos users et serveur: le javascript a fait d’énormes progrès ces derniers temps. A tel point que certains s’en servent désormais server-side, et de très bons frameworks ont vu le jour, permettant d’organiser votre code front comme vous ne l’aviez jamais fait. Profitez de cette opportunité pour déléguer une partie de votre applicatif directement à vos utilisateurs! Basez-vous sur vos propres APIs (que vous pouvez par la même occasion ouvrir au monde) et exploitez la puissance des navigateurs de vos utilisateurs pour une bonne partie de votre application! Mettez en cache chez eux les javascripts, propulsez-les statiquement via des CDN et concentrez vos efforts de cache sur vos APIs!

• Utilisez les bonnes technos: le panel de technos web disponibles de nos jours pour construire une bonne webApp laisse quand même rêveur. Nous sommes loin des années 2000 où tout était statique, où deux technos dominaient et où tout se faisait au rechargement des pages. Utilisez un bon framework bien robuste pour vos APIs (Symfony2 pour le PHP, Django pour le Python ou encore Rails pour Ruby), utilisez un bon framework pour vos javascripts (Backbonejs notamment), utilisez une base de données relationnelle pour vos traitements de fond, le gros de votre data, les stats. Utilisez du NoSql pour la data à moyenne persistance, les data “live”, la data de session. Utilisez du push (node.js, socket.io) pour propulser à vos utilisateurs connectés du contenu, sans venir agresser votre LAMP classique. Tirez partie de la puissance du cache et des ESI. Il y a vraiment des pistes à creuser en tout sens, et c’est vraiment fun comme perspectives :)

Tout cela pour dire (malgré un titre un brin racoleur..) qu’il ne devrait pas y avoir de chantier d’optimisation de performances à mettre en place au début de la vie de votre startup. Construisez votre applicatif en réfléchissant bien à l’architecture et les interactions des differentes technologies que vous mettez en relation au sein de votre projet. Ne vous souciez pas du cache ou des performances. Ajoutez-le au fur et à mesure que votre base d’utilisateurs grandit. Commencez sur un OVH mutualisé à faible coût. Passez sur un modeste serveur dédié une fois réellement nécessaire. Entamez des réflexions de cloud, de heavy caching et de scaling uniquement une fois tout ceci accompli, et pas avant.