Kodėl apskritai kalbame apie apkrovos testavimą?
Prieš pasinerdami į konkrečių įrankių palyginimą, verta suprasti, kodėl apkrovos testavimas yra ne tik svarbus, bet ir būtinas šiuolaikinėje programinės įrangos kūrimo ekosistemoje. Turbūt kiekvienas esame patyrę situaciją, kai populiari svetainė tiesiog „nugulė” per juodąjį penktadienį arba kai naujai paleista aplikacija tiesiog neatlaikė vartotojų antplūdžio. Tai ne tik kenkia reputacijai – tai tiesiogiai veikia pajamas.
Apkrovos testavimas leidžia simuliuoti realias naudojimo sąlygas dar prieš produktą pasiekiant galutiniam vartotojui. Tai tarsi generalinė repeticija prieš didįjį pasirodymą. Galite išsiaiškinti, kiek vartotojų jūsų sistema gali aptarnauti vienu metu, kur yra siaurausi vietai (bottlenecks), ir kaip sistema elgiasi esant kritinei apkrovai.
Šiandien pažvelgsime į du populiarius apkrovos testavimo įrankius: senbuvi JMeter ir gana naują žaidėją k6. Abu turi savo fanų armiją, ir abu gali efektyviai atlikti savo darbą, bet jų filosofija ir požiūris skiriasi kaip diena ir naktis.
JMeter: veteranas su savo keblumais
Apache JMeter atsirado dar 1998 metais, kai daugelis iš mūsų dar mokėsi programuoti su Pascal. Tai Java paremtas įrankis, kuris per daugiau nei du dešimtmečius tapo de facto standartu daugelyje organizacijų. Ir tam yra priežasčių.
JMeter siūlo grafinę vartotojo sąsają (GUI), kuri leidžia kurti testus vilkdami ir mesdami elementus. Tai puiku pradedantiesiems arba tiems, kas nori greitai sukurti paprastą testą. Galite vizualiai matyti savo testo struktūrą, pridėti klausytojus (listeners), konfigūruoti įvairius parametrus – visa tai neišeinant iš GUI aplinkos.
Tačiau štai kur prasideda problemos. JMeter GUI yra lėta. Tikrai lėta. Kai jūsų testai tampa sudėtingesni, GUI pradeda stabdyti. O pats testavimas su GUI? Tai didžiulis ne-ne. JMeter dokumentacija aiškiai įspėja: niekada nevykdykite apkrovos testų su GUI. Tai sunaudoja per daug resursų ir iškreipia rezultatus.
Testų kūrimas JMeter taip pat turi savo specifikos. Jūsų testai saugomi XML formatu JMX failuose. Bandėte kada nors peržiūrėti JMX failą? Tai ne pats maloninusias patyrimas. Version control sistemose šie failai tampa košmaru – merge konfliktai praktiškai neišsprendžiami rankiniu būdu. Kodo peržiūros (code reviews)? Pasisekimo reikalas.
k6: naujos kartos požiūris
k6 atsirado 2017 metais ir iš karto parodė, kad apkrovos testavimas gali būti kitoks. Sukurtas Grafana Labs (buvusios Load Impact) komandos, šis įrankis nuo pat pradžių buvo orientuotas į kūrėjus ir DevOps specialistus.
Pagrindinis k6 skirtumas – testai rašomi JavaScript (tiksliau, ES6+). Ne XML, ne keista DSL (domain-specific language), o tiesiog JavaScript. Jei esate frontend arba backend kūrėjas, dirbantis su Node.js, jums nereikės mokytis naujos kalbos ar sintaksės. Tiesiog rašote kodą.
Štai kaip atrodo paprastas k6 testas:
„`javascript
import http from ‘k6/http’;
import { check, sleep } from ‘k6′;
export let options = {
vus: 10,
duration: ’30s’,
};
export default function() {
let response = http.get(‘https://test.k6.io’);
check(response, {
‘status is 200’: (r) => r.status === 200,
});
sleep(1);
}
„`
Matote? Skaitoma, suprantama, ir bet kuris kūrėjas gali tai perskaityti code review metu. Nereikia specialių įrankių, kad atidarytumėte testą – tai tiesiog tekstinis failas.
k6 taip pat yra CLI-first įrankis. Nėra GUI, kuris jus gundytų. Viskas vykdoma per komandinę eilutę, o tai reiškia, kad lengva integruoti į CI/CD pipeline’us. Rezultatai gali būti eksportuojami į įvairias sistemas – InfluxDB, Prometheus, Grafana Cloud, ar net tiesiog JSON failą.
Našumo palyginimas: kas ką nugali?
Čia tampa įdomu. JMeter, būdamas Java aplikacija, yra gana resursų ėdrus. Kiekvienas virtualus vartotojas (VU) JMeter sukuria atskirą thread’ą, o tai reiškia, kad jūsų mašinos resursai greitai išsenka. Praktiškai, viename vidutiniame serveryje galite paleisti gal 500-1000 concurrent users, priklausomai nuo testo sudėtingumo.
k6, parašytas Go kalba, yra žymiai efektyvesnis. Vienas k6 procesas gali lengvai generuoti tūkstančius virtualių vartotojų, nes naudoja Go goroutines vietoj sunkių thread’ų. Tai reiškia, kad tuo pačiu hardware galite simuliuoti žymiai didesnę apkrovą.
Realūs testai rodo, kad k6 gali būti 5-10 kartų efektyvesnis nei JMeter tuo pačiu hardware. Tai ne tik sutaupo pinigų (mažiau serverių reikia testavimui), bet ir leidžia greičiau gauti rezultatus.
Bet štai kur JMeter vis dar turi pranašumų: protokolų palaikymas. JMeter palaiko ne tik HTTP/HTTPS, bet ir SOAP, FTP, JDBC, LDAP, JMS, SMTP ir dar daugybę kitų protokolų. k6 daugiausia orientuotas į HTTP/1.1, HTTP/2, WebSockets ir gRPC. Jei jums reikia testuoti senesnius protokolus, JMeter vis dar yra geresnis pasirinkimas.
Testų kūrimas ir palaikymas
Čia k6 tikrai švyti. Kadangi testai rašomi JavaScript, galite naudoti visus įprastus programavimo principus: funkcijas, modulius, bibliotekas. Galite sukurti helper funkcijas, importuoti bendrus konfigūracijos failus, net naudoti npm paketus (su tam tikrais apribojimais).
Pavyzdžiui, galite lengvai sukurti reusable autentifikacijos modulį:
„`javascript
// auth.js
export function login(username, password) {
let response = http.post(‘https://api.example.com/login’, {
username: username,
password: password
});
return response.json(‘token’);
}
// test.js
import { login } from ‘./auth.js’;
export default function() {
let token = login(‘[email protected]’, ‘password123’);
// naudoti token kitiems request’ams
}
„`
JMeter taip pat leidžia modularizuoti testus naudojant Test Fragments ir Include Controllers, bet tai nėra taip intuityvus ar lankstus kaip tiesiog rašyti kodą. Be to, bandymas suvaldyti versijų kontrolę su JMX failais yra nuolatinė kova.
Kalbant apie debugging’ą, k6 vėlgi laimi. Galite naudoti console.log() bet kurioje vietoje, ir išvestis bus matoma terminale. JMeter debugging’as dažniausiai reiškia View Results Tree listener’io pridėjimą ir bandymą suprasti, kas vyksta iš XML atsakymų.
Integracija su CI/CD ir cloud
Šiuolaikiniame DevOps pasaulyje apkrovos testavimas turi būti dalis jūsų deployment pipeline’o, ne kažkas, ką darote kartą per ketvirtį rankiniu būdu. Čia k6 tikrai parodo savo stipriąsias puses.
k6 buvo sukurtas su CI/CD mintyse. Tai paprasta komandinė eilutė, kuri grąžina exit kodą priklausomai nuo testo rezultatų. Galite nustatyti thresholds (ribas), ir jei jos neįvykdomos, testas failed:
„`javascript
export let options = {
thresholds: {
‘http_req_duration’: [‘p(95)<500'], // 95% request'ų turi būti greičiau nei 500ms
'http_req_failed': ['rate<0.01'], // mažiau nei 1% request'ų gali failed
},
};
```
Jei šie kriterijai neįvykdomi, k6 grąžina ne-nulį exit kodą, ir jūsų CI pipeline'as gali automatiškai sustabdyti deployment'ą.
JMeter taip pat gali būti integruotas į CI/CD, bet tai reikalauja daugiau darbo. Jums reikės sukurti wrapper skriptus, konfigūruoti JMeter properties per komandinę eilutę, ir parsinti rezultatų failus, kad nustatytumėte, ar testas praėjo ar ne.
Cloud palaikymas? k6 turi Grafana Cloud k6, kuri leidžia paleisti testus iš įvairių pasaulio lokacijų be jokios infrastruktūros valdymo. JMeter gali būti paleidžiamas cloud'e (yra įvairių trečiųjų šalių sprendimų), bet tai nėra taip seamless.
Bendruomenė, dokumentacija ir ekosistema
JMeter, būdamas rinkoje daugiau nei 20 metų, turi milžinišką bendruomenę. Bet kokią problemą, kurią susidursite, greičiausiai kažkas jau yra sprendęs. Stack Overflow pilnas JMeter klausimų ir atsakymų. Yra daugybė plugin’ų – JMeter Plugins projektas siūlo šimtus papildomų funkcijų.
Tačiau štai problema: didelė dalis šios informacijos yra pasenusi. Rasite tutorial’ų iš 2012 metų, kurie vis dar veikia, bet naudoja senus best practices. JMeter dokumentacija yra išsami, bet ne visada draugiška pradedantiesiems.
k6 bendruomenė yra mažesnė, bet labai aktyvi ir modernia. Dokumentacija yra puiki – aiški, su praktiniais pavyzdžiais, ir nuolat atnaujinama. k6 komanda aktyviai bendrauja Discord’e ir forumuose. Kadangi įrankis naujesnis, dauguma informacijos yra aktuali ir atitinka šiuolaikinius standartus.
Ekosistemos prasme, k6 turi integracijas su populiariausiomis monitoring ir observability platformomis. Grafana, Prometheus, Datadog, New Relic – visi palaiko k6 rezultatus. JMeter rezultatus taip pat galima integruoti, bet dažnai reikia papildomų įrankių ar plugin’ų.
Kaina ir licencijavimas
Abu įrankiai yra open source ir nemokami baziniam naudojimui. JMeter yra Apache 2.0 licencija, k6 – AGPL 3.0 (su tam tikromis išimtimis komerciniams naudojimams).
Skirtumas atsiranda, kai kalbame apie cloud sprendimus. Grafana Cloud k6 yra mokama paslauga (nors turi nemokamą tier’ą), kuri leidžia paleisti testus iš cloud be savo infrastruktūros. JMeter neturi oficialaus cloud sprendimo, bet yra trečiųjų šalių paslaugų kaip BlazeMeter ar Flood.io, kurios siūlo JMeter testų vykdymą cloud’e už pinigus.
Jei planuojate viską vykdyti savo infrastruktūroje, abu įrankiai yra visiškai nemokami. Bet atsiminkite, kad JMeter reikalauja daugiau resursų, tai gali reikšti didesnes infrastruktūros išlaidas.
Kas gi laimi šią kovą?
Atsakymas, kaip ir daugelyje technologijų palyginimų, yra: priklauso. Bet leiskite būti šiek tiek konkretesniam.
Jei esate didelė organizacija su legacy sistemomis, kuri jau turi JMeter testus ir komandą, kuri moka su juo dirbti, nėra būtinybės skubiai pereiti prie k6. JMeter vis dar puikiai atlieka savo darbą, ypač jei jums reikia testuoti ne-HTTP protokolus.
Tačiau jei kuriate naują apkrovos testavimo strategiją, dirbate su moderniais mikroservisais, ir norite, kad testavimas būtų dalis jūsų CI/CD pipeline’o, k6 yra akivaizdus pasirinkimas. Jis greičiau mokosi, lengviau integruojamas, ir efektyviau naudoja resursus.
Asmeniškai, po daugelio metų darbo su JMeter, perjimas prie k6 buvo atgaivinantis. Galimybė rašyti testus kaip kodą, naudoti version control be skausmo, ir lengvai integruoti su CI/CD – tai žaidimo keitėjai. Taip, kartais pasiilgstu JMeter plačių protokolų palaikymo, bet 95% atvejų k6 daro viską, ko man reikia, ir daro tai geriau.
Jei dar nesprendėte, mano patarimas būtų toks: išbandykite k6 vienam nedideliam projektui. Sukurkite paprastą testą, paleiskite jį, pažiūrėkite, kaip jaučiatės. Jei jums patinka developer-friendly požiūris ir efektyvumas, greičiausiai norėsite naudoti jį daugiau. Jei ne, JMeter niekur nedingsta ir vis dar yra solid pasirinkimas.
Galiausiai, geriausias apkrovos testavimo įrankis yra tas, kurį iš tikrųjų naudojate. Nesvarbu, ar tai JMeter, k6, ar kažkas kitas – svarbu, kad testuotumėte savo sistemas prieš jas pasiekiant vartotojams. Nes niekas nenori būti ta kompanija, kurios svetainė nugula per Black Friday.
