Problèmes de performance pour le dépannage des sites Socket

Vue d'ensemble

Les clients peuvent rencontrer des problèmes de performance avec leurs applications pendant qu'ils sont connectés à Cato. Les problèmes de performance sont un sujet vaste et peuvent survenir à travers différentes couches OSI, de la couche physique à la couche applicative. Ce manuel se concentrera principalement sur les problèmes de performance jusqu'à la couche TCP. Les problèmes de performance liés aux couches applicatives seront discutés dans d'autres manuels :

Pour les problèmes de connectivité aux ressources Internet, consultez Dépannage de l'accessibilité du service Internet
Pour les problèmes de performance liés à un navigateur Internet lent, consultez Dépannage du temps de chargement et des problèmes de rendu des pages Web
Pour les problèmes liés à l'accès aux ressources internes, consultez Dépannage de l'accès aux ressources internes
Pour les problèmes liés à la VoIP et à la vidéo, consultez Dépannage de la VoIP

Symptômes

Transfert de fichiers lent, débit réduit
- Lorsqu'ils sont connectés à Cato Cloud, les clients peuvent éprouver des lenteurs de téléchargement et de vitesse de chargement.
Temps de réponse retardés dans les applications
- Cela pourrait être plus évident dans les applications interactives telles que les postes de travail à distance.

Causes possibles

Mauvaise configuration (QoS, Licence, Accélération TCP, Redimensionnement de fenêtre)
Congestion réseau
Perte de paquets (FAI, dernière ligne)
PoP non optimal
Haute CPU de Socket
Latence accrue du Cloud
Limitations de matériel

Dépannage du problème

Avant de procéder à un dépannage plus approfondi, il est essentiel de déterminer si cela est lié à Cato Cloud. Pour ce faire, nous pouvons contourner la connexion à Cato et vérifier si le problème persiste. Contourner Cato Cloud fournit des étapes détaillées sur comment l'accomplir.

Si le problème persiste malgré le contournement de la connexion, cela indique que Cato ne cause pas le problème. Cependant, si le problème est résolu après avoir contourné la connexion à Cato Cloud, suivez les étapes suivantes pour un dépannage et une isolation supplémentaires.

Configuration des licences et de la bande passante

Note : L'allocation de bande passante WAN est basée sur la licence du site et la configuration de bande passante de l'interface. Si les deux ont des valeurs différentes, la plus basse sera appliquée au lien WAN.

Validez que la licence affectée au site est correcte. Allez à Network > Sites > Site Configurations > General
Validez que la bande passante configurée de l'interface WAN est correcte. Allez à Network > Sites > Site Configurations > Socket > Editer l'interface WAN.
Pour les sites en Chine et au Vietnam, la licence est différente. La licence sera divisée en licences globales et régionales. La licence globale est pour les connexions aux sites mondiaux tandis que la licence régionale est pour les connexions dans le pays.
Pour plus d'informations sur la gestion des licences de site, consultez Gestion des licences de bande passante de site.

Perte de paquets

La perte de paquets peut se produire au sein de l'infrastructure Cato ou avec le fournisseur de services Internet (FAI). Les étapes suivantes visent à isoler la source de la perte de paquets.

Vérifiez la perte de paquets (montante/descendante) dans Network Analytics.
Si cela coïncide avec une perte de paquets sur la dernière ligne, cela indique un problème matériel potentiel avec le câble reliant au port WAN de la Socket ou un problème avec le fournisseur de services Internet (FAI).
Consultez la section Résolution de la perte de paquets pour des suggestions sur la façon de résoudre les problèmes de perte de paquets.

Rejets de paquets (Gestion de la bande passante)

Si vous voyez de nombreux rejets de paquets sur la page Network Analytics, cela signifie que les paquets sont rejetés en raison de la gestion de la bande passante (QoS). Pour déterminer si votre application est affectée par cela :

Naviguez vers Network > Priority Analyzer pour valider quelle classe rejette des paquets et si votre application est affectée à la même classe.
Si tel est le cas, envisagez d'allouer plus de bande passante pour cette classe.
Alternativement, si l'application affectée est critique, déplacez-la vers une classe de priorité plus élevée pour améliorer les performances. Consultez Résolution des rejets de paquets (QoS) pour les instructions sur la configuration des classes.
Une autre raison du rejet de paquets est la micro-rafale. Consultez vérification des micro-rafales sur ce que cela signifie, comment en identifier un, et enfin, quelles étapes suivre pour le résoudre.

Limites des ressources de Socket

La dégradation des performances peut se produire lorsque le Socket atteint sa limite de ressources.

1. Débit maximal pris en charge

Naviguez vers Network > Site > Network Analytics et vérifiez si le débit pour le site est dans la limite prise en charge.
Ci-dessous sont indiquées les capacités maximales de débit en tunnel de nos modèles de Socket :

Modèle de Socket Débit maximal en tunnel

X1500 500Mbps

X1600 1Gbps

X1600 LTE 1Gbps

X1700 3Gbps

