Load testing k6-ով

01Performance թեստերի տեսակները

«Load test» արտահայտությունն օգտագործվում է ազատ, բայց յուրաքանչյուր տեսակ պատասխանում է տարբեր հարցի։ Smoke test-ը աշխատեցնում է փոքրիկ բեռ՝ ստուգելու, որ script-ը և համակարգն աշխատում են։ Average-load test-ը մոդելավորում է սովորական տրաֆիկ՝ հաստատելու, որ թիրախներին համապատասխանում եք։ Stress test-ը բեռը տանում է սովորականից այն կողմ՝ տեսնելու, թե ինչպես է համակարգը վատթարանում։ Spike test-ը կտրուկ թռիչք է անում, ինչպես push notification-ից հետո։ Soak (endurance) test-ը սովորական բեռը պահում է ժամերով՝ memory leak-եր և ռեսուրսների դանդաղ սպառում գտնելու համար։ Breakpoint test-ը բեռը մեծացնում է, մինչև ինչ-որ բան կոտրվի, որպեսզի գտնի իրական capacity-ն։ Սկսեք smoke-ից և average load-ից․ մյուսներն ավելացրեք, երբ իմանաք ձեր baseline-ը։

• Throughput՝ վայրկյանում համակարգի ավարտած հարցումների կամ iteration-ների քանակը։
• Latency percentile-ներ՝ p95-ը նշանակում է, որ հարցումների 95%-ն ավելի արագ էր, քան այս արժեքը։
• Error rate՝ ձախողված հարցումների բաժինը, որը հաճախ առաջինն է կոտրվում։

02Ձեր առաջին k6 script-ը

k6 script-ը ES module է։ options export-ը նկարագրում է բեռը և pass/fail կանոնները․ default ֆունկցիան այն է, ինչ յուրաքանչյուր virtual user (VU) աշխատեցնում է ցիկլով։ VU-ն մոդելավորված օգտատեր է, որը ձեր ֆունկցիան աշխատեցնում է մյուսների հետ զուգահեռ։ check()-ը ստուգում է պատասխանները՝ առանց թեստը կանգնեցնելու․ threshold-ները մետրիկաները վերածում են pass կամ fail արդյունքի, և երբ threshold-ը ձախողվում է, k6-ը դուրս է գալիս ոչ զրոյական կոդով, ինչը և կոտրում է CI build-ը։ sleep()-ը ավելացնում է think time, որպեսզի VU-ն վարվի իրական մարդու պես, ոչ թե խիտ ցիկլի։ k6-ը TypeScript ֆայլերն աշխատեցնում է ուղղակիորեն, ուստի մեծ suite-երում կարող եք տիպեր օգտագործել։

1import http from "k6/http";
2import { check, sleep } from "k6";
3 
4export const options = {
5  vus: 20,
6  duration: "2m",
7  thresholds: {
8    http_req_failed: ["rate<0.01"],                  // under 1% errors
9    http_req_duration: ["p(95)<400", "p(99)<1000"],  // ms
10  },
11};
12 
13export default function () {
14  const res = http.get("https://staging.example.com/api/products?page=1");
15  check(res, { "status is 200": (r) => r.status === 200 });
16  sleep(1);
17}

03Scenario-ներ և executor-ներ՝ open ընդդեմ closed մոդելների

Scenario-ները թույլ են տալիս ճշգրիտ ձևավորել բեռը և միաժամանակ աշխատեցնել մի քանի pattern։ Executor-ներն են որոշում՝ ինչպես։ Closed-model executor-ները (constant-vus, ramping-vus) զբաղված են պահում որոշակի քանակով VU-ներ․ եթե համակարգը դանդաղում է, յուրաքանչյուր VU ավելի քիչ հարցում է անում, ինչը թաքցնում է խնդիրը։ Open-model executor-ները (constant-arrival-rate, ramping-arrival-rate) նոր iteration-ներ են սկսում ֆիքսված տեմպով՝ անկախ պատասխանի ժամանակից, ինչը համապատասխանում է իրական ինտերնետային տրաֆիկին․ օգտատերերը շարունակում են գալ, նույնիսկ երբ ձեր կայքը դանդաղ է։ API-ի capacity թեստերի համար նախընտրեք arrival-rate executor-ներ և տվեք նրանց բավարար preAllocatedVUs և maxVUs՝ տեմպը պահելու համար։

