Skip to content
Բոլոր հոդվածները
Ստանդարտներ և մեթոդիկա

Ինչպես ենք փորձարկում վեբ պորտալները բեռի տակ. սցենարներ և p99

Alexander Zemskov 4 րոպե ընթերցում
Ինչպես ենք փորձարկում վեբ պորտալները բեռի տակ. սցենարներ և p99

Պորտալի բեռնվածության թեստը հաճախ հանգում է մեկ URL-ի և մեկ թվի. գլխավոր էջը պատասխանում է, ասենք, վայրկյանում 8000 հարցման, ուրեմն կայքը պատրաստ է։ Հետո ժամը 9:00-ին մի քանի հազար մարդ միաժամանակ մուտք է գործում, որոնում և ձևեր ուղարկում, և մուտքի ծառայությանը տվյալների բազայի միացումները չեն հերիքում։ Գլխավոր էջն այդ ամբողջ ընթացքում տրվում էր քեշից։ Մենք պորտալը բեռնում ենք այնպես, ինչպես դրա հետ աշխատում են օգտատերերը, և փնտրում ենք այն շերտը, որն առաջինն է տեղի տալիս։

Ստենդը

Պորտալը մնում է այնտեղ, որտեղ աշխատում է՝ Ձեր ամպային tenant-ում, Ձեր տվյալների կենտրոնում կամ որպես staging պատճեն ստենդի հիպերվիզորի վրա։ Բեռը տալիս են ստենդի L4-7 շարժիչները՝ կոմերցիոն գեներատորները և այն գեներատորը, որը մենք ինքներս ենք կառուցում, իրական ամպային միացման կամ առանձնացված կապուղու միջոցով։ Յուրաքանչյուր էմուլյացված օգտատեր ունի իր թեստային հաշիվը, աղբյուրի հասցեն և TLS սեսիան, ուստի քեշերը, սեսիաների կցումը և rate limit-ն իրենց պահում են այնպես, ինչպես իրական մարդկանց դեպքում։ Պորտալները դրանց առջևի ենթակառուցվածքի հետ միասին ամպի և NFV-ի էջի դասերից մեկն են։

Սցենարները վերցնում ենք Ձեր լոգերից՝ մուտք, որոնում, անձնական էջ, ձև, բջջային հավելվածի API կանչեր, սեղմումների միջև իրական դադարներով և խառնուրդում յուրաքանչյուրի իր բաժնով։ Ընթացքի ժամանակ գրանցում ենք յուրաքանչյուր շերտի հաշվիչները՝ բալանսավորիչ, WAF, հավելված, տվյալների բազա և CDN, եթե այն կա ճանապարհին։

Ինչ ենք ստուգում

  • Ramp-up. 1000-ից 200 000 միաժամանակյա օգտատեր աստիճաններով, պահում յուրաքանչյուրում և այն աստիճանը, որտեղ պորտալը դուրս է գալիս համաձայնեցված շեմից
  • Հարցումներ վայրկյանում մինչև առաջին սխալը. HTTP 5xx, timeout-ներ, մերժված միացումներ, հետո սխալների բաժինը յուրաքանչյուր աստիճանում
  • Պատասխանի ժամանակն ըստ գործարքների. p50, p95 և p99 մուտքի, որոնման, ձևի և յուրաքանչյուր API կանչի համար
  • Բովանդակության ստուգում. 200 կոդը, որի ներսում սխալի էջ է, համարվում է ձախողում
  • TLS. handshake-ներ վայրկյանում այնտեղ, որտեղ TLS-ն ավարտվում է (բալանսավորիչ, WAF կամ հավելված), առավոտյան հոսքի ժամանակ
  • Առաջինը հագեցող շերտը. միացումները բալանսավորիչում, WAF-ի ուշացումը կանոնների ամբողջական հավաքածուով, հավելվածի pool-երը, հարցումներն ու արգելափակումները բազայում
  • Soak. 2-ից 24 ժամ կայուն բեռի տակ, վերջին ժամն առաջինի դեմ
  • Ամպ և on-prem. որքան է տևում ավտոմասշտաբավորումը և ինչ է կատարվում p99-ի հետ այդ ընթացքում, նույն սցենարները երկու հարթակներում, ընթացքի ամպային հաշիվը