X1700B 10Gbps
Consultez Cato-Socket-Deployment-Guides sur la fiche technique respective pour plus de détails.
Si vous dépassez les limitations listées, consultez Résolution du dépassement du débit pris en charge.

2. Utilisation élevée du CPU de Socket

La surutilisation des ressources de Socket entraînera également une dégradation des performances.
Depuis l'interface webUI de Socket, sélectionnez l'onglet de Status matériel. Cela affichera l'utilisation actuelle du % de CPU pour chaque cœur. Une utilisation élevée constante du CPU impactera directement les performances du Socket et provoquera une perte de paquets.
Si vous remarquez une utilisation élevée constante de la CPU concomitante avec une perte de paquets réseau, veuillez contacter le support pour obtenir de l'aide.
À partir de la version 21.1 des sockets physiques et de la version 22 des sockets virtuels, le tableau de bord des métriques d'utilisation du processeur pour le socket est désormais visible dans l'interface CMA. Accédez à l'Analytique Réseau dans l'interface CMA et sélectionnez l'onglet Matériel.
De plus, le tableau de bord des métriques d'utilisation du processeur est également disponible à partir de l'interface utilisateur du Socket, sous l'onglet État du matériel.

PoP sub-optimal

Lors de l'utilisation du cloud Cato, les clients peuvent remarquer une performance plus lente de l'application ou une réduction des vitesses de téléchargement/chargement.

Pour valider, effectuez un test PING sur le service affecté.
Si le RTT retourné est plus élevé que prévu, validez que le site est connecté à un PoP optimal en naviguant vers Monitoring > Topology et en cliquant sur le site.
Un panneau de fenêtre à droite apparaîtra. Cliquez sur "Voir le Log" à la base du panneau de fenêtre
Une autre fenêtre apparaîtra. Validez que le FAI est proche du PoP connecté.
Pour résoudre cela, consultez Résolution du PoP optimal.

Validation des règles réseau

Vérifiez que la connexion affectée frappe la règle de réseau correcte.
Si l'application affectée est une application de partage de fichiers ou une application web, créez une règle de réseau avec l'accélération TCP activée et placez la règle en haut de la liste pour l'isolation. Reportez-vous à Meilleures pratiques pour l'accélération TCP pour plus de détails.

Latence supplémentaire dans le Cloud

Les applications, telles que les services SQL, qui sont sensibles aux changements de latence peuvent prendre plus de temps à terminer les tâches lors de la migration sur le Cato Cloud.
La latence supplémentaire introduite par la réalisation de ces requêtes sur le WAN, même si ce n'est que quelques millisecondes, s'accumule vraiment lorsqu'on considère le nombre de requêtes.
Pour réduire la latence entre les sites, il est recommandé d'envisager de mettre en œuvre des solutions Cato telles que l'accélération TCP, Off-Cloud. ou Alt-WAN.
Les services hébergés dans des environnements de Cloud public, tels qu'Azure ou AWS, peuvent tirer parti de l'interconnexion Cloud pour réduire considérablement la latence entre les Sites.
Alternativement, les requêtes SQL peuvent être modifiées pour mieux fonctionner sur le Cato Cloud.

Redimensionnement de fenêtre pour les appareils Windows

Le redimensionnement de fenêtre dans TCP/IP permet de négocier une taille de fenêtre plus grande, permettant ainsi d'envoyer plus de données dans chaque paquet et d'améliorer les performances.
Il doit être activé par défaut. Pour valider cela, ouvrez l'invite de commande sur le périphérique Windows et exécutez la commande netsh interface tcp show global.
Recherchez le réglage "Niveau de réglage automatique de la fenêtre de réception", qui doit être réglé sur "normal".
Consultez l'Activation de l'option de redimensionnement de fenêtre TCP pour plus de détails.

Option d'horodatage TCP pour les appareils Windows

Le réglage par défaut pour les systèmes d'exploitation Windows ne prend pas en charge l'option d'horodatage TCP. Activez l'option d'horodatage TCP pour améliorer les mesures RTT des paquets, ce qui peut mieux aider à identifier les pertes de paquets.
Cette option aide également la pile TCP à ajuster le minuteur de retransmission en cas de perte de paquets.
Nous recommandons d'activer l'horodatage TCP sur vos ordinateurs Windows en suivant ces étapes:
- Ouvrez l'éditeur de registre sous Windows.
- Naviguez vers la clé suivante HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
- Recherchez une clé nommée Tcp1323Opts. S'il n'existe pas, vous devrez la créer comme une valeur DWORD (32 bits) et l'appeler Tcp1323Opts. Définissez la valeur sur 2.
- Redémarrez votre système.
Pour vérifier le statut des horodatages TCP, exécutez netsh int tcp show global depuis l'invite de commande. Les horodatages RFC1323 doivent être activés.

Tests iPerf

