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, da "malo preizkusite pred objavo". Potrebna je kombinacija dejavnikov. neprekinjeno spremljanje (APM in RUM)Dobro zasnovani testi delovanja, jasne metrike in orodja, ki lahko simulirajo vse od vsakodnevne uporabe do ekstremnih porastov prometa, so bistvenega pomena. 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, imamo v mislih sposobnost aplikacije, da se hitro odzove, je stabilna in prilagodljiva ko se število uporabnikov ali količina podatkov poveča, ne da bi pri tem prišlo do povečanja porabe virov ali poslabšanja uporabniške izkušnje. To velja za mobilne, spletne in namizne aplikacijeAPI-ji, mikrostoritve ali kompleksni poslovni sistemi.

Ključno je sistematično meriti vrsto metrike uspešnosti aplikacij (KPI-ji) ki nam omogočajo, da razumemo, ali aplikacija izpolnjuje tehnične in poslovne cilje, ter da pravočasno zaznamo, kdaj začne iti 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 grafikonov: je razumeti dejansko stanje aplikacije, predvideti ozka grla, dati prednost izboljšavam in s podatki dokazati, 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, kontejnerji, hibridnimi oblaki in mikroservisi je praktično nemogoče nadzorovati zmogljivost brez dobrega orodje za spremljanje delovanja aplikacij (APM) v kombinaciji s tehnikami spremljanja dejanskih uporabnikov (RUM) in vse bolj naprednimi komponentami opazovalnosti.

Rešitve APM/RUM (kot so tiste podjetij Elastic, Instana, Applications Manager, Turbonomic, integrirane z APM itd.) zagotavljajo vidnost od konca do konca dogajanja v vaši aplikaciji: odzivni časi, porazdeljene sledi, poizvedbe v zbirki podatkov, zunanji klici, napake in anomalije, integrirano z metrikami infrastrukture.

El Nadzor resničnih uporabnikov (RUM) Zajame, kar 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.

Kombinacija APM, RUM in sintetičnega spremljanja ima za posledico 360° preglednost delovanjaTo omogoča vpogled v to, kaj uporabnik vidi, 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 ključnih točk v mobilnih napravah je zakasnitev zagona aplikacijeTo pomeni čas, ki preteče od trenutka, ko uporabnik tapne ikono (ali obvestilo), do trenutka, ko na zaslonu vidi uporabne podatke. Razlikujemo 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 referenca je zelo priporočljivo, da si prizadevate za hladni zagoni pod 500 ms Ker sta latenci p95 in p99 (najvišji percentili) blizu mediane, če nekateri uporabniki čakajo nekaj sekund, medtem ko drugi odprejo aplikacijo v pol sekunde, je nekaj neuravnoteženo.

Drug kritičen vidik je pomikanje in zaklepanje vmesnikaNa zaslonih, ki se premikajo (viri, seznami, galerije), uporabniki pričakujejo popolno tekočnost. Ko sistem ne uspe 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 več časa, kot je trajanje sličice (na primer več kot 16,7 ms pri 60 FPS).

Poleg tekočnosti je treba spremljati tudi prehodi med zasloniPreklapljanje med zavihki, odpiranje podrobnosti s seznama ali prikaz pogovornega okna bi moralo 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šajo ž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 dodeljevanja in odvoza smeti opazni.

Potek dela za prepoznavanje in odpravljanje težav z zmogljivostjo

Da se ne bi zanašali na srečo, je zelo koristno vzpostaviti sistematičen potek dela za analizo uspešnostiTa pristop združuje podrobno ročno testiranje v laboratoriju z zbiranjem zbirnih metrik v produkciji. Tipičen pristop vključuje te korake:

Najprej moramo identificirati ključne uporabniške potiTo pomeni, tokovi, 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 izvajajo in analizirajo z uporabo orodja za profiliranje in sledenje kot sta Perfetto ali Systrace, da z natančnostjo mikrosekund vidite, kaj naprava počne, generatorji profilov pomnilnika za zaznavanje puščanj in vročih točk dodeljevanja ali orodja, kot je Simpleperf, da ugotovite, katere funkcije porabijo največ procesorja.

Pomembno je poudariti, da je potrebna podrobna analiza uspešnosti odpravljanje napak posameznih izvedb Te poti se nadzorovano replicirajo, s čimer se reproducirajo težave. Analiza agregiranih podatkov je dragocena za odkrivanje vzorcev in regresij, vendar ne nadomešča poglobljene analize specifičnih sledi.

Hkrati je priporočljivo konfigurirati Neprekinjeno zbiranje meritev V avtomatiziranih testnih in produkcijskih okoljih: časi zagona, razmerja blokiranja, metrike sličic (npr. prek FrameMetricsAggregatorja v sistemu Android), metrike polj v konzoli Play, primerjalne vrednosti makrov 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 uspešnosti v nerealnih pogojih. Da bi bili rezultati uporabni, je potrebno konfigurirajte tako APK kot sistem previdno, pri čemer zagotovite, da je testno okolje podobno produkcijskemu, vendar nadzorujte šum.

Na strani aplikacije je bistveno ne meri v razhroščevalnih različicahRazličice za odpravljanje napak dodajo preverjanja, dnevnike in zastavice, ki znatno spremenijo čas izvajanja. V sistemu Android 10+ je mogoče uporabiti atribut profileable android:shell=»true« v manifestu, da se omogoči profiliranje v izdajnih različicah in ohrani vedenje blizu dejanskemu.

Priporočljivo je tudi uporabiti zmanjšanje kode Produkcijska okolja (ProGuard, R8 itd.) so pomembna, saj lahko velikost in organizacija kode povzročita opazne razlike v zmogljivosti. Vendar je ključnega pomena pregledati pravila: nekatere konfiguracije lahko odpravijo pomembne točke spremljanja, kar zahteva prilagoditve za testno okolje.

