Analiza performansi aplikacije: metrike, testiranje i praćenje

Informatec Digital » Resursi » Analiza performansi aplikacija: metrike, testiranje i praćenje

Da bi se dostigao taj nivo kvaliteta, nije dovoljno samo "malo testirati prije objavljivanja". Potrebna je kombinacija kontinuiranog praćenja (APM i RUM) , dobro osmišljenih testova performansi, jasnih metrika i alata sposobnih da simuliraju sve, od svakodnevne upotrebe do ekstremnih porasta prometa. Štaviše, to se mora uraditi strateški: mjerenjem onoga što je zaista važno za poslovanje i automatizacijom koliko god je to moguće kako bi se izbjeglo stalno reagovanje na probleme.

Performanse aplikacije: šta su, zašto su važne i šta mjerimo

Kada govorimo o performansama aplikacije, mislimo na sposobnost aplikacije da brzo reaguje, ostane stabilna i skalira se kako se korisnici ili količina podataka povećavaju, bez drastičnog povećanja potrošnje resursa ili ugrožavanja korisničkog iskustva. Ovo se odnosi na mobilne, web i desktop aplikacije , API-je, mikroservise i složene poslovne sisteme.

Ključno je sistematski mjeriti niz metrika performansi aplikacije (KPI) koje vam omogućavaju da shvatite da li aplikacija ispunjava tehničke i poslovne ciljeve i da na vrijeme otkrijete kada nešto počne ići po zlu, prije nego što to krajnji korisnik primijeti ili se u produkciji aktiviraju alarmi.

Među najčešćim metrikama koje se koriste za procjenu performansi aplikacije su:

• Upotreba procesoraKoliko procesora aplikacija troši i da li postoje skokovi koji otkrivaju prekomjerne izračune, loše dizajnirane petlje ili procese koji blokiraju odgovor.
• korištenje memorijeKoličina zauzete memorije, pojava curenja, grešaka stranica ili hiperstraničarenja koji ukazuju na to da sistem provodi više vremena premještajući podatke nego izvršavajući poslovnu logiku.
• Zahtjevi po minuti i bajtovi po zahtjevuOvo pokazuje koliko zahtjeva aplikacija ili API obrađuje i koliko podataka obrađuje u svakom zahtjevu. Pomaže vidjeti kako se backend skalira i da li je količina podataka po pozivu razumna.
• Latencija i vrijeme odziva: koliko vremena je potrebno aplikaciji da odgovori, od trenutka kada korisnik izvrši radnju ili klijent pošalje zahtjev do trenutka kada primi koristan odgovor.
• Vrijeme rada i dostupnost: postotak vremena u kojem je usluga aktivna i radi, obično se prati ponavljajućim pingovima ili sintetičkim provjerama.
• Stopa greškeudio zahtjeva koji završe greškom (HTTP 4xx/5xx kodovi, neobrađeni izuzeci, funkcionalni kvarovi).
• Apdex rezultat i zadovoljstvo korisnika: indeks koji sumira, u jednoj vrijednosti, postotak zadovoljnih, tolerantnih ili frustriranih korisnika na osnovu vremena odziva.
• Performanse sakupljanja smeća (GC)Na platformama s automatskim upravljanjem memorijom (Java, .NET, Android), koliko vremena se troši na GC, koliko pauza uvodi i kako to utiče na korištenje CPU-a i fluidnost.
• Brzina protoka ili performanse: broj transakcija ili zahtjeva obrađenih po jedinici vremena, kritično u sistemima sa visokom konkurentnošću.

Cilj praćenja ovih metrika nije prikupljanje grafikona: cilj je razumjeti stvarno stanje aplikacije , predvidjeti uska grla, odrediti prioritete poboljšanja i demonstrirati, uz pomoć podataka, da optimizacije imaju utjecaj i na korisničko iskustvo i na poslovne rezultate.

APM, RUM i praćenje performansi u realnom vremenu

U modernim okruženjima, s distribuiranim arhitekturama, kontejnerima, hibridnim oblacima i mikroservisima, praktično je nemoguće imati kontrolu nad performansama bez dobrog alata za praćenje performansi aplikacija (APM) u kombinaciji s tehnikama praćenja stvarnih korisnika (RUM) i, sve više, naprednim komponentama za praćenje.

