Présentation
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é des Services 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 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 bureaux à 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
CPU élevé du 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 l'Architecture Cato Cloud fournit des étapes détaillées pour accomplir cela.
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 attribuée au site est correcte. Allez dans Réseau > Sites > Configuration du site > Général
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 du Site.
Perte de Paquets
La perte de paquets peut se produire au sein de l'infrastructure Cato ou avec le Fournisseur de services Internet (ISP). Les étapes suivantes visent à isoler la source de la perte de Paquets.
Vérifiez la perte de paquets (amont/aval) dans l'Analytique Réseau.
Si cela coïncide avec la perte de paquets sur le dernier tronçon, cela indique un problème potentiel de matériel avec le câble connecté au port WAN du Socket ou un problème avec le Fournisseur (ISP).
Reportez-vous à la section Résolution des pertes de Paquets pour des suggestions sur la résolution des 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.
Si l'application affectée est critique, déplacez-la vers une classe de priorité supérieure pour améliorer les performances. Reportez-vous à Résolution des rejets de paquets (QoS) pour des instructions sur la configuration des classes.
Une autre raison du rejet de paquets est la micro-rafale. Consultez vérification des micro-rafales pour comprendre ce que cela signifie, comment en identifier une et enfin quelles étapes suivre pour la 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 Socket
Débit maximal en tunnel
X1500
500Mbps
X1600
1Gbps
X1600 LTE
1Gbps
X1700
3Gbps
X1700B
10Gbps
Consultez Guides de Déploiement des Sockets Cato 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 constante et élevée du CPU concomitante à 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.
Considération de performance : Débit WAN Actif/Actif
Dans les environnements WAN Actif/Actif, le débit de l'application peut être limité lorsque tous les flux de données s'agrègent temporairement sur un seul lien WAN au lieu de se répartir uniformément sur tous les liens disponibles. Lorsque cela se produit, le débit total est plafonné par la bande passante d'un lien, plutôt que d'utiliser la bande passante combinée de plusieurs liens.
Ce comportement peut affecter les attentes en matière de performance, en particulier pour les protocoles comme SMB qui reposent sur plusieurs flux simultanés. La distribution des flux est influencée par des conditions réseau dynamiques et par des algorithmes internes, qui ne garantissent pas toujours une utilisation équilibrée des liens.
Note : Si vous constatez un débit qui ne correspond pas aux performances attendues sur plusieurs liens WAN, veuillez contacter le Support Cato pour une enquête et une assistance supplémentaires.
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 supérieur aux attentes, validez que le site est connecté à un PoP optimal en naviguant vers Surveillance > Topologie 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 correspond bien à la règle 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. Consultez Meilleures Pratiques pour l'Accélération TCP pour davantage de détails.
Latence accrue du 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 Accélération TCP, Hors Cloud. ou Alt-WAN.
Les services hébergés dans les environnements Cloud public, tels que Azure ou AWS, peuvent tirer parti de l'Interconnexion Cloud pour réduire significativement 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 Activation de l'Option de Redimensionnement de la 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\ParametersRecherchez 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 globaldepuis l'invite de commandes. 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.
Reportez-vous à Testing the link with iPerf pour plus d'informations sur le test iPerf dans l'UI Web Socket.Note : Pour des résultats plus précis, il est recommandé d'utiliser UDP comme protocole de test car il ne prend pas en compte le contrôle de congestion. Gardez à l'esprit que ce test vise à déterminer le débit maximal réalisable du lien.
(Optionnel) Surveillance de l'Expérience dans le Dernier Tramo
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 des détails sur la configuration, consultez Routage du Trafic vers un Lien Hors-Cloud.
Résoudre les 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'améliore pas le problème de perte de paquets dernièrement, contactez votre fournisseur Internet pour isoler davantage le problème.
Si une forte perte de paquets est constatée, envisagez d'activer l'atténuation de la perte de paquets pour le trafic VoIP. Référez-vous à Optimisation du Trafic pour les détails.
Consultez Comment résoudre la perte de paquets des sites 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, consultez 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 PoP préféré nouvellement défini, tel que configuré dans Réseau > Sites > SLA de Connexion. Cependant, la reconnexion peut aussi être déclenchée manuellement en utilisant l'action Se reconnecter à un 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.
Ouverture de dossiers auprès de Cato Support
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 Self-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.