말 많은 SQL 앱이 VPN에서 느려지는 이유와 묶어야 할 것

근거리 통신망에서 일 초 안에 뜨는 폼이 VPN을 거치면 오 초가 걸리는데, 같은 회선에서 파일 복사는 최고 속도로 돈다. 차이는 대역폭이 아니다. 폼은 일련의 응답을 기다리며 매 단계마다 왕복 비용을 전부 치르고, 파일 복사는 바이트를 끊임없이 계속 흘려보낸다. 접속 회선을 건드리기 전에 그 대기 횟수를 세라.

증상은 질의가 아니라 화면이다

그 화면의 모든 질의가 빨라도 화면은 여전히 느릴 수 있다. 전체 시간은 실행 시간의 합이 아니라 대기의 합이기 때문이다. 이 밀리초에 끝나는 문장도 클라이언트가 다음 문장을 보내기 전에 결과를 받아야 한다면 왕복 한 번을 온전히 치른다. 지연이 사십 밀리초인 경로에서 종속 호출 백 개는 렌더링 작업이 시작되기도 전에 약 사 초를 쌓는다. 이 산수는 대기의 모델이지 당신 회선의 벤치마크가 아니다.

그래서 속도 테스트는 죄가 없어 보인다. 대량 전송은 처리량을 재고, 말 많은 폼은 지연을 재며, VPN은 한쪽에서 탁월하면서 다른 쪽에서는 평범할 수 있다. 따라서 화면을 진단한다는 것은 회선이 아니라 화면을 재는 일이다.

무엇이든 바꾸기 전에 사용자 행동 하나의 종단 간 시간을 기록하라. 나중 수정이 효과가 있었는지 말해 줄 수 있는 유일한 기준선이 그 숫자다.

사용자 행동 하나에서 순차 대기를 세라

추측 대신 클라이언트에 계측을 넣어라. psql에서 \timing on는 각 문장의 경과 시간을 출력하고, EXPLAIN (ANALYZE, BUFFERS)는 그 시간 중 서버가 실제 작업에 쓴 몫을 보여 준다.

두 숫자의 차이가 네트워크와 클라이언트 부담이다. 문장이 이 밀리초에 실행되는데 클라이언트가 육십을 기록했다면, 남은 오십팔은 이동과 로컬 처리이며 어떤 인덱스도 그것을 없애지 못한다. 화면이 보내는 모든 문장에 대해 이 비교를 반복하고, 실행 시간이 아니라 차이를 더하라.

결과를 순차 대기 횟수로 적어 두라. 다음 두 절이 줄일 수 있는 양이 바로 그것이고, 증거를 가지고 따질 수 있는 숫자다.

독립 호출은 묶고 종속 호출은 남겨라

서로의 결과를 읽지 않는 두 문장은 함께 이동해 한 번에 수집될 수 있고, 그러면 대기 두 번이 한 번이 된다. 두 번째가 첫 번째의 값을 필요로 하는 두 문장은 그럴 수 없다. 의존이 실제이고 묶으면 프로그램의 동작이 달라지기 때문이다. 무엇이든 다시 쓰기 전에 호출을 그 두 더미로 나눠라. 각 더미의 크기가 무엇이 가능한지 알려 준다.

집합 기반 작업은 묶기보다 대기를 더 철저히 없앤다. 루프가 하나씩 가져오던 행을 한 번에 돌려주는 질의 하나는 루프와 왕복을 함께 없앤다. 먼저 루프를 찾아라. 보통 더 큰 이득이고 검토하기 쉬운 변경이다.

묶음은 여전히 오류 처리와 트랜잭션 경계를 보존해야 한다. 무관한 문장을 한 문자열로 이어 붙이는 것은 안전한 최적화가 아니며, 실패한 문장을 성공한 제출 뒤에 숨기는 묶음은 아낀 대기보다 나쁘다.

대역폭을 사기 전에 연결을 재사용하라

새 연결은 이름 해석, TCP 핸드셰이크, TLS 협상, 인증을 치른다. 지연이 큰 경로에서는 그 하나하나가 첫 질의가 돌기 전의 또 다른 왕복이다. 연결 풀은 그 비용을 호출마다가 아니라 프로세스마다 한 번 치르기 위해 존재한다.

ADO.NET에서 풀에 있는 연결을 닫거나 dispose하면 새 물리 연결을 여는 대신 재사용을 위해 반납된다. 그래서 누수처럼 보이는 패턴이 흔히 올바른 사용법이다. 풀이 실제로 쓰이고 있는지 가정하지 말고 확인하라. 물리 연결 생성에 로그를 남기거나, 화면이 도는 동안 서버의 세션 수를 지켜보라. SQL 성능 지침도 왕복을 줄이고 잦은 임시 호출을 묶는 같은 요점을 말하며, 서비스별 예시를 당신의 배포에 맞춰 대응시켜야 한다.

풀링은 설정 비용을 없애지만 순차 질의 대기는 그대로 둔다. 그 자체로 고치는 것이 아니라 깨끗한 측정을 위한 전제다.

실행을 데이터 가까이 옮기는 방안을 저울질하라

애플리케이션을 데이터베이스 가까이에서 실행하면 많은 원격 데이터베이스 교환이 하나의 원격 디스플레이 세션으로 바뀐다. 말 많은 작업 부하에는 큰 변화일 수 있고, 성능 변화이자 운영 변화다. 세션 관리, 접근 제어, 소프트웨어 배포, 사용자 경험이 모두 애플리케이션과 함께 움직인다.

어느 방향이 더 빠르다고 가정하기 전에 실제 인터페이스와 그것이 전송하는 데이터를 재라. 원격 데스크톱 세션은 픽셀을 옮기며, 그래픽이 빽빽한 화면은 같은 경로에서 그것이 대체한 질의보다 더 나쁠 수 있다. 특히 클라이언트가 계속 다시 그릴 때 그렇다.

그런 다음 원래 행동을 반복하고 세 숫자를 비교하라. 순차 대기, 결과량, 종단 간 완료 시간이다. 데이터 정확성과 접근 정책을 지키면서 측정된 사용자 작업을 개선하는 변경이 남길 가치가 있다.