Applications lentes : le réseau mis en cause en premier, pourquoi?

Lorsqu’un ticket est remonté au helpdesk pour indiquer qu’une application est lente, pourquoi est-ce toujours le réseau qui est d’abord mis en cause ?

Je vois deux raisons essentielles à cela :

• La première est historique et simple : le réseau des années 90 et début 2000 était souvent le point de congestion et l’expression « le réseau est lent » est restée.
• La seconde est plus complexe et tient à l’organisation de l’entreprise et plus précisément à l’organisation de la DSI ; c’est ce deuxième point sur lequel nous allons faire un focus.

Au travers de cette explication, nous allons voir quels sont les mécanismes mis en œuvre pour la résolution des dégradations de performance d’une application au sein de l’entreprise et finalement au sein du service réseau/infrastructure.

Tout d’abord pourquoi le service réseau est mis en cause et pas un autre au sein de la DSI?

Le service réseau est le service transverse par excellence en ce sens qu’il voit passer tous les flux (voir points rouges schéma ci-dessous) et peut donc potentiellement être impliqué dans tout ralentissement qu’il soit associé à :

• Une seule application
• Un ou plusieurs sites
• Un data center
• Un service SAAS
• Un utilisateur
• Un serveur
• Un cluster
• Plusieurs applications

Que l’organisation soit en silo ou non, que la collaboration entre les équipes réseau, systèmes, application, production ou encore développement soit effective ou non, ce sera donc le plus souvent l’équipe réseau qui sera chargée de comprendre et résoudre les ralentissements.

Les différentes catégories de lenteurs applicatives

Poursuivons le mécanisme du paragraphe précédent. Si nous analysons les processus de flux de réclamation au sein de l’entreprise, lorsque les utilisateurs remontent des problèmes de lenteur sur leur application, ils adressent leur mécontentement via différents circuits selon l’organisation et le niveau hiérarchique :

1. Pour une lenteur ponctuelle sur une application donnée, il s’adressera :
   • Au helpdesk / support niveau 1
   • À l’équipe en charge de la gestion de l’application (cas rare)
   • À l’équipe réseau dans le cas de structures réduites
2. Si la lenteur est récurrente, (c’est qu’elle n’a pas été résolue par l’équipe applicative) elle sera traitée différemment car elle est déjà passée à plusieurs reprises par le helpdesk et donc son traitement se fera directement par le service réseau
3. Si la lenteur impacte la production, ce sera directement le réseau qui sera en charge de prendre le lead et dans des cas exceptionnels, le développement
4. Si la lenteur est subie par un responsable de l’entreprise, de la même manière, il s’adressera à l’équipe réseau

On constate donc que quoi qu’il arrive, c’est à l’équipe réseau de prendre en charge une lenteur applicative.

Pourtant, nous savons tous aujourd’hui, dans les entreprises, qu’une lenteur applicative a plus souvent une cause, une origine différentes que le réseau.

Voyons donc les causes réelles de dégradation de performance d’une application

D’après une étude auprès de nos clients, nous avons constaté que les causes les plus fréquentes de ralentissements applicatifs sont :

