Commencer une section de code vérifie l'accès à de nombreux fichiers de données (fichiers plats donc chaque table est un fichier) et lorsque je fais une capture de paquets, dans notre capture, seule l'info d'en-tête est envoyée par le serveur au client. Cependant, j'ai un Client qui utilise un SAN qui reçoit tout le fichier au lieu de juste l'info d'en-tête, et en plus d'être plus lent, cela cause des problèmes d'accès aux fichiers. Ils ont déjà désactivé les OPLOCKS sur le serveur et sur les postes de travail. Ce n'est pas client-serveur. Les fichiers de données et l'application résident sur le serveur mais les utilisateurs exécutent l'application en local via un raccourci avec un lecteur mappé ou UNC.
Donc quand je sélectionne simplement une option qui demande un numéro de véhicule, sans essayer de sélectionner un enregistrement mais plutôt simplement vérifier que les fichiers de données sont accessibles, cette fenêtre s'ouvre en 1 à 2 secondes pour moi. Quand ils font la même chose, cela prend 6 à 15 secondes après que plusieurs utilisateurs exécutent le programme. Le nombre maximum d'utilisateurs est de 15. Le programme a beaucoup de petits modules, 800 modules .cob. Donc c'est très bavard mais ce sont des fichiers de données.
Nous avons des captures Wireshark qui montrent qu'il tire tout le fichier et nous n'obtenons que l'en-tête. Leur capture vs la nôtre. Nous soupçonnons le SAN.
Est-ce que quelqu'un a déjà entendu parler d'un SAN interprétant incorrectement les demandes d'exécution? Donc une requête SMB. Ceci est Acucobol-GT (maintenant Microfocus). L'application est écrite en COBOL. Ce n'est pas un nouveau programme juste un nouveau problème. C'est un client parmi plus de mille qui fonctionnent par ailleurs correctement et nous sommes totalement perplexes.
Tous les utilisateurs XP, le serveur est Windows 2003 (avec un serveur virtuel) et je ne connais pas encore les informations du SAN. Nous avons également de nombreuses installations exécutant des serveurs virtuels mais seulement quelques-unes sur des SAN ou nous ne le savons tout simplement pas. Ce n'est pas un problème de débit réseau, la charge est inférieure à 5% sur le serveur et il n'y a pas de délais d'attente ou de retransmissions.
PS Si ce n'était pas pour Wireshark, je serais encore en train de me perdre en conjectures. Un fichier trace de l'application sur leur installation ressemble juste à ce qu'ils sont plus lents. Si vous voulez le fichier trace de Wireshark, je peux le rendre disponible.
Merci d'avance - Veuillez excuser ma verbeosité (mot?) mais je ne suis pas sûr de ce qui est pertinent.
