Защо SQL приложение с много заявки пълзи през VPN и какво да се групира

Формуляр, който в локална мрежа се показва за под секунда, през VPN отнема пет секунди, докато копирането на файл по същата връзка върви с пълна скорост. Разликата не е в честотната лента. Формулярът чака поредица от отговори и плаща пълния обмен на всяка стъпка, докато копирането на файл държи байтовете в движение непрекъснато. Пребройте тези изчаквания, преди да пипате линията за достъп.

Симптомът е екран, а не заявка

Всяка заявка на този екран може да е бърза, а екранът пак да е бавен, защото общото е сумата от изчакванията, а не сумата от времената за изпълнение. Израз, който се изпълнява за две милисекунди, пак струва цял обмен, когато клиентът трябва да получи резултата, преди да изпрати следващия. По път с четиридесет милисекунди закъснение сто зависими извиквания се натрупват до около четири секунди, преди да започне каквато и да е работа по изчертаването. Тази аритметика е модел на изчакването, а не измерване на вашата връзка.

Затова тестът за скорост изглежда невинен. Големият трансфер измерва пропускателната способност, приказливият формуляр измерва закъснението, а VPN може да е отличен в едното и обикновен в другото. Затова диагностицирането на екрана означава измерване на екрана, а не на връзката.

Запишете времето от край до край за едно потребителско действие, преди да променяте каквото и да е. Това число е единствената базова линия, която може да ви каже дали по-късна поправка е проработила.

Пребройте последователните изчаквания в едно потребителско действие

Измервайте в клиента, вместо да гадаете. В psql \timing on отпечатва изминалото време на всеки израз, а EXPLAIN (ANALYZE, BUFFERS) показва колко от това време сървърът наистина е изразходвал за работата.

Разликата между тези две числа е вашата мрежова и клиентска добавка. Ако израз се изпълни за две милисекунди, а клиентът отчете шестдесет, останалите петдесет и осем са пътуване и локална обработка и никакъв индекс няма да ги махне. Повторете това сравнение за всеки израз, който екранът изпраща, и съберете разликите, а не времената за изпълнение.

Запишете резултата като брой последователни изчаквания. Това е величината, която следващите два раздела могат да намалят, и число, за което можете да спорите с доказателства.

Групирайте независимите извиквания, запазете зависимите

Два израза, които не четат резултатите един на друг, могат да пътуват заедно и да бъдат събрани веднъж, което превръща две изчаквания в едно. Два израза, където вторият се нуждае от стойността на първия, не могат, защото зависимостта е реална и групирането ще промени какво прави програмата. Разделете извикванията в тези две купчини, преди да пренаписвате каквото и да е, и размерът на всяка купчина ви казва какво е възможно.

Работата на базата на множества премахва изчакванията по-задълбочено от групирането. Една заявка, която връща редовете, които цикъл е събирал един по един, елиминира цикъла, както и обмените. Търсете първо цикъла, защото той обикновено е по-голямата печалба и по-леката промяна за преглед.

Групата все още трябва да запази обработката на грешки и границите на транзакциите. Слепването на несвързани изрази в един низ не е безопасна оптимизация, а група, която скрива неуспешен израз зад успешно подаване, е по-лоша от спестените изчаквания.

Използвайте връзките повторно, преди да купувате честотна лента

Новата връзка струва разделяне на имена, TCP ръкостискане, TLS договаряне и удостоверяване, а по път с голямо закъснение всяко от тях е още един обмен, преди да стартира първата заявка. Пулът от връзки съществува, за да се плати този разход веднъж на процес, а не веднъж на извикване.

В ADO.NET затварянето или освобождаването на пулирана връзка я връща за повторна употреба, вместо да отваря нова физическа, затова моделът, който изглежда като изтичане, често е правилната употреба. Проверете дали пулът наистина се използва, вместо да предполагате: водете журнал за създаването на физически връзки или наблюдавайте броя на сесиите на сървъра, докато екранът работи. Насоките за производителност на SQL казват същото за намаляване на обмените и групиране на честите ad hoc извиквания, с примери за конкретната услуга, които трябва да нанесете върху своето внедряване.

Пулирането премахва разхода за установяване и оставя последователните изчаквания на заявките непокътнати. То е предпоставка за чисто измерване, а не самостоятелна поправка.

Претеглете преместването на изпълнението по-близо до данните

Стартирането на приложението близо до базата данни заменя много отдалечени обмени с базата с една отдалечена сесия за показване. За приказливо натоварване това може да е голяма промяна и е оперативна промяна в същата степен, в която е промяна на производителността: управлението на сесиите, контролът на достъпа, разгръщането на софтуера и потребителското изживяване се местят заедно с приложението.

Измерете действителния интерфейс и данните, които той прехвърля, преди да предполагате, че някоя посока е по-бърза. Отдалечената сесия за работен плот мести пиксели, а екран с плътна графика може да се представя по-зле по същия път от заявките, които е заменил, особено когато клиентът пречертава непрекъснато.

След това повторете първоначалното действие и сравнете три числа: последователни изчаквания, обем на резултата и време за завършване от край до край. Подобрение, което променя измерваната потребителска задача, като същевременно запазва коректността на данните и политиката за достъп, е това, което си струва да се запази.