Ինչու շատ հարցումներով SQL ծրագիրը դանդաղում է VPN-ով և ինչ խմբավորել

Ձևը, որը տեղական ցանցում երևում է մեկ վայրկյանից պակաս ժամանակում, VPN-ով տևում է հինգ վայրկյան, մինչդեռ նույն գծով ֆայլի պատճենումն ընթանում է լրիվ արագությամբ։ Տարբերությունը թողունակության մեջ չէ։ Ձևը սպասում է պատասխանների հաջորդականությանը և յուրաքանչյուր քայլում վճարում է ամբողջ շրջանը, մինչդեռ ֆայլի պատճենումը բայթերը պահում է անընդհատ ճանապարհին։ Հաշվեք այդ սպասումները նախքան մուտքի գծին դիպչելը։

Ախտանիշը էկրանն է, ոչ հարցումը

Այդ էկրանի յուրաքանչյուր հարցում կարող է արագ լինել, և էկրանը դեռ կարող է դանդաղ լինել, որովհետև գումարը սպասումների գումարն է, ոչ կատարման ժամանակների գումարը։ Երկու միլիվայրկյանում կատարվող հայտարարությունը դեռ արժե ամբողջ շրջան, երբ հաճախորդը պետք է ստանա դրա արդյունքը նախքան հաջորդը ուղարկելը։ Քառասուն միլիվայրկյան ուշացումով ուղու վրա հարյուր կախյալ կանչեր կուտակվում են մոտ չորս վայրկյանի մեջ նախքան որևէ գծագրման աշխատանք սկսվելը։ Այս թվաբանությունը սպասման մոդելն է, ոչ ձեր գծի չափումը։

Այդ պատճառով արագության թեստը անմեղ է թվում։ Զանգվածային փոխանցումը չափում է թողունակությունը, շատախոս ձևը՝ ուշացումը, և VPN-ը կարող է գերազանց լինել մեկում և սովորական՝ մյուսում։ Ուստի էկրանը ախտորոշելը նշանակում է չափել էկրանը, ոչ գիծը։

Գրանցեք մեկ օգտվողի գործողության սկզբից մինչև վերջ ժամանակը նախքան որևէ բան փոխելը։ Այդ թիվը միակ հիմքն է, որը կարող է ասել՝ արդյոք ավելի ուշ արված ուղղումը աշխատեց։

Հաշվեք հաջորդական սպասումները մեկ օգտվողի գործողության մեջ

Չափեք հաճախորդում՝ գուշակելու փոխարեն։ psql-ում \timing on տպում է յուրաքանչյուր հայտարարության անցած ժամանակը, և EXPLAIN (ANALYZE, BUFFERS) ցույց է տալիս, թե այդ ժամանակից որքանն է սերվերը իրականում ծախսել աշխատանքի վրա։

Այս երկու թվերի տարբերությունը ձեր ցանցային և հաճախորդային ծախսն է։ Եթե հայտարարությունը կատարվում է երկու միլիվայրկյանում, իսկ հաճախորդը գրանցում է վաթսուն, ապա մնացած հիսունութը ճանապարհ և տեղական մշակում են, և ոչ մի ինդեքս դրանք չի հեռացնի։ Կրկնեք այս համեմատությունը էկրանի թողարկած յուրաքանչյուր հայտարարության համար և գումարեք տարբերությունները, ոչ կատարման ժամանակները։

Գրառեք արդյունքը որպես հաջորդական սպասումների քանակ։ Դա այն մեծությունն է, որը հաջորդ երկու բաժինները կարող են նվազեցնել, և դա թիվ է, որի շուրջ կարող եք վիճել ապացույցներով։

Խմբավորեք անկախ կանչերը, պահեք կախյալները

Երկու հայտարարություն, որոնք չեն կարդում միմյանց արդյունքները, կարող են միասին ճամփորդել և մեկ անգամ հավաքվել, ինչը երկու սպասումը դարձնում է մեկ։ Երկու հայտարարություն, որտեղ երկրորդին պետք է առաջինի արժեքը, չեն կարող, որովհետև կախվածությունն իրական է, և խմբավորումը կփոխի, թե ինչ է անում ծրագիրը։ Նախքան որևէ բան վերաշարադրելը բաժանեք կանչերը այս երկու կույտերի, և յուրաքանչյուր կույտի չափը ձեզ ասում է, թե ինչ հնարավոր է։

