Analiza delovanja aplikacij: metrike, testiranje in spremljanje

Informatec Digital » Viri » Analiza delovanja aplikacij: metrike, testiranje in spremljanje

Da bi dosegli to raven kakovosti, ni dovolj zgolj »malo testirati pred objavo«. Potrebna je kombinacija stalnega spremljanja (APM in RUM) , dobro zasnovanih testov delovanja, jasnih metrik in orodij, ki lahko simulirajo vse od vsakodnevne uporabe do ekstremnih porastov prometa. Poleg tega je treba to storiti strateško: meriti, kaj je resnično pomembno za podjetje, in čim bolj avtomatizirati, da se izognemo nenehnemu odzivanju na težave.

Učinkovitost delovanja aplikacij: kaj je to, zakaj je pomembna in kaj merimo

Ko govorimo o zmogljivosti aplikacije, mislimo na sposobnost aplikacije, da se hitro odzove, ostane stabilna in se prilagaja, ko se uporabniki ali količina podatkov povečajo, ne da bi se pri tem drastično povečala poraba virov ali ogrozila uporabniška izkušnja. To velja za mobilne, spletne in namizne aplikacije , API-je, mikrostoritve in kompleksne poslovne sisteme.

Ključno je sistematično merjenje vrste kazalnikov uspešnosti aplikacij (KPI) , ki vam omogočajo, da razumete, ali aplikacija izpolnjuje tehnične in poslovne cilje, ter pravočasno zaznate, kdaj gre kaj narobe, preden to opazi končni uporabnik ali se v produkciji sprožijo alarmi.

Med najpogostejšimi meritvami, ki se uporabljajo za ocenjevanje uspešnosti aplikacij, so:

• Uporaba procesorja: koliko procesorja porabi aplikacija in ali obstajajo konice, ki razkrivajo prekomerne izračune, slabo zasnovane zanke ali procese, ki blokirajo odziv.
• porabo pomnilnika: količina zasedenega pomnilnika, pojav puščanj, napak strani ali hiperstraničenja, ki kažejo, da sistem porabi več časa za premikanje podatkov kot za izvajanje poslovne logike.
• Zahteve na minuto in bajti na zahtevoTo prikazuje, koliko zahtev aplikacija ali API obdela in koliko podatkov obravnava v vsaki zahtevi. Pomaga videti, kako se zaledni sistem prilagaja in ali je količina podatkov na klic razumna.
• Zakasnitev in odzivni čas: koliko časa traja, da se aplikacija odzove, od trenutka, ko uporabnik izvede dejanje ali odjemalec pošlje zahtevo, do trenutka, ko prejme uporaben odgovor.
• Delovni čas in razpoložljivost: odstotek časa, ko storitev deluje, običajno spremljan s ponavljajočimi se pingi ali sintetičnimi preverjanji.
• Stopnja napakdelež zahtev, ki se končajo z napako (kode HTTP 4xx/5xx, neobravnavane izjeme, funkcionalne napake).
• Ocena Apdex in zadovoljstvo uporabnikov: indeks, ki v eni sami vrednosti povzema odstotek zadovoljnih, tolerantnih ali frustriranih uporabnikov na podlagi odzivnih časov.
• Učinkovitost odvoza smeti (GC)Na platformah z avtomatskim upravljanjem pomnilnika (Java, .NET, Android), koliko časa se porabi za GC, koliko premorov uvede in kako to vpliva na porabo in pretočnost CPE-ja.
• Pretočnost ali zmogljivost: število transakcij ali zahtev, obdelanih na časovno enoto, ključnega pomena v sistemih z visoko sočasnostjo.

Cilj sledenja tem metrikam ni zbiranje grafov, temveč razumevanje dejanskega stanja aplikacije , predvidevanje ozkih grl, določanje prioritet izboljšav in prikaz s podatki, da optimizacije vplivajo tako na uporabniško izkušnjo kot na poslovne rezultate.

APM, RUM in spremljanje delovanja v realnem času

V sodobnih okoljih z porazdeljenimi arhitekturami, vsebniki, hibridnimi oblaki in mikroservisi je praktično nemogoče imeti nadzor nad zmogljivostjo brez dobrega orodja za spremljanje zmogljivosti aplikacij (APM) v kombinaciji s tehnikami spremljanja dejanskih uporabnikov (RUM) in vse bolj naprednimi komponentami opazovanja.

