Nagy SQL-eredmény VPN-en át: hol várnak a sorok

A lekérdezések ezredmásodpercek alatt befejeződhetnek, és mégis percekig tarthat, mire VPN-en át elérnek egy laptopot. A kiszolgáló sorokat ír a pufferekbe, a kapcsolat továbbítja őket, és az ügyfél fogyasztja őket, és ezek a szakaszok átfedik egymást ahelyett, hogy sorban futnának. Bármelyikük válhat a határrá. Találja meg a szakaszt, amely valóban vár, mielőtt sávszélességet változtat vagy tömörítést kapcsol be.

Három szakasz, egy stopper

Ossza fel az időmérőt két különböző jelentésű számra: arra a pillanatra, amikor az első sor elérhető, és arra, amikor az utolsó sort elfogyasztották. Az a rács, amely kirajzolja az első oldalt, csak azt bizonyítja, hogy a lekérdezés elkezdődött. A teljes eredmény ideje az, amit a felhasználó az exportáláskor vagy a végére görgetéskor tapasztal.

Jegyezze fel mindkét számot a lekérdezés szövegével, a paraméterekkel és a kapcsolati beállításokkal együtt. E kontextus nélkül az összehasonlítás két különböző feladat, nem két helyszín között történik.

Olvassa el a várakozást a hálózat előtt

Az SQL Server kimeneti pufferekbe írja az eredménysorokat, hogy az ügyfél lekereshesse őket, és a lassan fogyasztó ügyfél várakozásra kényszerítheti a kiszolgálót ezen a küldésen. A várakozás típusa ASYNC_NETWORK_IO, és a Microsoft hibaelhárítási jegyzete a nagy eredményeket és az ügyféloldali feldolgozást is az okok között sorolja fel. A várakozás azt mondja, hogy a küldési útvonal blokkolt, nem azt, hogy miért.

Egy lassú VPN hozzájárulhat, de egy olyan ügyfél is, amely minden sort formáz, fájlba ír, vagy szünetet tart a kötegek között. A várakozás neve a következő mérésre mutató jelzés, nem ítélet a kapcsolatról.

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

A számlálót a korlátozott terhelés futása közben olvassa, ne egy üres óra után, mert a kumulatív számlálók az példány indítása óta minden munkamenetet összekevernek. A futás alatti deltát hasonlítsa össze, ne az élettartam teljes összegét. Az átvitel alatt növekvő delta a fogyasztásra vagy a kézbesítésre szűkíti a kérdést.

Állítsa a két ügyfelet ugyanarra az órára

Futtasson korlátozott terhelést az adatbázishoz közeli ügyfélről és a távoli ügyfélről. Tartsa azonosnak a lekérdezést, a paramétereket, az eredmény méretét és a kapcsolati beállításokat. Mindkét oldalon ugyanazt a mérést használja, mert a kiszolgáló végrehajtási ideje, a rács megjelenítési ideje és az exportálási idő három különböző óra. Egy kiszolgálóoldali szám összehasonlítása egy ügyféloldali exportálási időmérővel olyan következtetést ad, amely nem tesztelhető.

Amikor az útvonal tűnik felelősnek, kérje meg a hálózat tulajdonosát, hogy az átvitel futása közben figyelje a veszteséget, az újraküldéseket és az elért átviteli sebességet arra a konkrét folyamra. Egy általános sebességteszt más útvonalat, végpontot vagy párhuzamossági mintát használhat. Egy kis sikeres kérés keveset mond egy tartós eredményátvitelről.

Csökkentse a bájtokat, mielőtt az útvonalat hibáztatja

A szűrés, az aggregálás és csak a szükséges oszlopok kiválasztása csökkenti az átvitel mennyiségét és azt a munkát is, amelyet az ügyfél minden sorral végez. Őrizze meg a tervezett eredményt, mert egy jelentésnek olyan részletre lehet szüksége, amely a képernyőn látható összegzésben nincs meg.

Ismételhető exportokhoz az adatbázis közelében lévő jóváhagyott végrehajtási hely meghatározott kimenetet írhat, amelyet aztán egyszer kézbesítenek. Ez megváltoztatja a munkafolyamatot és annak hozzáférés-vezérlését, és nem engedély arra, hogy korlátlan dumpot hagyjon egy megosztott gazdagépen.

A tömörítés nem az alapértelmezett javítás. A támogatás és a biztonság a tényleges protokolltól és telepítéstől függ, és egy tömörített adatfolyam, amelyet az ügyfél lassan bont ki, ronthatja az élményt. Először mérje meg a szakaszt, majd válasszon támogatott változtatást ahhoz a szakaszhoz.