Բազմությունների վրա հիմնված աշխատանքը սպասումները հեռացնում է ավելի հիմնավոր, քան խմբավորումը։ Մեկ հարցում, որը վերադարձնում է այն տողերը, որոնք ցիկլը բերում էր մեկ առ մեկ, վերացնում է և՛ ցիկլը, և՛ շրջանները։ Նախ փնտրեք ցիկլը, որովհետև սովորաբար դա է ավելի մեծ շահը և վերանայման համար ավելի հեշտ փոփոխությունը։

Խումբը դեռ պետք է պահպանի սխալների մշակումը և գործարքների սահմանները։ Անկապ հայտարարությունները մեկ տողի մեջ միացնելը անվտանգ օպտիմալացում չէ, և այն խումբը, որը թաքցնում է ձախողված հայտարարությունը հաջող ներկայացման հետևում, ավելի վատն է, քան խնայված սպասումները։

Կրկին օգտագործեք միացումները նախքան թողունակություն գնելը

Նոր միացումը արժե անվան լուծում, TCP ձեռքսեղմում, TLS բանակցություն և նույնականացում, և բարձր ուշացումով ուղու վրա դրանցից յուրաքանչյուրը ևս մեկ շրջան է նախքան առաջին հարցման կատարումը։ Միացումների լողավազանները գոյություն ունեն, որպեսզի այդ ծախսը վճարվի մեկ անգամ յուրաքանչյուր գործընթացի համար, ոչ մեկ անգամ յուրաքանչյուր կանչի։

ADO.NET-ում լողավազանային միացումը փակելը կամ վերացնելը վերադարձնում է այն կրկին օգտագործման՝ նոր ֆիզիկական միացում բացելու փոխարեն, ուստի արտահոսքի նմանվող օրինաչափությունը հաճախ ճիշտ օգտագործումն է։ Ստուգեք, որ լողավազանը իսկապես օգտագործվում է՝ ենթադրելու փոխարեն. գրանցեք ֆիզիկական միացումների ստեղծումը կամ հետևեք սերվերի սեսիաների քանակին, մինչ էկրանը աշխատում է։ SQL-ի արդյունավետության ուղեցույցը նույնն է ասում շրջանների կրճատման և հաճախակի ad hoc կանչերի խմբավորման մասին՝ ծառայությանը հատուկ օրինակներով, որոնք պետք է կիրառեք ձեր սեփական տեղակայման վրա։

Լողավազանացումը հեռացնում է կարգաբերման ծախսը և անձեռնմխելի է թողնում հաջորդական հարցումների սպասումները։ Այն մաքուր չափման նախապայման է, ոչ ինքնուրույն ուղղում։

Կշռեք կատարմանը տվյալներին ավելի մոտ տեղափոխելը

Ծրագիրը տվյալների բազայի մոտ գործարկելը շատ հեռավոր փոխանակումներ փոխարինում է մեկ հեռավոր ցուցադրման սեսիայով։ Շատախոս ծանրաբեռնվածության համար դա կարող է մեծ փոփոխություն լինել, և դա գործառնական փոփոխություն է այնքան, որքան արդյունավետության փոփոխություն. սեսիաների կառավարումը, մուտքի վերահսկումը, ծրագրային ապահովման տեղակայումը և օգտվողի փորձը բոլորը շարժվում են ծրագրի հետ։

Չափեք իրական ինտերֆեյսը և այն տվյալները, որոնք այն փոխանցում է, նախքան ենթադրելը, որ որևէ ուղղություն ավելի արագ է։ Հեռավոր աշխատասեղանի սեսիան տեղափոխում է պիքսելներ, և խիտ գրաֆիկայով էկրանը նույն ուղու վրա կարող է ավելի վատ աշխատել, քան այն հարցումները, որոնց այն փոխարինել է, հատկապես երբ հաճախորդը անընդհատ վերագծում է։

Ապա կրկնեք սկզբնական գործողությունը և համեմատեք երեք թիվ՝ հաջորդական սպասումներ, արդյունքի ծավալ և սկզբից մինչև վերջ ավարտի ժամանակ։ Այն բարելավումը, որը փոխում է չափվող օգտվողի խնդիրը՝ պահպանելով տվյալների ճշգրտությունը և մուտքի քաղաքականությունը, արժե պահել։