Un gros résultat SQL à travers un VPN : où les lignes attendent

Les requêtes peuvent se terminer en millisecondes et mettre malgré tout des minutes à atteindre un ordinateur portable à travers un VPN. Le serveur produit des lignes dans des tampons, la connexion les transporte et le client les consomme, et ces étapes se chevauchent au lieu de s’enchaîner. Chacune d’elles peut devenir la limite. Trouvez l’étape qui attend réellement avant de changer la bande passante ou d’activer la compression.

Trois étapes, un chronomètre

Séparez le chronomètre en deux nombres qui n’ont pas le même sens : l’instant où la première ligne est disponible et l’instant où la dernière ligne a été consommée. Une grille qui affiche la première page prouve seulement que la requête a commencé. Le temps du résultat complet est ce que l’utilisateur vit lorsqu’il exporte ou fait défiler jusqu’à la fin.

Notez les deux nombres avec le texte de la requête, les paramètres et les réglages de connexion. Sans ce contexte, la comparaison porte sur deux travaux différents, pas sur deux emplacements.

Lisez l’attente avant le réseau

SQL Server écrit les lignes du résultat dans des tampons de sortie que le client récupère, et un client qui consomme lentement peut faire attendre le serveur sur cet envoi. Le type d’attente est ASYNC_NETWORK_IO, et la note de dépannage de Microsoft cite les gros résultats et le traitement côté client parmi ses causes. L’attente indique que le chemin d’envoi est bloqué, pas pourquoi.

Un VPN lent peut y contribuer, mais aussi un client qui met en forme chaque ligne, écrit dans un fichier ou marque des pauses entre les lots. Le nom de l’attente est un pointeur vers la mesure suivante, pas un verdict sur le lien.

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

Lisez le compteur pendant que la charge de travail bornée s’exécute, pas après une heure d’inactivité, car les compteurs cumulatifs mélangent chaque session depuis le démarrage de l’instance. Comparez le delta sur la durée de l’exécution plutôt que le total depuis le début. Un delta croissant pendant le transfert resserre la question sur la consommation ou la livraison.

Mettez les deux clients sur la même horloge

Exécutez une charge de travail bornée depuis un client proche de la base de données et depuis le client distant. Gardez la requête, les paramètres, la taille du résultat et les réglages de connexion identiques. Utilisez la même mesure des deux côtés, car le temps d’exécution du serveur, le temps d’affichage de la grille et le temps d’exportation sont trois horloges différentes. Comparer un nombre côté serveur à un chronomètre d’exportation côté client produit une conclusion qui ne peut pas être testée.

Quand le chemin semble responsable, demandez au responsable réseau de surveiller les pertes, les retransmissions et le débit obtenu pour ce flux précis pendant le transfert. Un test de débit générique peut utiliser une autre route, un autre point de terminaison ou un autre modèle de concurrence. Une petite requête réussie dit peu de chose sur un transfert de résultat soutenu.

Coupez des octets avant d’accuser le chemin

Le filtrage, l’agrégation et la sélection des seules colonnes nécessaires réduisent à la fois le volume transféré et le travail que le client fait sur chaque ligne. Préservez le résultat prévu, car un rapport peut avoir besoin d’un détail qu’un résumé à l’écran n’a pas.

Pour des exportations reproductibles, un emplacement d’exécution approuvé près de la base de données peut écrire une sortie définie qui est ensuite livrée une fois. Cela change le flux de travail et ses contrôles d’accès, et ce n’est pas une autorisation de laisser un vidage non restreint sur un hôte partagé.

La compression n’est pas la réparation par défaut. La prise en charge et la sécurité dépendent du protocole et du déploiement réels, et un flux compressé que le client décompresse lentement peut dégrader l’expérience. Mesurez d’abord l’étape, puis choisissez un changement pris en charge pour cette étape.