1export const options = {
2  scenarios: {
3    browse: {
4      executor: "ramping-arrival-rate",
5      startRate: 10, timeUnit: "1s",
6      preAllocatedVUs: 50, maxVUs: 300,
7      stages: [
8        { target: 100, duration: "3m" }, // ramp to 100 requests/s
9        { target: 100, duration: "10m" }, // hold
10        { target: 0, duration: "2m" },   // ramp down
11      ],
12    },
13  },
14  thresholds: { "http_req_duration{scenario:browse}": ["p(95)<500"] },
15};

04Իրատեսական օգտատիրոջ ճանապարհներ

Իրական օգտատերերը մուտք են գործում, դիտում, որոնում և checkout անում՝ քայլերի միջև դադարներով։ Մոդելավորեք հիմնական ճանապարհները analytics-ից վերցված իրական համամասնություններով (օրինակ՝ 80% դիտում, 15% որոնում, 5% checkout)։ Օգտագործեք group()՝ քայլերն անվանելու համար, tag-եր՝ մետրիկաները բաժանելու համար, և SharedArray՝ թեստային տվյալները մեկ անգամ բեռնելու և VU-ների միջև առանց memory պատճենելու կիսելու համար։ Որտեղ գրառումներ են լինում, ստեղծեք եզակի տվյալներ յուրաքանչյուր VU-ի և iteration-ի համար, որպեսզի չխփեք նույն տողին և արհեստական lock contention չստեղծեք։ Նախապատրաստումը (թեստային account-ի ստեղծում, token-ի ստացում) արեք setup()-ում, որը մեկ անգամ է աշխատում, և արդյունքը փոխանցեք VU-ներին։

1import http from "k6/http";
2import { group, check } from "k6";
3import { SharedArray } from "k6/data";
4 
5const products = new SharedArray("products", () => JSON.parse(open("./products.json")));
6const BASE = __ENV.BASE_URL || "https://staging.example.com";
7 
8export function setup() {
9  const res = http.post(BASE + "/api/login", JSON.stringify({ email: "[email protected]", password: __ENV.TEST_PASSWORD }),
10    { headers: { "Content-Type": "application/json" } });
11  return { token: res.json("token") };
12}
13 
14export default function (data) {
15  const params = { headers: { Authorization: "Bearer " + data.token } };
16  group("product page", () => {
17    const p = products[Math.floor(Math.random() * products.length)];
18    check(http.get(BASE + "/api/products/" + p.slug, params), { "200": (r) => r.status === 200 });
19  });
20}

05Աշխատեցում, արդյունքների ընթերցում և CI

Աշխատեցրեք k6 run script.js տեղում կամ container-ում։ Վերջում k6-ը տպում է ամփոփում․ հարցումների տեմպ, latency percentile-ներ, error rate, փոխանցված տվյալներ և արդյոք յուրաքանչյուր threshold անցել է։ Նայեք p95-ին և p99-ին, ոչ թե միջիններին, քանի որ միջինները թաքցնում են դանդաղ պոչը, որը օգտատերերը նկատում են։ Տենդենցների և սերվերային մետրիկաների հետ համադրման համար արդյունքները stream արեք Prometheus (remote write) կամ Grafana Cloud k6 և դիտեք դրանք CPU-ի, database-ի և հերթերի dashboard-ների կողքին։ CI-ում յուրաքանչյուր release-ի ժամանակ staging-ի դեմ աշխատեցրեք կարճ smoke կամ average-load test, իսկ ավելի երկար stress և soak թեստերը պահեք ժամանակացույցով։ Երբեք load test մի արեք production-ը կամ third-party API առանց հստակ թույլտվության և պլանի։

1# Local run with an environment variable
2k6 run -e BASE_URL=https://staging.example.com script.js
3 
4# Docker, no local install
5docker run --rm -i grafana/k6 run - <script.js
6 
7# Stream metrics to Prometheus remote write
8K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
9  k6 run -o experimental-prometheus-rw script.js

06Little-ի օրենքը և թեստի չափավորումը

Little-ի օրենքը կապում է երեք թիվ․ concurrency = throughput × համակարգում անցկացրած ժամանակ։ Եթե ձեզ պետք է 200 հարցում վայրկյանում, և հարցումը տևում է 0.25 վայրկյան, համակարգում միաժամանակ ընթացքի մեջ է մոտ 50 հարցում։ k6 arrival-rate թեստերի համար անհրաժեշտ VU-ները ≈ տեմպ × iteration-ի տևողություն (sleep-երով), ուստի 2 վայրկյանանոց ճանապարհը 50 iteration վայրկյանում տեմպով պահանջում է մոտ 100 VU․ maxVUs-ը սահմանեք պաշարով։ Նույն օրենքը բացատրում է սերվերի սահմանները․ 40 worker-ով PHP-FPM pool-ը 200 ms հարցումներով սահմանափակվում է մոտ 200 հարցում վայրկյանում, և դրանից վեր ամեն ինչ հերթագրվում է։ Եթե latency-ն թռչում է, մինչ throughput-ը հարթվում է, դուք ինչ-որ տեղ հասել եք concurrency-ի սահմանին․ worker pool, database connection-ներ կամ lock։

