Ce qui est assez bien n’est assez bien que jusqu’à ce que ce ne soit plus le cas

Parlons franchement. Ou d’œufs à la crème. Ou de boîtes de bonbons. Qu’ont-ils en commun ? Ils sont tous liés aux fêtes, bien sûr. Et en réalité, ces fêtes génèrent à la fois les plus forts profits et les pires performances des sites web.

Considérez une étude récente menée au Royaume-Uni , « qui a impliqué plus de 100 décideurs du commerce électronique ». Elle « a révélé que plus de la moitié (58 %) ont admis avoir été confrontés à des problèmes de vitesse de site Web pendant la période de pointe de l'année dernière ».

Nous savons tous que les performances sont importantes et que même quelques microsecondes de retard peuvent entraîner des pertes de plusieurs millions de dollars. C'est tout ce qu'il faut dire.

La question est : que pouvez-vous faire à ce sujet ?

La réponse réside dans le rappel de l’axiome opérationnel n°2 : À mesure que la charge augmente, les performances diminuent.

Peu importe que le serveur d’applications soit exécuté dans le cloud ou dans le centre de données, dans une machine virtuelle ou dans un conteneur. Cet axiome est un axiome parce qu’il est toujours vrai. Quoi qu'il en soit. Plus vous chargez un système, plus il fonctionne lentement. Période.

La clé pour de meilleures performances est d’équilibrer la nécessité de réduire les coûts en maximisant la charge tout en optimisant simultanément les performances. Dans la plupart des cas, cela signifie utiliser tous les outils dont vous disposez pour rétablir cet équilibre, en particulier face aux périodes de pointe (qui exercent une forte pression sur les systèmes, où qu’ils se trouvent).

1. Équilibrer la charge

C'est pourquoi les services d'applications suffisamment bons (rudimentaires) ne le sont pas. Car même s’ils s’adaptent souvent sans effort, ils n’équilibrent pas nécessairement la charge entre les ressources disponibles. Ils ne fournissent pas nécessairement l’intelligence nécessaire pour sélectionner les ressources en fonction des performances ou de la charge existante. Leur « meilleur effort » ne vaut guère mieux que le hasard.

Pour équilibrer la charge, vous devez comprendre la charge existante afin d’orienter les nouvelles requêtes vers la ressource capable de répondre le plus rapidement. L’équilibrage basique ne peut y parvenir, car il se base uniquement sur des décisions algorithmiques, qui tiennent rarement compte de quoi que ce soit d’autre que la pondération statique des ressources disponibles. Les décisions en temps réel exigent des informations actualisées sur la charge en cours maintenant. Sinon, vous ne faites pas un équilibrage de charge, mais une simple répartition. 

2. Réduire la charge

Ce n’est pas seulement la sélection des ressources qui soutient l’amélioration des performances tout en équilibrant la charge. Pouvoir appliquer diverses fonctions d’optimisation de protocole qui réduisent la charge sans diminuer la disponibilité est également crucial. Le multiplexage et la réutilisation des connexions TCP, le déchargement du chiffrement et de la sécurité, ainsi que le transfert des tâches de compression vers les services en aval allègent les applications et services web, libérant des ressources serveur et améliorant réellement les performances.

Les serveurs doivent fonctionner, qu’ils soient dans le cloud ou dans le centre de données, exécutés dans un conteneur ou une machine virtuelle. La cryptographie et la compression sont toujours des fonctions gourmandes en calcul qui peuvent être exécutées par des services en amont conçus pour cette tâche.

3. Éliminer la charge

L’élimination des sauts supplémentaires dans le chemin de requête-réponse améliore également les performances. Oui, vous pouvez effectuer une mise à l'échelle horizontale entre les services d'équilibrage de charge, mais cela ajoute une autre couche de prise de décision (routage) à l'équation qui prend du temps à la fois en termes d'exécution (lequel d'entre eux doit traiter cette demande ?) et en termes de temps de transfert (l'envoyer sur le réseau à celui -là). Cela signifie moins de temps pour que le serveur Web ou d'application fasse son travail, ce qui est vraiment tout ce que nous voulions au départ. Sous une charge normale, les différences entre un système gérant un million de connexions et dix systèmes gérant chacun une partie de ce million de connexions peuvent être négligeables. Jusqu’à ce que la demande entraîne une charge plus élevée et que les axiomes opérationnels entrent également en jeu. Car ce n’est pas seulement la charge sur le serveur Web ou d’applications qui contribue aux mauvaises performances, mais l’ensemble de la chaîne de diffusion des applications.

Plus votre service d'équilibrage de charge peut gérer de connexions simultanées, moins vous aurez besoin d’instances. Vous diminuez ainsi la charge liée à la gestion d’une couche supplémentaire de ressources, qui exige autant de rigueur pour respecter l’axiome opérationnel n° 2 que tout autre service.

La performance reste un enjeu majeur pour les détaillants et, avec l’expansion rapide de l’économie numérique, elle deviendra (si ce n’est pas déjà le cas) un problème pour tous ceux qui ont une présence numérique. Dans la précipitation qui précède toujours les vacances, les gens deviennent encore moins tolérants aux mauvaises performances. Ce qui était assez bon la veille ne l’est plus. Le plus souvent, les problèmes de performances ne sont pas la faute de l’application, mais plutôt de l’architecture et des services utilisés pour la fournir et la sécuriser. En utilisant les bons services avec le bon ensemble de fonctionnalités, les organisations sont plus susceptibles de pouvoir éviter les problèmes de performances sous une charge importante.

Ce qui est assez bien est assez bien, jusqu’à ce que ce ne soit plus le cas. Il est alors trop tard pour convaincre les clients frustrés de revenir. Ils ont déjà trouvé un autre fournisseur pour ce que vous essayiez de leur vendre.