Skalabilnost aplikacije provjerava se mjerenjem cijelog poslovnog scenarija pri opterećenju koje stvarno očekujete, a zatim pronađete resurs ili serijsku točku koja ga ograničava. Još servera neće riješiti zaključani red u bazi, serijski obračun, spori vanjski API ili red poruka koji raste brže nego što ga potrošač prazni. Cilj nije postići lijep rezultat testa, nego dokazati koji kapacitet sustav ima i kako se ponaša kada ga prijeđe.
Prosječan broj korisnika rijetko govori dovoljno o stvarnom opterećenju. Za poslovnu aplikaciju važnije je što korisnici rade istodobno, nad kojim podacima i u kojem dijelu radnog dana.
Zaključenje mjeseca, jutarnji unos proizvodnje, izdavanje većeg broja dokumenata ili masovni obračun mogu imati sasvim drukčiji profil od uobičajenog rada. Jedan proces može dominantno čitati podatke, a drugi istodobno stvarati mnogo upisa, zaključavanja i pozadinskih poslova.
Zato polazište nije pitanje "Koliko korisnika sustav podnosi?". Korisnije je pitanje: "Može li sustav u vršnom trenutku završiti posao koji korisnici moraju završiti?"
Za svaki važan scenarij opišite:
Takav opis pretvara nejasan zahtjev za većim kapacitetom u testabilnu odluku. Primjerice, nije dovoljno reći da izvještaj mora biti brz. Treba odrediti smije li interaktivna potvrda proizvodnog unosa čekati dok se pokreće masovni izvještaj i što se događa ako oba procesa koriste isti resurs.
Load testing je koristan samo ako promet u testu podsjeća na rad koji očekujete. Test koji šalje velik broj jednakih GET zahtjeva može pokazati dobru latenciju, a propustiti problem u upisima, obradi reda ili sinkronom pozivu prema vanjskom servisu.
Model opterećenja ne mora na početku biti složen, ali mora sadržavati stvarne omjere i redoslijed radnji. Ako u vrhuncu većina korisnika unosi podatke, a manji dio pregledava stanje, test mora obuhvatiti oba toka. Ako unos pokreće izračun ili poruku za drugu aplikaciju, taj se nastavak ne smije izostaviti.
Korisno je provesti test u tri faze:
Ova posljednja faza često razdvaja kratkotrajno usporavanje od problema koji nastavlja blokirati rad i nakon što vršni promet prođe.
Spor odgovor je simptom, ne dijagnoza. Latencija može rasti zato što je procesor zauzet, memorija pod pritiskom, broj veza prema bazi dosegnuo granicu, disk spor, mreža zagušena ili vanjski servis ograničava pozive. U poslovnim sustavima čest uzrok može biti i zaključavanje: više procesa čeka isti podatak ili isti redoslijed obrade.
Tijekom load testinga pratite najmanje sljedeće pokazatelje:
Percentili su važni jer prosjek može sakriti iskustvo manjeg, ali poslovno važnog dijela zahtjeva. Ako većina potvrda prođe brzo, a dio čeka neprihvatljivo dugo, korisnik koji mora ponoviti unos ili propusti rok ne doživljava sustav kao responzivan.
Povežite zahtjev kroz tracing, od korisničke radnje do baze, reda i vanjskog poziva. Tek tada možete vidjeti gdje vrijeme stvarno nestaje. Metrika može pokazati rast čekanja, a trace može potvrditi čeka li aplikacija bazu, potrošača reda ili vanjsku ovisnost.
Dodavanje instanci aplikacije pomaže samo kada se posao može raspodijeliti. Ako cijeli tok prolazi kroz globalnu bravu, zajedničku sesiju, jedan potrošač reda ili jedan serijski obračun, dodatne instance mogu povećati konkurenciju za isti ograničeni resurs.
Zato prije promjene infrastrukture provjerite postoji li serijska točka. Pitanja za odluku mogu biti jednostavna:
Rješenje ponekad nije veći kapacitet, nego promjena algoritma, grupiranje upisa, uklanjanje nepotrebne koordinacije ili asinkrona obrada. Cache može smanjiti opterećenje čitanja, ali uvodi pitanje zastarjelosti podataka. Asinkrona obrada može skratiti čekanje korisnika, ali zahtijeva jasan status obrade i način postupanja kod pogreške. Svaka optimizacija ima poslovnu posljedicu koju treba razumjeti prije uvođenja.
Kod procesa koji prelaze više funkcija posebno je važno promatrati cijeli tok. Poslovni moduli povezani s ERP-om mogu dijeliti podatke i ovisnosti, pa lokalno ubrzanje jednog ekrana ne mora ukloniti usko grlo u sljedećem koraku.
Za svaki scenarij zapišite iste stavke prije i nakon testa. Time se izbjegava optimiziranje prema dojmu ili prema jednoj izoliranoj metrici.
Ovaj slijed sprječava pogrešan zaključak da je promjena pomogla samo zato što je test bio drukčiji. Također čuva vezu između tehničke metrike i poslovne odluke: koja radnja mora ostati dostupna, a koja može pričekati.
Svaki sustav ima granicu kapaciteta. Prelazak te granice treba biti predvidiv. Nekontrolirano čekanje može zauzeti sve radne niti ili veze prema bazi i pretvoriti lokalno usporavanje u potpuni zastoj.
Backpressure, ograničenje reda, rate limiting i pravovremeni timeout mogu pomoći sustavu kontrolirano odbiti, odgoditi ili rasporediti posao. No poslovni sloj mora odrediti prioritete. Interaktivna potvrda korisnika možda ne smije čekati iza masovnog izvještaja, dok izvještaj može biti odgođen ili obrađen u pozadini.
Korisniku treba dati pošten odgovor. Bolje je jasno pokazati da obrada čeka i sačuvati zahtjev kada je to prikladno, nego ostaviti ekran u beskonačnom učitavanju koje potiče ponovno klikanje i stvara dodatno opterećenje.
Ovdje postoje stvarni kompromisi. Veći red može privremeno zaštititi aplikaciju, ali povećava vrijeme čekanja i rizik zaostalih poruka. Kraći timeout može brže osloboditi resurse, ali može prekinuti postupak koji bi se inače dovršio. Zato granice i prioriteti trebaju proizlaziti iz poslovnog scenarija, a ne samo iz tehničkih zadanih vrijednosti.
Jedan uspješan test nije trajna potvrda skalabilnosti. Podaci rastu, funkcije se mijenjaju, obrasci korištenja se pomiču, a vanjske ovisnosti dobivaju nova ograničenja. Trošak skaliranja također treba pratiti. Sustav koji postiže cilj samo uz neodrživ trošak nije riješen na održiv način.
Odredite pragove koji upozoravaju prije zasićenja, dodijelite vlasnika za njihovo praćenje i ponavljajte relevantne scenarije nakon značajnih promjena. To je posebno korisno kada se povezuju procesi proizvodnje, računovodstva i integracija u povezanom poslovanju , gdje promjena jednog toka može promijeniti opterećenje drugoga.
Ako nije jasno koji scenarij treba testirati ili gdje početi s mjerenjem, ERP i procesni screening može pomoći strukturirati procese, ovisnosti i odluke prije većeg zahvata. ORKA performance review povezuje poslovni scenarij, load test, observability i arhitekturnu odluku kako bi se kapacitet procjenjivao dokazom o tome gdje sustav stvarno prestaje pratiti posao.