Un autre outil de dépannage qui aide à isoler le problème est iPerf. Les tests iPerf peuvent être utilisés pour mesurer le débit maximal réalisable sur le réseau. Cela est inclus dans l'UI Web Socket dans le cadre des tests de réseau et de connectivité et est accessible sous l'onglet Outils.
Consultez Test du lien avec iPerf pour plus d'informations sur la réalisation de tests iPerf dans l'interface utilisateur Web Socket.
Remarque: Pour obtenir des résultats plus précis, il est recommandé d'utiliser UDP comme protocole de test car il ne tient pas compte du contrôle de la congestion. Gardez à l'esprit que ce test vise à déterminer le débit maximal réalisable du lien.

(Facultatif) Surveillance de l'expérience Dernier kilomètre

Les clients disposant d'une licence de Surveillance de l'expérience peuvent vérifier les onglets Performance du dernier kilomètre et des applications pour détecter d'éventuelles pertes de paquets et de paquets rejetés. les données peuvent être corrélées avec les résultats de l'onglet d'analyse du réseau du site pour mieux comprendre d'où provient le problème.

Off-Cloud

À des fins de test, envisagez de configurer une installation hors Cloud entre les deux sites. Cette approche nous permettra de comparer les performances entre le Cloud et hors Cloud.
Cependant, il convient de noter que les moteurs de Protection contre les menaces de Cato n'inspectent pas le trafic hors Cloud.
Cependant, il est important de noter que les moteurs de protection contre les menaces de Cato n'inspectent pas le trafic hors cloud.
Pour les détails de la configuration, consultez Routage du trafic vers un lien hors Cloud.

Résolution des problèmes découverts

Résolution de la mauvaise configuration

Résolution de la perte de paquets

Si une perte de paquets dans le dernier kilomètre est présente, remplacez le câble connecté au port WAN du Socket.
Si possible, connectez-vous à un autre port WAN sur le Socket et le périphérique en amont. Si cela n'a pas amélioré le problème de perte de paquets dans le dernier kilomètre, contactez votre fournisseur d'Internet pour isoler davantage le problème.
Si une forte perte de paquets est observée, envisagez d'activer la Mitigation de la perte de paquets pour le trafic VoIP. Reportez-vous à Optimisation du trafic pour les détails.
Consultez Comment résoudre la perte de paquets sur le site Socket pour un dépannage détaillé de la perte de paquets.

Résolution des rejets de paquets (QoS)

Pour allouer plus de bande passante à la classe, naviguez vers Réseau > Gestion de la bande passante, sélectionnez la classe affectée et modifiez les limites en conséquence.
Pour déplacer l'application affectée vers une classe de priorité plus élevée, modifiez la règle de réseau existante de l'application affectée et baissez la priorité de BW (plus la valeur est basse, plus la priorité est élevée). Alternativement, créez une nouvelle Règle de réseau et attribuez à la priorité de BW une valeur plus basse.
Pour un guide détaillé sur la gestion de la bande passante, reportez-vous à Configuration des profils de gestion de la bande passante.

Résolution de la connexion à un PoP sous-optimal

Si l'appareil n'est pas connecté à un PoP optimal, vérifiez si le paramétrage "Emplacements POP préférés" est configuré. Pour ce faire, accédez à Réseau > Site > Configurations du site > Général > Emplacements POP préférés. Si le paramétrage a été défini incorrectement, sélectionnez l'emplacement optimal.
Le Socket se reconnectera automatiquement au nouveau PoP préféré tel que configuré dans Réseau > Sites > SLA de connexion. Cependant, la reconnexion peut également être déclenchée manuellement en utilisant l'action Reconnecter au PoP préféré, comme expliqué dans Reconnexion manuelle à un emplacement PoP préféré.

Résolution de l'excès de débit supporté

Contactez votre gestionnaire de compte ou votre gestionnaire de service client respectif pour passer à un Socket plus grand. Si vous ne savez pas qui ils sont, contactez le support.

Soumettre des cas au support de Cato

Si les étapes ci-dessus n'ont pas aidé à isoler et à résoudre le problème, veuillez ouvrir un cas avec le support de Cato. Lors de l'ouverture d'un cas, prenez en compte les questions suivantes et fournissez les réponses correspondantes :

Le problème affecte-t-il toutes les applications ou des applications spécifiques ?
Si cela affecte des application(s) spécifique(s), s'agit-il de nouvelle(s) application(s) ?
Pour nouvelle(s) application(s), veuillez fournir les détails, y compris le nom de l'application, la version, etc.
Qu'est-ce qui a changé pour les application(s) existante(s), entraînant le problème ?
Ce problème affecte-t-il tous les sites ou des sites spécifiques ? Si ce sont des sites spécifiques, veuillez énumérer les sites affectés
où se trouve le serveur si cela affecte tous les sites ?

Collecte de données

Veuillez collecter le Support en Libre-Service (SSS) tout en reproduisant le problème. De plus, installez Wireshark sur l'appareil et capturez deux ensembles de données de paquets :

Le premier ensemble de captures de paquets (PCAP) doit capturer le problème de performance. Ceci peut être fait simultanément lors de la collecte du SSS.
Le second ensemble de PCAP doit être collecté lorsque la connexion contourne le cloud Cato, c'est-à-dire lorsque le problème de performance n'est pas présent. Cet ensemble de données servira de référence pour le Support lors de l'examen des journaux collectés et du SSS.