Голям SQL резултат през VPN: къде чакат редовете

Заявките могат да завършат за милисекунди и въпреки това да отнемат минути, за да стигнат до лаптоп през VPN. Сървърът записва редове в буфери, връзката ги пренася, а клиентът ги консумира, и тези етапи се застъпват, вместо да вървят последователно. Всеки от тях може да стане ограничението. Открийте етапа, който действително чака, преди да промените честотната лента или да включите компресия.

Три етапа, един хронометър

Разделете таймера на две числа с различно значение: моментът, в който първият ред е наличен, и моментът, в който последният ред е консумиран. Мрежата, която рисува първата страница, доказва само, че заявката е започнала. Времето за пълния резултат е това, което потребителят изпитва при експорт или превъртане до края.

Запишете двете числа заедно с текста на заявката, параметрите и настройките на връзката. Без този контекст сравнението е между две различни задачи, а не между две местоположения.

Прочетете чакането преди мрежата

SQL Server записва редовете от резултата в изходни буфери, от които клиентът ги изтегля, и клиент, който консумира бавно, може да накара сървъра да чака на това изпращане. Типът на чакане е ASYNC_NETWORK_IO и бележката на Microsoft за отстраняване на неизправности изброява големите резултати и обработката от страна на клиента сред причините. Чакането ви казва, че пътят на изпращане е блокиран, а не защо.

Бавен VPN може да допринесе, но също и клиент, който форматира всеки ред, записва във файл или прави паузи между партидите. Името на чакането е указател към следващото измерване, а не присъда за връзката.

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

Четете брояча, докато ограниченото натоварване работи, а не след празен час, защото кумулативните броячи смесват всяка сесия от стартирането на екземпляра. Сравнявайте разликата за пробега, а не общата стойност за целия живот. Нарастващата разлика по време на прехвърлянето стеснява въпроса до консумация или доставяне.

Сложете двата клиента на един часовник

Стартирайте ограничено натоварване от клиент близо до базата данни и от отдалечения клиент. Дръжте заявката, параметрите, размера на резултата и настройките на връзката идентични. Използвайте едно и също измерване от двете страни, защото времето за изпълнение на сървъра, времето за показване на мрежата и времето за експорт са три различни часовника. Сравняването на число от сървъра с таймер за експорт от клиента дава заключение, което не може да бъде проверено.

Когато пътят изглежда виновен, накарайте собственика на мрежата да следи загуби, повторни предавания и постигната пропускателна способност за точно този поток, докато тече прехвърлянето. Общ тест за скорост може да използва друг маршрут, крайна точка или модел на паралелност. Малка успешна заявка казва малко за продължително прехвърляне на резултат.

Намалете байтовете, преди да обвинявате пътя

Филтрирането, агрегирането и изборът само на нужните колони намаляват както обема на прехвърлянето, така и работата на клиента с всеки ред. Запазете предвидения резултат, защото отчетът може да се нуждае от подробност, която обобщението на екрана не дава.

За повторяеми експорти одобрено място за изпълнение близо до базата данни може да запише дефиниран изход, който след това се доставя веднъж. Това променя работния процес и контрола му на достъп и не е разрешение да оставите неограничен дъмп на споделен хост.

Компресията не е подразбиращото се решение. Поддръжката и сигурността зависят от действителния протокол и внедряване, а компресиран поток, който клиентът разкомпресира бавно, може да влоши преживяването. Измерете първо етапа, после изберете поддържана промяна за този етап.