Rešitve APM/RUM (kot so tiste podjetij Elastic, Instana, Applications Manager, Turbonomic, integrirane z APM itd.) zagotavljajo celovit vpogled v dogajanje v vaši aplikaciji: odzivne čase, porazdeljene sledi, poizvedbe v zbirki podatkov, zunanje klice, napake in anomalije, integrirane z metrikami infrastrukture.

Spremljanje dejanskih uporabnikov (RUM) zajame, kaj vidijo dejanski uporabniki: čase nalaganja zaslona, ​​zamrznitve vmesnika, napake brskalnika ali mobilne aplikacije in zaznano zakasnitev v različnih regijah in napravah. To dopolnjuje sintetične primerjalne teste in laboratorijske teste, ki so bistveni, vendar ne nadomeščajo podatkov iz resničnega sveta.

Sodobne platforme APM pa ponujajo funkcije, kot so:

• Spremljanje v realnem času Ključni kazalniki uspešnosti: razpoložljivost, Apdex, stopnja napak, hitrost prenosa, Poraba virov.
• Porazdeljene sledi za sledenje transakciji v več mikroservisih, čakalnih vrstah, bazah podatkov in zunanjih storitvah, pri čemer se prepozna najpočasnejša povezava.
• Zemljevidi odvisnosti Avtomatizirana orodja, ki prikazujejo, kako so storitve, baze podatkov, čakalne vrste in frontendi povezani, kar olajša odkrivanje vzroka napake.
• Profiliranje kode in niti za iskanje metod, poizvedb SQL ali delov kode, ki porabljajo preveč procesorja ali blokirajo nit vmesnika.
• Pametna opozorila in AIOps ki združujejo strojno učenje in analizo časovnih vrst za odkrivanje anomalij, zmanjšanje lažnih alarmov in določanje prioritet kritičnih incidentov.

Z združevanjem APM, RUM in sintetičnega spremljanja pridobite 360-stopinjski vpogled v delovanje : kaj vidi uporabnik, kaj aplikacija počne interno in kako se odziva osnovna infrastruktura. To omogoča ekipam DevOps in ITOps, da se hitro odzovejo na incidente in, še bolje, jih preprečijo.

Ključne metrike uspešnosti v mobilnih in spletnih aplikacijah

V mobilnih in spletnih aplikacijah so nekatere metrike učinkovitosti še posebej občutljive, saj neposredno vplivajo na uporabnikovo zaznavanje in uspeh izdelka. Skrbno spremljanje teh kazalnikov naredi razliko med aplikacijo, ki pritegne uporabnike, in tisto, ki se po drugi uporabi odstrani.

Ena od kritičnih točk pri mobilnih napravah je zakasnitev zagona aplikacije , torej čas, ki preteče od trenutka, ko uporabnik tapne ikono (ali obvestilo), do trenutka, ko na zaslonu vidi uporabne podatke. Ločimo lahko več vrst:

• Hladni zagonAplikacija ni v pomnilniku; sistem mora ustvariti proces, naložiti kodo, inicializirati knjižnice in prikazati prvi zaslon.
• Poltopel zagonProces obstaja, vendar je aktivnost ponovno ustvarjena ali obnovljena v neko stanje.
• Vroči zagon: samo napihniti morate svoj pogled ali nadaljevati z dejavnostjo, z zelo malo dodatnega dela.

Kot referenco je zelo priporočljivo, da si prizadevate za čase hladnega zagona pod 500 ms, saj se bosta s tem latenci p95 in p99 (najvišji percentili) približali mediani. Če nekateri uporabniki čakajo več sekund, medtem ko drugi odprejo aplikacijo v pol sekunde, je nekaj narobe.

Drug kritičen vidik je pomikanje in zamrzovanje vmesnika . Na premikajočih se zaslonih (viri, seznami, galerije) uporabniki pričakujejo popolno tekočnost. Ko sistem ne more ustvariti sličic s hitrostjo osveževanja naprave (60 Hz, 90 Hz ali celo 120 Hz), pride do zatikanja in trzanja. Do tega »trzanja« pride, ko aplikacija za upodabljanje vsebine potrebuje dlje kot trajanje sličice (na primer več kot 16,7 ms pri 60 FPS).

Poleg tekočnosti je treba skrbno spremljati tudi prehode med zasloni . Preklapljanje med zavihki, odpiranje podrobnosti s seznama ali prikazovanje pogovornega okna mora biti praktično takojšnje, z gladkimi animacijami in brez utripanja ali dolgotrajnih praznih zaslonov.