APM/RUM rješenja (kao što su ona od Elastic-a, Instana-e, Applications Manager-a, Turbonomic-a integrirana s APM-om, itd.) pružaju potpuni uvid u ono što se događa u vašoj aplikaciji: vrijeme odziva, distribuirane tragove, upite u bazu podataka, vanjske pozive, greške i anomalije, integrirano s metrikama infrastrukture.

Praćenje stvarnih korisnika (RUM) bilježi ono što stvarni korisnici vide: vrijeme učitavanja ekrana, zamrzavanje interfejsa, greške preglednika ili mobilnih aplikacija i percipiranu latenciju u različitim regijama i uređajima. Ovo dopunjuje sintetičke benchmarkove i laboratorijske testove, koji su neophodni, ali ne zamjenjuju podatke iz stvarnog svijeta.

S druge strane, moderne APM platforme nude funkcije kao što su:

• Praćenje u realnom vremenu Ključni KPI-jevi: dostupnost, Apdex, stopa grešaka, brzina prenosa, Potrošnja resursa.
• Distribuirani tragovi pratiti transakciju kroz više mikroservisa, redova čekanja, baza podataka i eksternih servisa, identificirajući najsporiju vezu.
• Mape zavisnosti Automatizirani alati koji pokazuju kako su servisi, baze podataka, redovi čekanja i frontendovi povezani, olakšavajući otkrivanje uzroka kvara.
• Profiliranje koda i niti za lociranje metoda, SQL upita ili dijelova koda koji troše previše CPU-a ili blokiraju nit interfejsa.
• Pametna upozorenja i AIOps koji kombinuju mašinsko učenje i analizu vremenskih serija kako bi otkrili anomalije, smanjili lažne alarme i odredili prioritet kritičnih incidenata.

Kombinacijom APM-a, RUM-a i sintetičkog praćenja, dobijate potpuni uvid u performanse : šta korisnik vidi, šta aplikacija radi interno i kako reaguje osnovna infrastruktura. Ovo omogućava DevOps i ITOps timovima da brzo reaguju na incidente i, još bolje, da ih spriječe.

Ključne metrike performansi u mobilnim i web aplikacijama

U mobilnim i web aplikacijama, određeni pokazatelji performansi su posebno osjetljivi jer direktno utiču na percepciju korisnika i uspjeh proizvoda. Pažljivo praćenje ovih pokazatelja čini razliku između aplikacije koja privlači korisnike i one koja se deinstalira nakon druge upotrebe.

Jedna od kritičnih tačaka kod mobilnih uređaja je latencija pokretanja aplikacije , odnosno vrijeme koje prođe od trenutka kada korisnik dodirne ikonu (ili obavještenje) do trenutka kada vidi korisne podatke na ekranu. Može se razlikovati nekoliko vrsta:

• Hladni startAplikacija nije u memoriji; sistem mora kreirati proces, učitati kod, inicijalizirati biblioteke i prikazati prvi ekran.
• Polutopli startProces postoji, ali aktivnost je ponovo kreirana ili vraćena u neko stanje.
• Vrući startSamo trebate ponovo proširiti svoj pogled ili nastaviti aktivnost, uz vrlo malo dodatnog rada.

Kao referenca, toplo se preporučuje da se ciljno vrijeme hladnog pokretanja stavi ispod 500 ms, jer će to dovesti latencije p95 i p99 (najviši percentili) blizu medijane. Ako neki korisnici čekaju nekoliko sekundi dok drugi otvore aplikaciju za pola sekunde, nešto nije u ravnoteži.

Još jedan kritičan aspekt je skrolovanje i zamrzavanje interfejsa . Na ekranima koji se kreću (feedovi, liste, galerije), korisnici očekuju savršenu fluidnost. Kada sistem ne uspije generirati kadrove pri brzini osvježavanja uređaja (60 Hz, 90 Hz ili čak 120 Hz), dolazi do zastajkivanja i trzanja. Ova "zastajkivanja" se događaju kada aplikaciji treba duže od trajanja kadrova (na primjer, više od 16,7 ms pri 60 FPS) da prikaže sadržaj.

Pored fluidnosti, prijelazi između ekrana moraju se pažljivo pratiti . Prebacivanje između kartica, otvaranje detalja s liste ili prikazivanje dijaloga treba biti gotovo trenutno, s glatkim animacijama i bez treperenja ili dugotrajnih praznih ekrana.