1. Un serveur trop sollicité
2. Une requête de BDD trop lent ou mal écrite
3. Un load balancing mal géré et donc un serveur plus sollicité que les autres
4. Une requête http lente
5. Une application mal écrite
6. Un seveur DNS mal configuré
7. Manque de ressources sur les serveurs d’applications
8. Problèmes liés au stockage (nombre d’I/O ou débit insuffisant)
9. Un PC utilisateur défaillant
10. Un problème réseau (pour en savoir plus téléchargez notre livre blanc : Top dix des causes d’un ralentissement réseau

Une seul sur 10 de ces causes est relative au réseau, 2 sur 10 si l’on prend en compte le DNS, néanmoins, l’équipe réseau a donc la charge de la gestion des ralentissements applicatifs.

Quels choix se présentent à l’équipe réseau?

2 cas possibles pour nos ingénieurs réseau

Selon leur périmètre de responsabilité et le choix de fonctionnement de l’équipe réseau, ils devront recueillir / mesurer différentes informations.

CAS 1 : SE DEDOUANNER

• Vous êtes en charge du réseau,
• Votre périmètre est restreint au seul réseau
• Vous n’avez pas l’autorisation ou ne souhaitez pas élargir ce périmètre

Dans ce cas votre préoccupation est de montrer que le réseau n’est pas en cause, vous résoudrez le problème si c’est le réseau qui est responsable. Alors votre job est terminé. Votre objectif n’est pas nécessairement de résoudre le ralentissement mais de montrer que ce n’est pas le réseau (1 cas sur 10, voir précédemment).

De quelles informations avez-vous besoin pour arriver à vos fins :

• Des mesures précises au moment où les problèmes se produisent ou se sont produits pour les personnes impactées :
  • Latences réseau (RTT) des personnes impactées
  • Charge des liens : % utilisation de la bande passante, montant et descendant
  • Retransmissions éventuelles
  • Informations de performance relatives aux équipements réseau (SNMP généralement)
  • Valeurs de MTU
• Un système de qualification synthétique basé sur les informations listées précédemment vous informant sous forme de couleur rouge, orange vert de la qualité du réseau
• Conservation de ces données détaillées d’au moins 15 jours, jusqu’à 4 semaines

CAS 2 : RESOUDRE ; le plus complexe et le plus intéressant !

• Vous êtes en charge du réseau.
• Votre périmètre est restreint au seul réseau.
• Vous avez la responsabilité de la résolution de l’incident et vous pouvez être amené à collaborer avec vos collègues des différents services de la DSI.

Dans ce cas, quelle que soit l’origine du ralentissement, vous êtes le mieux placé pour le résoudre. POURQUOI ?

Parce que la place d’observateur que vous possédez est la meilleure qui soit. En effet, tous les échanges entre les différentes sources possibles de ralentissement passent par le réseau. Vous avez donc la possibilité d’avoir une vue macro et micro sur tous les éléments qui composent la fourniture du service applicatif.

Certes mais comment avoir l’information? Par où commencer?

Le moyen de plus rapide est de CONTEXTUALISER :

• Du point de vue MACRO ; est-ce circonscrit à :
  • L’application seule ou plusieurs ou toutes
  • Un user, plusieurs, tous
  • Un site ou plusieurs ou tous
  • Un serveur (de mon load balancer) ou plusieurs ou tous
  • Un Data Center …
  • Le serveur frontal, applicatif ou de BDD

Une vue Matricielle pourra apporter les premiers éléments de réponse, elle vous permettra d’un seul coup d’œil de vous faire une idée synthétique et donc contextuelle des performances de vos applications. Par exemple ci-dessous, nous pouvons restreindre le périmètre des problèmes de ressenti utilisateur pour 1 application aux échanges entre les sites « remote sites » et « servers » (dans ce sens et pas dans l’autre). Bien d’autres métriques pourront permettre d’autres investigations, comme la latence, l’EURT (End User Response Time : Temps de réponse utilisateur final) ou encore le CT (temps de connexion applicatif) …

Une navigation en 4 clics vous permettra aussi d’investiguer à partir de dashboards synthétiques de la performance de votre application. Pour ce type de contextualisation voir aussi notre article sur le diagnostic en 4 clics.

• Du point de vue MICRO ; est-ce relatif à
  • Un Vlan, plusieurs, tous ?
  • Une transaction HTTP… ?
  • Une URL
  • Un hit dans ma transaction ?
  • Une transaction SQL, Oracle… ?
  • Une transaction SMB… ?
  • Une requête DNS… ?

Par exemple, via l’analyse des flux réseau, nous pouvons décrypter le détail du téléchargement d’une page web et des différents hits qui la composent.

Les technologies actuelles permettent l’analyse des flux réseau temps réel des couches 2 à 7. Toutes ces informations peuvent donc être qualifiées en quelques instants à partir des échanges qui passent sur vos liens réseaux.

Parce que vous pouvez contextualiser toutes les informations, qu’elles soient relatives à vos collègues des applications, des systèmes ou encore de la production, votre situation en tant que « réseau » fait que vous êtes le seul à pouvoir analyser toutes les causes possibles de ces lenteurs applicatives car tous les échanges de données passent par le réseau.

Vous êtes donc les plus compétents et les mieux à même à faire le diagnostic lors des incidents remontés par les utilisateurs finaux.

Il vous reste à trouver la solution qui vous permettra de le faire!