Kar zadeva prevajanje, je vredno aplikacijo spraviti v znano stanje, običajno in jasno v način hitrost o profil hitrostiOboje zmanjša količino kode, interpretirane iz DeX-a, in potrebo po JIT prevajanju 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 (npr. osnovnih profilov).

Z vidika sistema je običajno, ko so potrebne meritve z zelo visoko natančnostjo (mikro-referenčne vrednosti) umerite napravoIzvajanje A/B primerjalnih testov na istem terminalu in različici operacijskega sistema, nastavljanje frekvenc CPU/GPU, onemogočanje majhnih jeder ali omejevanje temperature s skripti, kot je lockClocks itd. To ne predstavlja resničnega sveta, vendar zmanjšuje šum za zelo specifične scenarije.

Za meritve, ki so bližje uporabniški izkušnji (čas zagona, poraba baterije, zrušitve uporabniškega vmesnika), je priporočljivo uporabiti ogrodja za testiranje, kot je Macrobenchmarkki 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čene stvari ponavljajoči se vzorci težav kar je vredno vedeti, saj običajno obstajajo precej jasne rešitve, če jih pravočasno odkrijemo.

Eden najpogostejših je Počasen zagon zaradi aktivnosti na trampolinuDo tega pride, ko se po zagonski nameri (ikona, obvestilo, globoka povezava) zažene vmesna aktivnost, ki ne nariše nobenih okvirjev, nato pa se začne »prava« aktivnost. Sledi prikazujejo 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.

Druga klasika so nepotrebne dodelitve, ki sprožijo zbiranje smetiČe profili Systrace ali pomnilnika prikazujejo cikle zbiranja smeti, ki se med dolgotrajno operacijo izvajajo vsakih nekaj sekund, je zelo verjetno, da obstaja koda, ki večkrat in dosledno dodeljuje objekte znotraj intenzivnih zank. Rešitev ni v tem, da se odpravi vsak nov stavek, temveč v tem, da se obravnavajo vroče točke, ponovna uporaba struktur ali uporaba vzorcev združevanja, kjer je to primerno.

Pogosto jih najdemo tudi okvirji z zamrznitvami v grafičnem cevovoduV zdravi sledi se klici funkcije Choreographer.doFrame() izvajajo z redno hitrostjo (npr. vsakih 16,7 ms). Povečava na območjih, kjer se ti klici izvajajo s to hitrostjo, lahko razkrije drage poglede, preveč zapletene postavitve, vhodno/izhodne operacije, ki se izvajajo v niti uporabniškega vmesnika, ali napačno konfigurirane elemente RecyclerView.

Natančneje, RecyclerView je vir številnih težav: razveljavitev celotnega nabora podatkov z notifyDataSetChanged(), ko se dejansko spremeni le nekaj elementov, nepravilna konfiguracija recikliranih pogledov v ugnezdenih RecyclerViews ali nedelovanje... predhodno pridobivanje podatkov To je dovolj, ko je dosežen konec seznama. Vse to povzroči drago upodabljanje, skoke pri pomikanju in vidne čakalne čase za uporabnika.

Testiranje zmogljivosti: vrste, koraki in najboljše prakse

Poleg spremljanja proizvodnje vsaka resna strategija potrebuje trden načrt testiranje delovanja aplikacij v nadzorovanih okoljih. Ti testi nam omogočajo, da preverimo zmogljivost, stabilnost in skalabilnost, preden uporabnike izpostavimo 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 analiza zahtevRazumevanje, kateri odzivni časi, razmerja pretočnosti, ravni razpoložljivosti ali omejitve napak so sprejemljive za podjetje. Nato faza načrtovanje in strategija ki opredeljuje obseg testov, okolje, orodja in metrike, ki bodo spremljane.

Naslednje so zasnovane testni primeri Zajema 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 analizaTo vključuje korelacijo odzivnih časov z porabo procesorja, omrežnih zakasnitev s stopnjami napak, prometnih konic s preobremenitvami baze podatkov itd. Po dokumentiranju ugotovitev v jasnih poročilih za deležnike se postopek nadaljuje ... optimizacija in ponovno testiranjeKoda, konfiguracije ali viri se prilagodijo, testi pa se ponavljajo, dokler se ne potrdi, da izboljšave začnejo veljati.

Orodja in ogrodja za testiranje zmogljivosti

Za uresničitev vsega zgoraj navedenega se je treba zanašati na orodja za testiranje zmogljivosti Specifično, tako odprtokodno kot komercialno, ki zajema avtomatizacijo, ustvarjanje obremenitve, spremljanje in analitiko. 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 enega ali drugega je priporočljivo upoštevati dejavnike, kot so Enostavnost uporabe, podpora za protokole in tehnologije, skalabilnost, integracija s CI/CDPomembni dejavniki so tudi model licenciranja, razširljivost in kakovost podpore (podpora skupnosti ali komercialna podpora). Ni neobičajno, da se jih združi več: eden za ustvarjanje obremenitve, drugi za APM in tretji za opazovanje infrastrukture.

Skratka, analiziranje in spremljanje delovanja aplikacij zahteva kombinacijo dobro izbranih metrik, ustreznih orodij in discipliniranih procesov testiranja, vendar rezultati več kot nadomestijo: hitrejše, stabilnejše in učinkovitejše aplikacijeBolj zadovoljni uporabniki, manj proizvodnih incidentov in seveda neposreden pozitiven vpliv na ugled blagovne znamke in prihodke.

Povezani članek:

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