Il arrive souvent que des endroits fassent des erreurs dans leurs enregistrements inversés. Vous pouvez dire que vous avez des enregistrements inversés foirés parce que si vous exécutez quelque chose comme netstat -a et cela prend beaucoup de temps pour fonctionner et vous obtenez un tas d'adresses IP dans la base de données. rfc1918 espace d'adressage. Le fait de ne pas avoir d'enregistrements inversés dans cet espace n'est pas vraiment un problème en soi, mais cela est un problème si les personnes chargées du DNS font suivre leurs demandes de DNS aux fournisseurs ou à un serveur DNS en panne.
Un moyen rapide de vérifier s'il s'agit d'un problème de DNS est de se connecter au système et de rechercher l'IP d'une personne connectée au système (regardez dans netstat -a et recherchez les connexions établies), puis exécutez
nslookup a.b.c.d (or whatever the IP of that host is)
si vous avez un ancien système, vous devrez peut-être taper
nslookup d.c.b.a.in-addr.arpa.
Dans les deux cas, le résultat peut être quelque chose comme "impossible de trouver cette adresse" mais la réponse doit revenir rapidement . Les délais d'attente DNS peuvent être de l'ordre de quelques secondes, et si vous avez 3 serveurs DNS dans votre resolv.conf, votre serveur va essayer chacun d'entre eux avant d'abandonner. Cela peut facilement s'ajouter à une quantité de temps vraiment ennuyeuse.
Un moyen rapide d'illustrer le problème à votre patron est d'exécuter netstat -an et ensuite exécuter netstat -a puis dire "si notre DNS fonctionnait correctement, les deux s'exécuteraient en presque exactement le même temps".
S'il s'agit d'un problème d'enregistrement inverse, vous pouvez probablement "régler" le problème en désactivant les recherches inversées dans vos applications. Dans cette situation, cela peut être plus facile que de faire intervenir un autre groupe.
Il est également possible qu'il y ait un décalage duplex entre vos serveurs et leurs commutateurs. Vous pouvez le vérifier en examinant la sortie de (Windows) netstat -e ou (unix) netstat -i. Vous recherchez des "erreurs" ou des "collisions". Si vous voyez des "collisions", votre extrémité est mal configurée ; elle est en semi-duplex et devrait être en duplex intégral. Si vous voyez des "erreurs", l'extrémité du commutateur est semi-duplex et vous êtes full duplex. Les deux compteurs devraient être nuls, ou du moins faibles et ne pas augmenter. Ces problèmes peuvent être vraiment difficiles à localiser car la liaison fonctionnera plutôt bien si elle n'est pas chargée et s'effondrera complètement lorsqu'il y aura beaucoup de trafic.
0 votes
Pouvez-vous ajouter de la journalisation à vos appels AJAX pour obtenir des horodatages du moment où les choses sont reçues, et du moment où elles sont renvoyées ? Est-il possible que les méthodes que vous appelez soient en fait en train de perdre du temps au lieu du réseau ?
0 votes
Bonjour mpeterson, il ne semble pas y avoir de délai d'attente, il faut juste 60 secondes pour que la requête soit complète, c'est presque comme si les paquets prenaient beaucoup de temps pour arriver au serveur. Avec le serveur CVS, le serveur ne voit pas la demande avant 60 secondes après que je l'ai faite (en utilisant SSH), une fois que la session est établie, elle revient presque immédiatement. Les requêtes AJAX et les autres requêtes HTTP se trouvent sur un autre serveur et semblent se heurter à un délai d'attente. Je n'ai qu'un accès limité à ce serveur et il s'agit de Windows, ce qui me permet de diagnostiquer les problèmes plus facilement que sous Linux.