V ozadju, a enako pomembna, je poraba baterije in energetska učinkovitost. Nepotrebna opravila, ogromne dodelitve pomnilnika in intenzivna uporaba procesorja skrajšujejo življenjsko dobo baterije in povzročajo pregrevanje naprave. Android Runtime (ART) je izboljšal učinkovitost, če pa notranja zanka vaše aplikacije ustvarja na tisoče novih objektov na sekundo, bodo stroški dodelitve in zbiranja smeti opazni.

Potek dela za prepoznavanje in odpravljanje težav z zmogljivostjo

Da bi se izognili zanašanju na srečo, je zelo koristno vzpostaviti sistematičen potek dela za analizo učinkovitosti , ki združuje podrobno ročno testiranje v laboratoriju z zbiranjem zbirnih meritev v produkciji. Tipičen pristop vključuje te korake:

Najprej je treba opredeliti kritične uporabniške poti , torej tokove, ki imajo največji vpliv na izkušnjo in poslovanje:

• Pogosto zaganjanje aplikacij (ikona, obvestila, povezave v globino).
• Zasloni z nenehnim pomikanjem po velikih količinah podatkov.
• Ključni prehodi med pogledi in dejavnostmi.
• Dolgi procesi, kot so brskanje, predvajanje zvoka/videoposnetkov, blagajne itd.

Ko so definirani, se instrumentalizirajo in analizirajo z orodji za profiliranje in sledenje, kot sta Perfetto ali Systrace, da se z mikrosekundno natančnostjo vidi, kaj naprava počne, generatorji profilov pomnilnika za odkrivanje puščanj in vročih točk dodeljevanja ali orodji, kot je Simpleperf, da se ugotovi, katere funkcije porabijo največ procesorja.

Pomembno je poudariti, da podrobna analiza učinkovitosti delovanja zahteva odpravljanje napak v posameznih izvedbah teh poti, kar nadzorovano reproducira težave. Analiza združenih podatkov je dragocena za odkrivanje vzorcev in regresij, vendar ne nadomesti poglobljene analize določenih sledi.

Vzporedno je priporočljivo nastaviti neprekinjeno zbiranje metrik v avtomatiziranih testnih okoljih in produkciji: časi zagona, stopnje blokiranja, metrike sličic (na primer prek FrameMetricsAggregatorja v sistemu Android), metrike polj v konzoli Play, makro primerjalne vrednosti pomikanja itd. Te metrike vam omogočajo, da vidite dejansko variabilnost med napravami, različicami operacijskih sistemov in omrežnimi pogoji.

Nastavitve aplikacije in sistema za natančno merjenje

Ena najpogostejših pasti je merjenje zmogljivosti v nerealnih pogojih. Da bi bili rezultati uporabni, morata biti tako APK kot sistem skrbno konfigurirana, da se zagotovi, da je testno okolje podobno produkcijskemu, hkrati pa se nadzoruje šum.

Na strani aplikacije je bistveno, da se ne meri z različicami za odpravljanje napak . Različice za odpravljanje napak dodajajo preverjanja, dnevnike in zastavice, ki bistveno spremenijo čas izvajanja. V sistemu Android 10+ lahko v manifestu uporabite atribut `profileable android:shell="true"` , da omogočite profiliranje z različicami za izdajo in ohranite skoraj realistično vedenje.

Priporočljivo je tudi uporabiti zmanjšanje produkcijske kode (ProGuard, R8 itd.), saj velikost in organizacija kode opazno vplivata na zmogljivost. Vendar pa morate pregledati pravila: nekatere konfiguracije lahko izločijo sledilne točke, ki so pomembne za merjenje, in te bo treba prilagoditi za testno različico.

Kar zadeva prevajanje, je smiselno aplikacijo prevesti v znano stanje, običajno in jasno v način hitrosti ali način profila hitrosti . Oba načina zmanjšata količino kode, ki jo interpretira DeX, in potrebo po prevajanju JIT v ozadju, kar stabilizira rezultate. Način profila hitrosti poskuša bolj posnemati vedenje v resničnem svetu, vendar zahteva "ogrevanje" aplikacije in upravljanje profilov (na primer osnovnih profilov).

