Чаму SQL-дадатак з мноствам запытаў паўзе праз VPN і што варта аб'ядноўваць у пакеты

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

Сімптом — гэта экран, а не запыт

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

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

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

Падлічыце паслядоўныя чаканні ў адным дзеянні карыстальніка

Вымярайце ў кліенце, а не здагадвайцеся. У psql \timing on друкуе прайшоўшы час кожнага выраза, а EXPLAIN (ANALYZE, BUFFERS) паказвае, колькі з гэтага часу сервер сапраўды выдаткаваў на працу.

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

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

Аб'ядноўвайце незалежныя выклікі, пакідайце залежныя

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

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

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

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

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

У ADO.NET закрыццё або вызваленне пулаванага злучэння вяртае яго для паўторнага выкарыстання замест адкрыцця новага фізічнага, таму шаблон, які выглядае як уцечка, часцей за ўсё правільны. Праверце, што пул сапраўды выкарыстоўваецца, а не мяркуйце: лагуйце стварэнне фізічных злучэнняў або назірайце за колькасцю сесій на серверы, пакуль працуе экран. Рэкамендацыі па прадукцыйнасці SQL кажуць тое ж пра скарачэнне кругоў і пакетаванне частых ad hoc выклікаў, з прыкладамі для канкрэтнай службы, якія варта праектаваць на вашае разгортванне.

Пулаванне здымае выдаткі на наладку і пакідае паслядоўныя чаканні запытаў нязменнымі. Гэта перадумова для чыстага замеру, а не самастойнае выпраўленне.

Узважце перанос выканання бліжэй да даных

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

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

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