U pozadini, ali podjednako važno, je potrošnja baterije i energetska efikasnost. Nepotrebni zadaci, masovna alokacija memorije i intenzivno korištenje CPU-a smanjuju vijek trajanja baterije i uzrokuju pregrijavanje uređaja. Android Runtime (ART) je poboljšao efikasnost, ali ako interna petlja vaše aplikacije kreira hiljade novih objekata u sekundi, troškovi alokacije i sakupljanja smeća bit će primjetni.

Tok rada za identifikaciju i ispravljanje problema s performansama

Da biste izbjegli oslanjanje na sreću, vrlo je korisno uspostaviti sistematski tijek rada za analizu performansi koji kombinira detaljno ručno testiranje u laboratoriju s prikupljanjem agregiranih metrika u produkciji. Tipičan pristup uključuje sljedeće korake:

Prvo, potrebno je identificirati kritična korisnička putovanja , odnosno tokove koji imaju najveći utjecaj na iskustvo i poslovanje:

• Često pokretanje aplikacija (ikona, obavještenja, dubinske veze).
• Ekrani sa kontinuiranim skrolanjem preko velikih količina podataka.
• Ključni prelazi između prikaza i aktivnosti.
• Dugi tokovi kao što su pregledavanje, reprodukcija zvuka/videa, naplata itd.

Nakon što se definiraju, instrumentaliziraju se i analiziraju korištenjem alata za profiliranje i praćenje kao što su Perfetto ili Systrace kako bi se vidjelo što uređaj radi s preciznošću od mikrosekundi, generatora memorijskih profila za otkrivanje curenja i vrućih tačaka alokacije ili alata kao što je Simpleperf kako bi se otkrilo koje funkcije troše najviše CPU-a.

Važno je naglasiti da detaljna analiza performansi zahtijeva otklanjanje grešaka u pojedinačnim prolazima ovih ruta, reproducirajući probleme na kontroliran način. Analiza agregiranih podataka je vrijedna za otkrivanje obrazaca i regresija, ali ne zamjenjuje dubinsku analizu specifičnih tragova.

Paralelno s tim, preporučljivo je postaviti kontinuirano prikupljanje metrika u automatiziranim testnim okruženjima i u produkciji: vrijeme pokretanja, stope blokiranja, metrike sličica (na primjer, putem FrameMetricsAggregator-a na Androidu), metrike polja Play Console, makro-benchmarkovi za pomicanje itd. Ove metrike vam omogućavaju da vidite stvarnu varijabilnost između uređaja, verzija operativnog sistema i mrežnih uslova.

Postavke aplikacije i sistema za precizno mjerenje

Jedna od najčešćih zamki je mjerenje performansi u nerealnim uslovima. Da bi rezultati bili korisni, i APK i sistem moraju biti pažljivo konfigurisani, osiguravajući da testno okruženje podsjeća na produkcijsko, a istovremeno kontroliše buku.

Na strani aplikacije, bitno je da se ne mjeri u odnosu na debug buildove . Debug varijante dodaju provjere, logove i zastavice koje značajno mijenjaju vrijeme izvođenja. U Androidu 10+, možete koristiti atribut `profileable android:shell="true"` u manifestu kako biste omogućili profiliranje u odnosu na release buildove, održavajući gotovo realistično ponašanje.

Također je preporučljivo koristiti smanjenje produkcijskog koda (ProGuard, R8, itd.), jer veličina i organizacija koda čine primjetnu razliku u performansama. Međutim, trebali biste pregledati pravila: neke konfiguracije mogu eliminirati tačke praćenja koje su važne za mjerenje, a one će se morati prilagoditi za testnu verziju.

Što se tiče kompajliranja, isplati se dovesti aplikaciju u poznato stanje, obično i jasno u mod brzine ili mod profila brzine . Oba smanjuju količinu koda interpretiranog iz DeX-a i potrebu za JIT kompajliranjem u pozadini, što stabilizira rezultate. Mod profila brzine pokušava više nalikovati ponašanju u stvarnom produkcijskom svijetu, ali zahtijeva "zagrijavanje" aplikacije i upravljanje profilima (na primjer, osnovni profili).

