La performance applicative dépend du code
Dossier par Pascal Sage, 507 mots
Quand il s'agit de réduire l'empreinte des applications web sur le réseau, le retour à la case développement se révèle parfois incontournable. Avant de se lancer dans le load balancing, vérifions si certaines requêtes ne peuvent pas être reformulées.
«Une application d'entreprise vit, et ses technologies de programmation ou d'accès aux données vieillissent vite. Alors, on ajoute parfois une couche d'innovation, puis une autre. Et l'on finit avec un empilement difficile à pérenniser. Quand on veut optimiser les performances ou les temps de réponse, il faut aussi veiller aux contraintes d'exploitabilité. On a souvent besoin de revenir au code source», remarque Patrick Joubert, directeur technique d'ITS Group. Idéalement, les ingénieurs de la production et ceux de l'intégration doivent faire le lien entre les études et l'exploitation. C'est ainsi que l'on industrialise les processus de production informatique et que l'on peut apporter «un regard critique sur les développements et sur les architectures proposées». Gérer la production informatique forme une véritable valeur ajoutée.
En quête des goulets d'étranglement
Et cette introspection n'est pas forcément synonyme de retour à la case départ. Dans de nombreux problèmes de temps de réponse, il est fréquent que l'on puisse réduire le nombre de requêtes vers les gestionnaires de données ou les regrouper. L'utilisation des caches disponibles sur les navigateurs web est souvent bénéfique également. Effectuer des tests de montée en charge et vérifier chaque point faible d'une chaîne de services intranet ou Internet n'est pas un luxe : «Les éventuels goulets d'étranglements peuvent se situer au niveau du réseau, de l'application ou des liens vers les SGBD. Nous donnons des pistes pour améliorer les applications quand le besoin s'en fait sentir», souligne Arnaud Bertrand, directeur technique de Jet Multimedia. Il rappelle que les compétences sur les couches basses n'interdisent pas la compréhension des flux applicatifs et recommande de faire la chasse aux sockets surabondants et aux mécanismes propriétaires, car «plus les traitements et les contenus sont normalisés, mieux cela se passera», observe-t-il.
Equilibrer les charges
L'équilibrage de charges n'est pas compliqué à mettre en oeuvre. On le rencontre souvent associé à une forme ou une autre d'accélération protocolaire ou applicative, avec des serveurs locaux ou distants : «Si l'application supporte une translation d'adresses, on peut l'équilibrer sur plusieurs plates-formes. C'est très simple à démontrer et utile aux plans de reprise d'activité. L'accélération et le load balancing peuvent aussi fonctionner côte à côte», confirme Christophe Leblanc, directeur technique Europe chez Radware. Cette organisation des serveurs derrière de gros commutateurs finit d'ailleurs par former un vaste blade server aux lames éclatées. En cas d'application lente, on peut placer une sonde sur le lien emprunté par le flux, mais la prochaine session passera-t-elle par le même chemin ? L'entreprise a toujours intérêt à privilégier la simplicité et la prédictabilité de son architecture : «On peut tout croiser. Mais, en cas de pépin, les problèmes de câblage deviennent plus difficiles à comprendre sur une trace réseau. Il faut être capable de dire ce qui va se passer, si on perd tel élément puis tel autre sur le réseau», prévient Christophe Leblanc.