Z vidika sistema je običajno, da se naprava kalibrira , ko so potrebne zelo natančne meritve (mikro-referenčne vrednosti) : izvajajo se A/B testi na istem terminalu in različici operacijskega sistema, nastavijo se frekvence CPU/GPU, onemogočijo majhna jedra ali toplotna omejitev s skripti, kot je lockClocks itd. To ne predstavlja resničnega sveta, vendar zmanjša šum za zelo specifične scenarije.

Za meritve, ki so bližje uporabniški izkušnji (zagon, poraba baterije, zrušitve uporabniškega vmesnika), je priporočljiva uporaba testnih ogrodji, kot je Macrobenchmark , ki avtomatizirajo številne od teh korakov in se izognejo subtilnim, a kritičnim napakam pri konfiguraciji.

Tipični vzorci težav z delovanjem

V skoraj vseh temeljito analiziranih aplikacijah se pojavijo določeni ponavljajoči se vzorci težav , ki jih je vredno poznati, saj običajno obstajajo precej jasne rešitve, če so pravočasno odkrite.

Ena najpogostejših težav je počasen zagon zaradi aktivnosti skakalca . Do tega pride, ko se po zagonskem namenu (ikona, obvestilo, globoka povezava) zažene vmesna aktivnost, ki ne nariše nobenih okvirjev, nato pa se začne »prava« aktivnost. V sledeh se to prikaže kot dva zaporedna dogodka `activityStart` brez vizualnega dela vmes. Ta »skok« doda zakasnitev zagona, ne da bi pri tem zagotovil kakršno koli vrednost. Rešitev običajno vključuje preoblikovanje inicializacije v komponento, ki jo je mogoče ponovno uporabiti, ali njeno neposredno integracijo v glavno aktivnost.

Drug klasičen primer so nepotrebne dodelitve, ki sprožijo zbiranje smeti . Če Systrace ali profili pomnilnika prikazujejo cikle GC, ki se med dolgotrajno operacijo izvajajo vsakih nekaj sekund, je zelo verjetno, da obstaja koda, ki večkrat in nenehno dodeljuje objekte znotraj intenzivnih zank. Rešitev ni v odstranjevanju vsakega novega objekta, temveč v obravnavanju vročih točk, ponovni uporabi struktur ali uporabi vzorcev združevanja, kadar je to primerno.

Okvirji z blokiranjem se pogosto nahajajo tudi v grafičnem cevovodu . V zdravi sledi se klici funkcije Choreographer.doFrame() izvajajo z redno kadenco (na primer vsakih 16,7 ms). Povečava območij s to kadenco lahko razkrije drage poglede, preveč zapletene postavitve, vhodno/izhodne operacije, ki se izvajajo v niti uporabniškega vmesnika, ali napačno konfigurirane elemente RecyclerView.

RecyclerView je prav vir številnih težav: razveljavitev celotnega nabora podatkov z `notifyDataSetChanged()`, ko se je dejansko spremenilo le nekaj elementov, nepravilna konfiguracija recikliranih pogledov v ugnezdenih RecyclerView-ih ali neizvajanje zadostnega prednalaganja podatkov, ko je dosežen konec seznama. Vse to povzroči drago upodabljanje, skoke pri pomikanju in opazne čakalne čase za uporabnika.

Testiranje zmogljivosti: vrste, koraki in najboljše prakse

Poleg spremljanja produkcije vsaka resna strategija potrebuje robusten načrt testiranja delovanja aplikacij v nadzorovanih okoljih. To testiranje vam omogoča, da preverite zmogljivost, stabilnost in skalabilnost, preden uporabnike izpostavite spremembam ali novim izdajam.

Obstaja več vrst testov, vsak s svojim specifičnim ciljem:

• Obremenitveni testiOcenijo vedenje aplikacije pri predvideni obremenitvi uporabnikov ali transakcij, pri čemer merijo odzivne čase, prepustnost in porabo virov, da bi pred uvedbo odkrili ozka grla.
• Stresni testiSistem potiskajo preko njegovih normalnih meja, da bi videli, kako daleč ga je mogoče potisniti, kako odpove in kako si opomore. Ključni so za načrtovanje zmogljivosti in obvladovanje konic, kot so tiste, ki se zgodijo po črnem petku.
• Preizkusi vzdržljivosti/namakanjaVzdržujejo stalno obremenitev več ur ali dni, da odkrijejo težave s počasno degradacijo, puščanjem pomnilnika ali izčrpavanjem virov.
• Vrhunski testiSimulirajo nenadna in ponavljajoča se povečanja obremenitve (npr. kampanje, predstavitve funkcij, prenosi v živo), da preverijo, ali lahko aplikacija in infrastruktura obvladujeta nenadne spremembe.
• Volumski testiAnalizirajo, kako se aplikacija obnaša, ko se število uporabnikov znatno poveča. količina podatkov (velikost baze podatkov, datoteke, sporočila), preverjanje odzivnih časov, zanesljivost shranjevanja in izguba podatkov.
• Testi skalabilnostiPreverjajo, kako se aplikacija odziva, ko se obremenitev postopno povečuje, in ali horizontalno ali vertikalno skaliranje povzroči pričakovano izboljšanje zmogljivosti.