Sa sistemske perspektive, kada su potrebna vrlo precizna mjerenja (mikro-benchmarkovi), uobičajeno je kalibrirati uređaj : pokrenuti A/B testove na istom terminalu i verziji operativnog sistema, postaviti frekvencije CPU/GPU-a, onemogućiti male jezgre ili termalno ograničenje pomoću skripti poput lockClocks itd. Ovo ne predstavlja stvarni svijet, ali smanjuje šum za vrlo specifične scenarije.

Za mjerenja bliža korisničkom iskustvu (pokretanje, potrošnja baterije, padovi korisničkog interfejsa) preporučuje se korištenje okvira za testiranje kao što je Macrobenchmark , koji automatiziraju mnoge od ovih koraka i izbjegavaju suptilne, ali kritične greške u konfiguraciji.

Tipični obrasci problema s performansama

U gotovo svim aplikacijama koje su detaljno analizirane, pojavljuju se određeni ponavljajući obrasci problema koje vrijedi znati, jer obično postoje prilično jasna rješenja ako se otkriju na vrijeme.

Jedan od najčešćih problema je sporo pokretanje zbog aktivnosti premosnika . Ovo se dešava kada se, nakon namjere pokretanja (ikona, obavještenje, duboka veza), pokrene međuaktivnost koja ne crta nikakve okvire, a zatim se pokrene "prava" aktivnost. U tragovima se ovo pojavljuje kao dva uzastopna događaja `activityStart` bez vizualnog rada između. Ovaj "skok" dodaje latenciju pokretanja bez pružanja ikakve vrijednosti. Rješenje obično uključuje refaktorisanje inicijalizacije u komponentu koja se može ponovo koristiti ili njenu direktnu integraciju u glavnu aktivnost.

Još jedan klasičan primjer su nepotrebne alokacije koje pokreću sakupljanje smeća . Ako Systrace ili memorijski profili pokazuju GC cikluse koji se izvršavaju svakih nekoliko sekundi tokom dugotrajne operacije, vrlo je vjerovatno da postoji kod koji ponavljano i konstantno alocira objekte unutar intenzivnih petlji. Rješenje nije uklanjanje svakog novog objekta, već rješavanje vrućih tačaka, ponovna upotreba struktura ili primjena obrazaca grupisanja kada je to prikladno.

Okviri s blokiranjem se također često nalaze u grafičkom cjevovodu . U ispravnom tragu, pozivi funkcije Choreographer.doFrame() se javljaju u redovnoj kadenci (na primjer, svakih 16,7 ms). Zumiranje područja s ovom kadencom može otkriti skupe prikaze, previše složene rasporede, I/O operacije koje se izvode na UI niti ili pogrešno konfigurirane RecyclerView-ove.

RecyclerView je upravo izvor brojnih problema: poništavanje cijelog skupa podataka pomoću `notifyDataSetChanged()` kada se zapravo promijenilo samo nekoliko elemenata, nepravilno konfiguriranje recikliranih skupova prikaza u ugniježđenim RecyclerView-ima ili nedovoljno prethodno preuzimanje podataka kada se dođe do kraja liste. Sve ovo rezultira skupim renderiranjem, skokovima pri skrolovanju i primjetnim vremenima čekanja za korisnika.

Testiranje performansi: vrste, koraci i najbolje prakse

Pored praćenja produkcije, svaka ozbiljna strategija zahtijeva robustan plan testiranja performansi aplikacije u kontroliranim okruženjima. Ovo testiranje vam omogućava da provjerite kapacitet, stabilnost i skalabilnost prije nego što izložite korisnike promjenama ili novim izdanjima.

Postoji nekoliko vrsta testova, svaki sa svojim specifičnim ciljem:

• Testovi opterećenjaOni procjenjuju ponašanje aplikacije pod predviđenim opterećenjem korisnika ili transakcija, mjereći vrijeme odziva, propusnost i potrošnju resursa kako bi otkrili uska grla prije implementacije.
• Stres testoviOni guraju sistem izvan njegovih normalnih granica kako bi vidjeli koliko daleko se može gurati, kako može propasti i kako se oporaviti. Ključni su za planiranje kapaciteta i upravljanje vrhuncima tipa Crnog petka.
• Testovi izdržljivosti/namakanjaOni održavaju kontinuirano punjenje satima ili danima kako bi otkrili probleme spore degradacije, curenja memorije ili iscrpljivanja resursa.
• Vrhunski testoviOni simuliraju iznenadna i ponovljena povećanja opterećenja (npr. kampanje, lansiranja funkcija, prijenose uživo) kako bi provjerili mogu li aplikacija i infrastruktura podnijeti iznenadne promjene.
• Testovi volumenaOni analiziraju kako se aplikacija ponaša kada se broj korisnika značajno poveća. količina podataka (veličina baze podataka, datoteke, poruke), validacija vremena odziva, pouzdanost pohrane i gubitak podataka.
• Testovi skalabilnostiOni provjeravaju kako aplikacija reaguje kada se opterećenje postepeno povećava i da li horizontalno ili vertikalno skaliranje proizvodi očekivano poboljšanje performansi.

