Большой результат 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';

Читайте счётчик, пока выполняется ограниченная нагрузка, а не после пустого часа, потому что накопительные счётчики смешивают каждый сеанс с момента запуска экземпляра. Сравнивайте разницу за прогон, а не общую сумму за всё время. Растущая разница во время передачи сужает вопрос до потребления или доставки.

Поставьте оба клиента на одни часы

Запустите ограниченную нагрузку с клиента рядом с базой данных и с удалённого клиента. Сохраняйте запрос, параметры, размер результата и настройки соединения идентичными. Используйте одно и то же измерение с обеих сторон, потому что время выполнения сервера, время отображения сетки и время экспорта — это три разных часа. Сравнение числа со стороны сервера с таймером экспорта на стороне клиента даёт вывод, который нельзя проверить.

Когда путь выглядит виновным, попросите владельца сети наблюдать потери, повторные передачи и достигнутую пропускную способность именно для этого потока, пока идёт передача. Общий тест скорости может использовать другой маршрут, конечную точку или шаблон параллельности. Небольшой успешный запрос мало говорит о длительной передаче результата.

Сократите байты, прежде чем винить путь

Фильтрация, агрегация и выбор только нужных столбцов уменьшают и объём передачи, и работу, которую клиент выполняет с каждой строкой. Сохраните предполагаемый результат, потому что отчёту может понадобиться деталь, которой нет в сводке на экране.

Для повторяемых экспортов утверждённое место выполнения рядом с базой данных может записать определённый вывод, который затем доставляется один раз. Это меняет рабочий процесс и его управление доступом, и это не разрешение оставлять неограниченный дамп на общем хосте.

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