Великий результат 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';

Читайте лічильник, поки виконується обмежене навантаження, а не після порожньої години, бо накопичувальні лічильники змішують кожен сеанс від запуску екземпляра. Порівнюйте різницю за прогін, а не загальну суму за весь час. Зростаюча різниця під час передавання звужує питання до споживання або доставки.

Поставте обидва клієнти на один годинник

Запустіть обмежене навантаження з клієнта поблизу бази даних і з віддаленого клієнта. Тримайте запит, параметри, розмір результату та налаштування з’єднання ідентичними. Використовуйте те саме вимірювання з обох боків, бо час виконання сервера, час показу сітки та час експорту — це три різні годинники. Порівняння числа з боку сервера з таймером експорту на боці клієнта дає висновок, який неможливо перевірити.

Коли шлях виглядає винним, попросіть власника мережі стежити за втратами, повторними передаваннями та досягнутою пропускною здатністю саме для цього потоку, поки триває передавання. Загальний тест швидкості може використовувати інший маршрут, кінцеву точку або схему паралельності. Невеликий успішний запит мало говорить про тривале передавання результату.

Скоротіть байти, перш ніж звинувачувати шлях

Фільтрація, агрегація та вибір лише потрібних стовпців зменшують і обсяг передавання, і роботу, яку клієнт виконує з кожним рядком. Збережіть передбачуваний результат, бо звіту може знадобитися деталь, якої немає в підсумку на екрані.

Для повторюваних експортів затверджене місце виконання поруч із базою даних може записати визначений вивід, який потім доставляється один раз. Це змінює робочий процес і його керування доступом, і це не дозвіл залишати необмежений дамп на спільному хості.

Стиснення — не стандартне виправлення. Підтримка й безпека залежать від фактичного протоколу та розгортання, а стиснений потік, який клієнт повільно розпаковує, може погіршити враження. Спершу виміряйте етап, потім виберіть підтримувану зміну для цього етапу.