Tipičan proces testiranja performansi uključuje nekoliko različitih faza. Prvo, analiza zahtjeva : razumijevanje koja su vremena odziva, omjeri propusnosti, nivoi dostupnosti i ograničenja grešaka prihvatljivi za poslovanje. Zatim, faza planiranja i strategije u kojoj se definiraju obim testova, okruženje, alati i metrike koje će se pratiti.

Zatim se osmišljavaju testni slučajevi koji pokrivaju različite scenarije opterećenja, mrežne uvjete i količine podataka; konfigurira se testno okruženje (hardver, softver, mreža, alati za ubrizgavanje opterećenja i praćenje); i testovi se pokreću, pažljivo prikupljajući podatke o performansama.

Kritična faza je praćenje i analiza : povezivanje vremena odziva s korištenjem CPU-a, latencija mreže s stopama grešaka, skokova prometa s preopterećenjem baze podataka i tako dalje. Nakon dokumentiranja nalaza u jasnim izvještajima za zainteresirane strane, proces prelazi na optimizaciju i ponovno testiranje : kod, konfiguracije ili resursi se prilagođavaju, a testovi se ponavljaju dok se poboljšanja ne potvrde.

Alati i okviri za testiranje performansi

Da bi se sve navedeno primijenilo u praksi, potrebno je osloniti se na specifične alate za testiranje performansi , i otvorenog koda i komercijalne, koji pokrivaju automatizaciju, generiranje opterećenja, praćenje i analizu. Neke relevantne kategorije su:

• Alati otvorenog kodaProjekti poput Apache JMeter-a, Gatling-a, k6, Locust-a, Taurusa, nGrinder-a ili okvira za jedinično i funkcionalno testiranje (JUnit, XCTest, Appium) koji su prošireni scenarijima performansi omogućavaju konstrukciju vrlo moćnih testnih paketa uz niske troškove licenciranja.
• Komercijalno testiranje opterećenja i APM alatiRješenja kao što su WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest ili Parasoft pružaju integrirana okruženja s generiranjem opterećenja u oblaku, naprednim izvještavanjem i profesionalnom podrškom.
• Specijalizirana i uočljiva rješenjaProizvodi kao što su Applications Manager, Instana, Dynatrace, IBM Turbonomic ili platforme za praćenje mreže poput SolarWinds-a, koje se fokusiraju na kontinuirano praćenje, otkrivanje anomalija i korelaciju između performansi aplikacija, infrastrukture i korisničkog iskustva.
• Alati specifični za platformuU slučaju Androida, na primjer, alati kao što su Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace ili Play Console frame metrics, omogućavaju vrlo finu analizu ponašanja na nivou sistema.

Prilikom odabira između jednog ili drugog, preporučljivo je uzeti u obzir faktore kao što su jednostavnost korištenja, podrška za protokole i tehnologije, skalabilnost, integracija sa CI/CD , model licenciranja, proširivost i kvalitet podrške (podrška zajednice ili komercijalna podrška). Također nije neuobičajeno kombinovati nekoliko: jedan za generisanje opterećenja, drugi za APM i treći za mogućnost praćenja infrastrukture.

Ukratko, analiza i praćenje performansi aplikacija zahtijeva kombinaciju dobro odabranih metrika, odgovarajućih alata i discipline u procesima testiranja, ali rezultat više nego nadoknađuje: brže, stabilnije i efikasnije aplikacije , zadovoljniji korisnici, manje incidenata u produkciji i, naravno, direktan pozitivan utjecaj na reputaciju brenda i prihod.

Povezani članak:

Otkrijte Qt Creator IDE: Najmoćnije okruženje za kreiranje višeplatformskih aplikacija