VPN을 통한 큰 SQL 결과: 행이 기다리는 곳

쿼리는 밀리초 만에 끝나도 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';

유휴 시간 후가 아니라 제한된 워크로드가 실행되는 동안 카운터를 읽으세요. 누적 카운터는 인스턴스가 시작된 이후 모든 세션을 섞기 때문입니다. 전체 수명 총계가 아니라 실행 중 델타를 비교하세요. 전송 중 델타가 커지면 질문은 소비나 전달로 좁혀집니다.

두 클라이언트를 같은 시계에 올리세요

데이터베이스에 가까운 클라이언트와 원격 클라이언트에서 제한된 워크로드를 실행하세요. 쿼리, 매개변수, 결과 크기, 연결 설정을 동일하게 유지하세요. 서버 실행 시간, 그리드 표시 시간, 내보내기 시간은 서로 다른 세 개의 시계이므로 양쪽에서 같은 측정을 사용하세요. 서버 측 숫자와 클라이언트 측 내보내기 타이머를 비교하면 검증할 수 없는 결론이 나옵니다.

경로가 책임 있는 것처럼 보이면, 전송이 실행되는 동안 네트워크 담당자에게 그 특정 흐름의 손실, 재전송, 달성 처리량을 지켜보게 하세요. 일반 속도 테스트는 다른 경로, 엔드포인트 또는 동시성 패턴을 사용할 수 있습니다. 작은 성공 요청은 지속적인 결과 전송에 대해 거의 말해 주지 않습니다.

경로를 탓하기 전에 바이트를 줄이세요

필터링, 집계, 필요한 열만 선택하는 것은 전송량과 각 행에 대해 클라이언트가 하는 일을 모두 줄입니다. 의도한 결과를 보존하세요. 보고서에는 화면 요약에 없는 세부 정보가 필요할 수 있습니다.

반복 가능한 내보내기의 경우 데이터베이스에 가까운 승인된 실행 위치가 정의된 출력을 작성하고 이를 한 번 전달할 수 있습니다. 이는 워크플로와 접근 제어를 바꾸는 것이며, 공유 호스트에 무제한 덤프를 남길 수 있는 권한은 아닙니다.

압축은 기본 수리가 아닙니다. 지원과 보안은 실제 프로토콜과 배포에 달려 있으며, 클라이언트가 느리게 해제하는 압축 스트림은 경험을 더 나쁘게 만들 수 있습니다. 먼저 단계를 측정한 다음 그 단계에 지원되는 변경을 선택하세요.