Tipičen postopek testiranja zmogljivosti vključuje več različnih faz. Najprej je potrebna analiza zahtev : razumevanje, kateri odzivni časi, razmerja pretočnosti, ravni razpoložljivosti in omejitve napak so sprejemljive za podjetje. Nato sledi faza načrtovanja in strategije, v kateri se opredelijo obseg testov, okolje, orodja in metrike, ki jih je treba spremljati.

Nato so testni primeri zasnovani tako, da pokrivajo različne scenarije obremenitve, omrežne pogoje in količine podatkov; konfigurira se testno okolje (strojna oprema, programska oprema, omrežje, orodja za vbrizgavanje obremenitve in spremljanje); in izvedejo se testi, pri čemer se skrbno zbirajo podatki o zmogljivosti.

Kritična faza je spremljanje in analiza : povezovanje odzivnih časov z porabo procesorja, omrežnih zakasnitev s stopnjami napak, porastov prometa s preobremenitvami baze podatkov in tako naprej. Po dokumentiranju ugotovitev v jasnih poročilih za deležnike se postopek premakne k optimizaciji in ponovnemu testiranju : koda, konfiguracije ali viri se prilagodijo, testi pa se ponavljajo, dokler izboljšave niso potrjene.

Orodja in ogrodja za testiranje zmogljivosti

Da bi vse zgoraj navedeno uporabili v praksi, se je treba zanašati na specifična orodja za testiranje zmogljivosti , tako odprtokodna kot komercialna, ki zajemajo avtomatizacijo, ustvarjanje obremenitev, spremljanje in analizo. Nekatere ustrezne kategorije so:

• Orodja odprte kodeProjekti, kot so Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder ali ogrodja za enotno in funkcionalno testiranje (JUnit, XCTest, Appium), ki so razširjena s scenariji delovanja, omogočajo izdelavo zelo zmogljivih testnih paketov z nizkimi stroški licenciranja.
• Orodja za komercialno obremenitveno testiranje in APMRešitve, kot so WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest ali Parasoft, zagotavljajo integrirana okolja z generiranjem obremenitve v oblaku, naprednim poročanjem in profesionalno podporo.
• Specializirane in opazne rešitveIzdelki, kot so Applications Manager, Instana, Dynatrace, IBM Turbonomic ali platforme za spremljanje omrežja, kot je SolarWinds, ki se osredotočajo na neprekinjeno spremljanje, odkrivanje anomalij in korelacijo med delovanjem aplikacij, infrastrukturo in uporabniško izkušnjo.
• Orodja, specifična za platformoV primeru Androida na primer orodja, kot so Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace ali metrike okvirjev Play Console, omogočajo zelo natančno analizo vedenja na ravni sistema.

Pri izbiri med eno ali drugo možnostjo je priporočljivo upoštevati dejavnike, kot so enostavnost uporabe, podpora protokolom in tehnologijam, skalabilnost, integracija s CI/CD , model licenciranja, razširljivost in kakovost podpore (podpora skupnosti ali komercialna podpora). Prav tako ni neobičajno, da se jih kombinira več: ena za generiranje obremenitve, druga za APM in tretja za opazovanje infrastrukture.

Skratka, analiziranje in spremljanje delovanja aplikacij zahteva kombinacijo dobro izbranih metrik, ustreznih orodij in discipline v procesih testiranja, vendar rezultat več kot nadomesti: hitrejše, stabilnejše in učinkovitejše aplikacije , bolj zadovoljni uporabniki, manj produkcijskih incidentov in seveda neposreden pozitiven vpliv na ugled in prihodke blagovne znamke.

Povezani članek:

Odkrijte Qt Creator IDE: Najzmogljivejše okolje za ustvarjanje aplikacij za več platform