Անցման չափանիշները համաձայնեցնում ենք մինչև ընթացքը։ Ramp-ը և soak-ը կատարվում են մեր բեռնվածության թեստերի մեթոդիկայով, իսկ WAF-ը կամ բալանսավորիչը կարելի է առանձին չափել որպես սարքերի դաս։

Ինչն է սովորաբար խափանվում

Ամենից հաճախ՝ տվյալների բազան։ Օրինակ կլոր թվերով. հավելվածը մասշտաբավորվում է 4-ից 12 օրինակի, յուրաքանչյուրն ունի 50 միացման pool, իսկ բազան ընդունում է 300։ Մոտ 6000 օգտատիրոջ դեպքում նոր օրինակները սպասում են միացումների, մուտքի p99-ը 0,8 վայրկյանից աճում է մինչև 9, իսկ վեբ շերտի CPU-ն մնում է կանաչ։ Նոր օրինակները միայն ավելի շատ միացումներ են խնդրում։

Երկրորդ դեպք. ավտոմասշտաբավորում, որն ուշ է արձագանքում։ Նոր օրինակը գալիս է CPU-ի 70%-ից բարձր 5 րոպեից հետո և ևս 3 րոպե տաքանում է, իսկ առավոտյան հոսքը տևում է 10 րոպե։ Այդ 10 րոպեից 8-ը պորտալն աշխատում է այն հզորությամբ, որն ուներ ժամը 8:59-ին։

Երրորդ դեպք. պորտալի առջևի ճանապարհը։ Սեսիաների կցումն ըստ աղբյուրի հասցեի մեկ NAT-ի հետևում գտնվող ամբողջ գրասենյակն ուղարկում է մեկ սերվերի։ WAF-ն ավելացնում է 40 մվ p99-ում (օրինակ) և CPU-ի սահմանին հասնում է հավելվածից շուտ։ TLS-ն ավարտվում է էջերի դիտումների համար հաշվարկված բալանսավորիչում, և առավոտյան մուտքը վերածվում է handshake-ների փոթորկի։ Մեկ URL-ի վրա բեռ տվող 3 մեքենան սրանցից ոչինչ ցույց չի տա։

Ինչ կա հաշվետվության մեջ

Աղյուսակ բեռի յուրաքանչյուր աստիճանի համար՝ օգտատերեր, հարցումներ վայրկյանում, p50, p95 և p99 ըստ գործարքների, սխալներն ըստ տեսակի։ Առաջինը հագեցած շերտը՝ դրա հաշվիչներով այդ պահին։ TLS-ի թվերը, soak-ի կորը, ավտոմասշտաբավորման ժամանակագրությունը և ամպային ընթացքի արժեքը։ Սցենարները և գեներատորի կարգավորումները հաշվետվության մեջ են, ուստի ուղղումից հետո ընթացքը կրկնում է նույն թեստը։

Որտեղից սկսել

Ուղարկեք մեզ պորտալի հասցեն, այն 3-5 սցենարը, որոնցից կախված է Ձեր բիզնեսը, և պիկային ժամի սպասվող բեռը։ Մենք պատասխանում ենք պլանի նախագծով՝ սցենարները, բեռի աստիճանները, ինչպես ենք հավաքում ստենդը և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ մշակողին կամ հոսթինգ պրովայդերին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։

Հեղինակ

Alexander Zemskov

Ցանցերի և անվտանգության թեստավորման փորձագետ և վաճառք (19+ տարի) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel և այլն

Բլոգ

Կարդացեք նաև

Պահոցներ և տվյալների կենտրոններ

Ինչպես ենք փորձարկում պահեստավորման ցանցերը. incast, PFC և p99

NVMe/TCP պահեստավորման զանգվածի բնութագրում գրված է 11 GB/s։ Թիվը չափվել է ուղիղ մալուխով, բլոկի մեկ չափով և դատարկ պորտով։ Արտադրական ցանցում զանգվածը կանգնած է ToR զույ…

Alexander Zemskov 4 րոպե ընթերցում