Parlons franchement. Ou des œufs à la crème. Ou des boîtes de bonbons. Qu'ont-ils en commun ? Ils sont tous associés aux vacances, bien sûr. Et il s’avère que ces vacances sont la première source de profits et de mauvaises performances pour les 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.
L'équilibrage de la charge nécessite une compréhension de la charge existante afin que les nouvelles demandes soient dirigées vers la ressource la plus susceptible de pouvoir répondre le plus rapidement possible. L'équilibrage de charge de base ne peut pas y parvenir car il se concentre uniquement sur des décisions basées sur des algorithmes, qui prennent rarement en compte autre chose que la pondération statique des ressources disponibles. Les décisions en temps réel nécessitent des informations en temps réel sur la charge existante à ce moment-là . Sinon, vous n'équilibrez pas la charge, vous la répartissez .
Il s’agit de bien plus qu’une simple sélection de ressources qui contribue à améliorer les performances tout en équilibrant la charge. Il est également essentiel de pouvoir utiliser une variété de fonctions d’amélioration du protocole qui réduisent la charge sans nuire à la disponibilité. Le multiplexage et la réutilisation des connexions TCP, le déchargement du cryptage et de la sécurité et la réaffectation des tâches de compression aux services en amont soulagent les applications et les services Web, ce qui libère des ressources et a un impact réel sur 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.
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 simultanément de capacité (connexions), moins vous avez besoin d'instances. Cela réduit les frais généraux liés à la gestion d’une autre couche de ressources qui nécessitent une attention tout aussi minutieuse à 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.