07Bottleneck-ի որոնումը թեստի ընթացքում

k6-ը ձեզ ասում է, որ ինչ-որ բան դանդաղ է․ սերվերային մետրիկաները ասում են՝ ինչու։ Հետևեք, այս հերթականությամբ, հավելվածի CPU-ին և worker-ների saturation-ին, database-ի CPU-ին, slow query log-ին և connection-ներին, cache hit ratio-ին, հերթի խորությանը և արտաքին API-ների latency-ին։ Յուրաքանչյուր ռեսուրսի համար օգտագործեք USE մեթոդը (utilisation, saturation, errors)։ k6-ում հարցումները tag արեք ըստ endpoint-ի անվան, որպեսզի ID-ներով URL-ները խմբավորվեն (օգտագործեք name tag-ը), և ամենադանդաղ endpoint-ները համադրեք ձեր APM-ի trace-երի հետ։ Շտկեք մեկ bottleneck միաժամանակ և նորից աշխատեցրեք նույն թեստը․ հաջորդ bottleneck-ը սովորաբար անմիջապես հայտնվում է։ Պահեք արդյունքների log՝ յուրաքանչյուր run-ի commit-ով, կոնֆիգուրացիայով և հիմնական թվերով, որպեսզի կարողանաք ազնվորեն համեմատել։

1// Group dynamic URLs under one metric name
2http.get(BASE + "/api/products/" + id, { tags: { name: "GET /api/products/:id" } });
3 
4// Custom metric for a business step
5import { Trend } from "k6/metrics";
6const checkoutTime = new Trend("checkout_duration", true);
7checkoutTime.add(res.timings.duration);

08Coordinated omission և generator-ի սահմաններ

Coordinated omission-ը տեղի է ունենում, երբ load generator-ը սպասում է դանդաղ պատասխաններին՝ նախքան հաջորդ հարցումն ուղարկելը, ուստի ավելի քիչ հարցում է ուղարկում հենց այն ժամանակ, երբ համակարգը դժվարանում է, և չափված latency-ն ավելի լավ է թվում, քան իրականությունը։ Closed-model executor-ները նախագծով տառապում են դրանից։ Arrival-rate executor-ները խուսափում են դրա մեծ մասից՝ iteration-ները սկսելով ժամանակացույցով, բայց եթե VU-ները սպառվում են, k6-ը հաղորդում է dropped_iterations, որը պետք է դիտարկեք որպես ձախողման ազդանշան։ Հետևեք նաև generator-ին․ եթե դրա CPU-ն մոտ 80%-ից բարձր է, ժամանակաչափումները դառնում են անհուսալի։ Մեծ թեստերի համար բեռը բաշխեք մի քանի մեքենայի վրա Kubernetes-ում k6 Operator-ով կամ Grafana Cloud k6-ով, և բեռը ստեղծեք նույն տարածաշրջանից, որտեղ օգտատերերն են։

09Թեստավորում HTTP-ից այն կողմ՝ WebSockets, gRPC և extension-ներ

k6-ն ունի ներկառուցված module-ներ HTTP/1.1-ի և HTTP/2-ի, WebSockets-ի, gRPC-ի և browser-ի համար, իսկ extension-ները (կառուցված xk6-ով, իսկ նոր տարբերակներում պաշտոնականները լուծվում են ավտոմատ) ավելացնում են այնպիսի protocol-ներ, ինչպիսիք են Kafka-ն, SQL-ը կամ Redis-ը։ Սա թույլ է տալիս թեստավորել համակարգի այն մասերը, որոնց HTTP-ն չի հասնում․ WebSocket chat հազարավոր connection-ների տակ, gRPC service mesh կամ հերթի consumer-ի throughput-ը։ Այս թեստերին վերաբերվեք ինչպես HTTP-ին․ իրատեսական հաղորդագրությունների տեմպեր, threshold-ներ latency-ի և սխալների վրա և սերվերային մոնիտորինգ։ Event-driven համակարգերի համար չափեք end-to-end ժամանակը publish-ից մինչև արդյունք, ոչ միայն publish կանչը։