Вялікі вынік 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';

Чытайце лічыльнік, пакуль выконваецца абмежаваная нагрузка, а не пасля пустой гадзіны, бо назапашаныя лічыльнікі змешваюць кожную сесію з моманту запуску асобніка. Параўноўвайце дэльту за прагон, а не агульны паказчык за ўвесь час. Дэльта, якая расце падчас перадачы, звужае пытанне да спажывання або дастаўкі.

Пастаўце абодва кліенты на адзін гадзіннік

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

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

Скараціце байты, перш чым вінаваціць шлях

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

Для паўтаральных экспартаў зацверджанае месца выканання побач з базай даных можа запісаць вызначаны вынік, які потым дастаўляецца адзін раз. Гэта змяняе працоўны працэс і яго кантроль доступу, і гэта не дазвол пакідаць неабмежаваны дамп на агульным хосце.

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