Analiza e performancës së aplikacionit: metrika, testimi dhe monitorimi

Informatec Digital » Burime » Analiza e performancës së aplikacionit: metrika, testimi dhe monitorimi

Për të arritur atë nivel cilësie, nuk mjafton të "testosh pak para publikimit". Kërkon një kombinim faktorësh. monitorim i vazhdueshëm (APM dhe RUM)Testet e performancës të hartuara mirë, metrika të qarta dhe mjetet e afta për të simuluar gjithçka, nga përdorimi i përditshëm deri te rritjet ekstreme të trafikut, janë thelbësore. Dhe, për më tepër, kjo duhet të bëhet në mënyrë strategjike: duke matur atë që ka vërtet rëndësi për biznesin dhe duke automatizuar sa më shumë që të jetë e mundur për të shmangur reagimin e vazhdueshëm ndaj problemeve.

Performanca e aplikacionit: çfarë është, pse ka rëndësi dhe çfarë masim

Kur flasim për performancën e aplikacionit, i referohemi aftësia e një aplikacioni për t'u përgjigjur shpejt, për të qenë i qëndrueshëm dhe për t'u shkallëzuar kur numri i përdoruesve ose vëllimi i të dhënave rritet, pa rritur konsumin e burimeve ose pa prishur përvojën e përdoruesit. Kjo vlen për aplikacione për celularë, ueb dhe desktopAPI-të, mikroshërbimet ose sistemet komplekse të ndërmarrjeve.

Çelësi është të matet sistematikisht një seri metrika të performancës së aplikacionit (KPI) që na lejojnë të kuptojmë nëse aplikacioni po i përmbush objektivat teknikë dhe të biznesit, si dhe të zbulojmë në kohë kur diçka fillon të shkojë keq, përpara se përdoruesi përfundimtar ta vërejë ose përpara se të bien alarmet gjatë prodhimit.

Ndër metrikat më të zakonshme të përdorura për të vlerësuar performancën e aplikacionit janë:

• Përdorimi i CPU-së: sa procesor konsumon aplikacioni dhe nëse ka rritje të papritura që zbulojnë llogaritje të tepërta, sythe të projektuara dobët ose procese që bllokojnë përgjigjen.
• përdorimin e kujtesës: vëllimi i memories së zënë, shfaqja e rrjedhjeve, defektet e faqes ose hiperfaqëzimi që tregojnë se sistemi shpenzon më shumë kohë duke zhvendosur të dhëna sesa duke ekzekutuar logjikën e biznesit.
• Kërkesa për minutë dhe bajt për kërkesëKjo tregon se sa kërkesa përpunon aplikacioni ose API-ja dhe sa të dhëna trajton në secilën kërkesë. Ndihmon të shihet se si shkallëzohet backend-i dhe nëse vëllimi i të dhënave për thirrje është i arsyeshëm.
• Vonesa dhe koha e reagimitsa kohë i duhet aplikacionit për t'u përgjigjur, nga momenti kur përdoruesi kryen një veprim ose klienti dërgon një kërkesë deri në marrjen e një përgjigjeje të dobishme.
• Koha e funksionimit dhe disponueshmëria: përqindja e kohës që shërbimi është aktiv dhe në funksionim, zakonisht monitorohet me ping-e të përsëritura ose kontrolle sintetike.
• Shkalla e gabimit: përqindja e kërkesave që përfundojnë me gabim (kodet HTTP 4xx/5xx, përjashtimet e patrajtuara, dështimet funksionale).
• Rezultati i Apdex dhe kënaqësia e përdoruesitindeks që përmbledh, në një vlerë të vetme, përqindjen e përdoruesve të kënaqur, tolerantë ose të frustruar bazuar në kohën e përgjigjes.
• Performanca e mbledhjes së mbeturinave (GC)Në platformat me menaxhim automatik të memories (Java, .NET, Android), sa kohë shpenzohet në GC, sa pauza sjell dhe si ndikon kjo në përdorimin dhe rrjedhshmërinë e CPU-së.
• Shkalla e përpunimit ose performanca: numri i transaksioneve ose kërkesave të përpunuara për njësi të kohës, kritik në sisteme me konkurrueshmëri të lartë.

Qëllimi i ndjekjes së këtyre metrikave nuk është mbledhja e grafikëve: është të kuptojë gjendjen aktuale të aplikacionit, parashikojnë pengesat, përcaktojnë përparësitë e përmirësimeve dhe demonstrojnë, me anë të të dhënave, se optimizimet kanë ndikim si në përvojën e përdoruesit ashtu edhe në rezultatet e biznesit.

Monitorimi i performancës APM, RUM dhe në kohë reale

Në mjediset moderne, me arkitektura të shpërndara, kontejnerë, re hibride dhe mikroshërbime, është praktikisht e pamundur të kontrollosh performancën pa një... mjet monitorimi i performancës së aplikacionit (APM) të kombinuara me teknikat e monitorimit të përdoruesit real (RUM) dhe, gjithnjë e më shumë, me komponentë të vëzhgueshmërisë së avancuar.

Zgjidhjet APM/RUM (si ato nga Elastic, Instana, Applications Manager, Turbonomic të integruara me APM, etj.) ofrojnë dukshmëri nga fillimi në fund të asaj që ndodh në aplikacionin tuaj: kohët e reagimit, gjurmët e shpërndara, pyetjet në bazën e të dhënave, thirrjet e jashtme, gabimet dhe anomalitë, të integruara me metrikat e infrastrukturës.

El Monitorimi i vërtetë i përdoruesit (RUM) Ai kap atë që shohin përdoruesit realë: kohët e ngarkimit të ekranit, ngrirjet e ndërfaqes, gabimet e shfletuesit ose të aplikacionit celular dhe vonesën e perceptuar në rajone dhe pajisje të ndryshme. Kjo plotëson testet sintetike dhe testet laboratorike, të cilat janë thelbësore, por nuk zëvendësojnë të dhënat e botës reale.

Platformat moderne APM, nga ana tjetër, ofrojnë veçori të tilla si:

• Monitorimi në kohë reale KPI-të kryesore: disponueshmëria, Apdex, shkalla e gabimeve, shpejtësia e transferimit, Konsumi i burimeve.
• Gjurmët e shpërndara për të ndjekur një transaksion nëpër mikroshërbime të shumta, radhë, baza të dhënash dhe shërbime të jashtme, duke identifikuar lidhjen më të ngadaltë.
• Hartat e varësisë Mjete të automatizuara që tregojnë se si lidhen shërbimet, bazat e të dhënave, radhët dhe frontend-et, duke e bërë më të lehtë zbulimin e shkakut rrënjësor të një dështimi.
• Profilizimi i kodit dhe fijeve për të gjetur metoda, pyetje SQL ose seksione të kodit që konsumojnë shumë CPU ose bllokojnë fijen e ndërfaqes.
• Alarme inteligjente dhe AIOps që kombinojnë të mësuarit automatik dhe analizën e serive kohore për të zbuluar anomalitë, për të zvogëluar alarmet e rreme dhe për të përcaktuar përparësitë e incidenteve kritike.

Kombinimi i APM, RUM dhe monitorimit sintetik rezulton në një Shikueshmëri 360° e performancësKjo ofron një pasqyrë të asaj që përdoruesi sheh, çfarë bën aplikacioni në mënyrë të brendshme dhe si reagon infrastruktura themelore. Kjo u lejon ekipeve DevOps dhe ITOps të reagojnë shpejt ndaj incidenteve dhe, akoma më mirë, t'i parandalojnë ato.

Metrikat kryesore të performancës në aplikacionet mobile dhe web

Në aplikacionet mobile dhe në internet, disa metrika të performancës janë veçanërisht të ndjeshme sepse ndikojnë drejtpërdrejt në perceptimin e përdoruesit dhe suksesin e produktit. Monitorimi i ngushtë i këtyre treguesve bën ndryshimin midis një aplikacioni që i magjeps përdoruesit dhe një aplikacioni që çinstalohet pas përdorimit të dytë.

Një nga pikat kritike në celular është vonesa e nisjes së aplikacionitDomethënë, koha që kalon nga momenti kur përdoruesi prek ikonën (ose një njoftim) derisa të shohë të dhëna të dobishme në ekran. Dallohen disa lloje:

• Nisje e ftohtëAplikacioni nuk është në kujtesë; sistemi duhet të krijojë një proces, të ngarkojë kodin, të inicializojë bibliotekat dhe të shfaqë ekranin e parë.
• Nisje gjysmë e ngrohtëProcesi ekziston, por aktiviteti rikrijohet ose rikthehet në një gjendje të caktuar.
• Nisje e nxehtë: thjesht duhet ta ringritësh pamjen tënde ose të rifillosh aktivitetin, me shumë pak punë shtesë.

Si referencë, rekomandohet fuqimisht të synohet fillime të ftohta nën 500 ms Meqenëse vonesat p95 dhe p99 (percentilet më të larta) janë afër mesatares, nëse disa përdorues presin disa sekonda ndërsa të tjerët e hapin aplikacionin brenda gjysmë sekonde, diçka nuk është në ekuilibër.

Një aspekt tjetër kritik është lëvizja dhe kyçja e ndërfaqesNë ekranet që lëvizin (burime, lista, galeri), përdoruesit presin rrjedhshmëri të përsosur. Kur sistemi dështon të gjenerojë kuadro me shpejtësinë e rifreskimit të pajisjes (60 Hz, 90 Hz ose edhe 120 Hz), ndodhin bllokime dhe ngecje. Këto "ngecje" ndodhin kur aplikacionit i duhet më shumë kohë se kohëzgjatja e një kuadroje (për shembull, më shumë se 16,7 ms në 60 FPS) për të paraqitur përmbajtjen.

Përveç rrjedhshmërisë, është e nevojshme të monitorohet edhe tranzicionet midis ekraneveNdërrimi i skedave, hapja e detajeve nga një listë ose shfaqja e një dialogu duhet të jenë gjeste praktikisht të menjëhershme, me animacione të lëmuara dhe pa dridhje ose ekrane bosh të zgjatur.

Në sfond, por po aq të rëndësishëm, është konsumi i baterisë dhe efikasiteti i energjisë. Detyra të panevojshme, alokime masive të memories dhe përdorim intensiv të CPU-së Ato zvogëlojnë jetëgjatësinë e baterisë dhe shkaktojnë mbinxehjen e pajisjes. Android Runtime (ART) ka përmirësuar efikasitetin, por nëse cikli i brendshëm i aplikacionit tuaj po krijon mijëra objekte të reja në sekondë, kostot e ndarjes dhe mbledhjes së mbeturinave do të jenë të dukshme.

Fluksi i punës për identifikimin dhe korrigjimin e problemeve të performancës

Për të shmangur mbështetjen te fati, është shumë e dobishme të krijoni një rrjedha e punës së analizës sistematike të performancësKjo qasje kombinon testimin manual të detajuar në një laborator me mbledhjen e metrikave të agreguara në prodhim. Një qasje tipike përfshin këto hapa:

Së pari, duhet të identifikojmë udhëtimet kritike të përdoruesitDomethënë, flukset që kanë ndikimin më të madh në përvojë dhe biznes:

• Lançime të shpeshta të aplikacioneve (ikona, njoftime, lidhje të thella).
• Ekrane me lëvizje të vazhdueshme mbi sasi të mëdha të dhënash.
• Kalimet kryesore midis pamjeve dhe aktiviteteve.
• Flukse të gjata si shfletimi, luajtja e audios/videos, arkëtimet, etj.

Pasi të përcaktohen, ato zbatohen dhe analizohen duke përdorur mjetet e profilizimit dhe gjurmimit si Perfetto ose Systrace për të parë se çfarë po bën pajisja me precizion mikrosekondash, gjeneratorë të profileve të memories për të zbuluar rrjedhjet dhe pikat e nxehta të alokimit, ose mjete si Simpleperf për të zbuluar se cilat funksione konsumojnë më shumë CPU-në.

Është e rëndësishme të theksohet se një analizë e hollësishme e performancës kërkon debugoni ekzekutimet individuale Këto rrugë replikohen në një mënyrë të kontrolluar, duke riprodhuar problemet. Analiza e të dhënave agregate është e vlefshme për zbulimin e modeleve dhe regresioneve, por nuk zëvendëson analizën e thelluar të gjurmëve specifike.

Në të njëjtën kohë, këshillohet të konfiguroni Mbledhja e vazhdueshme e metrikave Në mjediset e testimit dhe prodhimit të automatizuar: kohët e nisjes, raportet e bllokimit, metrikat e kuadrove (p.sh., nëpërmjet FrameMetricsAggregator në Android), metrikat e fushës së Play Console, makro-pikat referuese të lëvizjes, etj. Këto metrika ju lejojnë të shihni ndryshueshmërinë reale midis pajisjeve, versioneve të sistemit operativ dhe kushteve të rrjetit.

Cilësimet e aplikacionit dhe sistemit për matje të sakta

Një nga grackat më të zakonshme është matja e performancës në kushte joreale. Që rezultatet të jenë të dobishme, është e nevojshme konfiguroni si APK-në ashtu edhe sistemin me kujdes, duke u siguruar që mjedisi i testimit i ngjan prodhimit, por duke kontrolluar zhurmën.

Nga ana e aplikacionit, është thelbësore mos mat në ndërtimet e debugimitVariantet e debugimit shtojnë kontrolle, regjistra dhe flamuj që ndryshojnë ndjeshëm kohët e ekzekutimit. Në Android 10+, është e mundur të përdoret atributi android i profilueshëm: shell=»i vërtetë» në manifest për të aktivizuar profilizimin në versionet e versioneve, duke ruajtur sjelljen afër asaj reale.

Gjithashtu këshillohet të përdoret reduktimi i kodit Mjediset e prodhimit (ProGuard, R8, etj.) janë të rëndësishme, pasi madhësia dhe organizimi i kodit mund të çojnë në ndryshime të dukshme në performancë. Megjithatë, është thelbësore të rishikohen rregullat: disa konfigurime mund të eliminojnë pika të rëndësishme monitorimi, duke kërkuar rregullime për mjedisin e testimit.

Lidhur me kompilimin, ia vlen ta çoni aplikacionin në një gjendje të njohur, zakonisht dhe qartësisht në modalitetin shpejtësi o profili i shpejtësisëTë dyja zvogëlojnë sasinë e kodit të interpretuar nga DeX dhe nevojën për përpilimin e JIT në sfond, gjë që stabilizon rezultatet. Modaliteti i profilit të shpejtësisë përpiqet të ngjajë më shumë me sjelljen e prodhimit në botën reale, por kërkon ngrohjen e aplikacionit dhe menaxhimin e profileve (p.sh., Profilet Bazë).

Nga pikëpamja e sistemit, kur nevojiten matje me saktësi shumë të lartë (mikro-standarde), është e zakonshme kalibroni pajisjenEkzekutimi i testeve A/B në të njëjtin terminal dhe version të sistemit operativ, caktimi i frekuencave të CPU/GPU, çaktivizimi i bërthamave të vogla ose kufizimi termik me skripte si lockClocks, etj. Kjo nuk përfaqëson botën reale, por zvogëlon zhurmën për skenarë shumë specifikë.

Për matje më afër përvojës së përdoruesit (koha e nisjes, konsumi i baterisë, rrëzimi i ndërfaqes së përdoruesit) rekomandohet të përdoret korniza testimi si Macrobenchmarktë cilat automatizojnë shumë nga këto hapa dhe shmangin gabimet delikate por kritike të konfigurimit.

Modele tipike të problemeve të performancës

Në pothuajse të gjitha aplikacionet që analizohen plotësisht, shfaqen disa gjëra të caktuara modele të përsëritura të problemeve gjë që ia vlen ta dish, sepse zakonisht ka zgjidhje mjaft të qarta nëse zbulohen në kohë.

Një nga më të zakonshmet është Nisje e ngadaltë për shkak të aktivitetit të trampolinësKjo ndodh kur, pas një qëllimi nisjeje (ikonë, njoftim, lidhje e thellë), niset një aktivitet i ndërmjetëm që nuk tërheq asnjë kornizë, dhe më pas fillon aktiviteti "real". Gjurmët tregojnë dy ngjarje të njëpasnjëshme `activityStart` pa punë vizuale midis tyre. Ky "kërcim" shton vonesën e nisjes pa ofruar ndonjë vlerë. Zgjidhja zakonisht përfshin rifaktorizimin e inicializimit në një komponent të ripërdorshëm ose integrimin e tij direkt në aktivitetin kryesor.

Një tjetër klasik janë ndarje të panevojshme që shkaktojnë mbledhjen e mbeturinaveNëse një Systrace ose profile memorieje tregojnë cikle mbledhjeje të mbeturinave që ekzekutohen çdo disa sekonda gjatë një operacioni të gjatë, ka shumë të ngjarë që të ketë kod që ndan objekte në mënyrë të përsëritur dhe të vazhdueshme brenda sytheve intensive. Zgjidhja nuk është të eliminohet çdo deklaratë e re, por të adresohen pikat e nxehta, duke ripërdorur strukturat ose duke aplikuar modele grumbullimi aty ku është e përshtatshme.

Ato gjenden gjithashtu shpesh korniza me ngrirje në rrjedhën e grafikësNë një gjurmim të shëndetshëm, thirrjet në Choreographer.doFrame() ndodhin me një ritëm të rregullt (p.sh., çdo 16,7 ms). Zmadhimi në zonat ku këto thirrje ndodhin me atë ritëm mund të zbulojë pamje të kushtueshme, paraqitje tepër komplekse, operacione I/O që ekzekutohen në fijen e ndërfaqes së përdoruesit ose RecyclerViews të konfiguruara gabimisht.

Në mënyrë specifike, RecyclerView është burimi i problemeve të shumta: pavlefshmëria e të gjithë të dhënave me notifyDataSetChanged() kur vetëm disa elementë ndryshojnë në të vërtetë, moskonfigurimi siç duhet i grupeve të pamjeve të ricikluara në RecyclerViews të ndërthurura, ose mosfunksionimi i tyre. para-kërkimi i të dhënave Kjo është e mjaftueshme kur arrihet fundi i listës. E gjithë kjo rezulton në renderim të kushtueshëm, vonesa në rrotullim dhe kohë pritjeje të dukshme për përdoruesin.

Testimi i performancës: llojet, hapat dhe praktikat më të mira

Përtej monitorimit të prodhimit, çdo strategji serioze ka nevojë për një plan të fortë të testimi i performancës së aplikacionit në mjedise të kontrolluara. Këto teste na lejojnë të vërtetojmë kapacitetin, stabilitetin dhe shkallëzueshmërinë përpara se t'i ekspozojmë përdoruesit ndaj ndryshimeve ose versioneve të reja.

Ekzistojnë disa lloje testesh, secila me objektivin e vet specifik:

• Testet e ngarkesësAta vlerësojnë sjelljen e aplikacionit nën një ngarkesë të parashikuar përdoruesish ose transaksionesh, duke matur kohën e reagimit, rendimentin dhe konsumin e burimeve për të zbuluar pengesat para vendosjes.
• Testet e stresitAta e shtyjnë sistemin përtej kufijve të tij normalë për të parë se sa larg mund të shtyhet, si dështon dhe si rikuperohet. Ato janë thelbësore për planifikimin e kapaciteteve dhe menaxhimin e kulmeve të tipit Black Friday.
• Testet e qëndrueshmërisë/zhytjesAto mbajnë një ngarkesë të qëndrueshme për orë të tëra ose ditë për të zbuluar problemet e degradimit të ngadaltë, rrjedhjeve të kujtesës ose shterimit të burimeve.
• Testet e pikutAto simulojnë rritje të papritura dhe të përsëritura të ngarkesës (p.sh., fushata, lançime veçorish, transmetime të drejtpërdrejta) për të verifikuar që aplikacioni dhe infrastruktura mund të përballojnë ndryshime të papritura.
• Testet e vëllimitAta analizojnë se si sillet aplikacioni kur numri i përdoruesve rritet ndjeshëm. sasia e të dhënave (madhësia e bazës së të dhënave, skedarët, mesazhet), validimi i kohës së përgjigjes, besueshmëria e ruajtjes dhe humbja e të dhënave.
• Testet e shkallëzueshmërisëAta kontrollojnë se si përgjigjet aplikacioni kur ngarkesa rritet gradualisht dhe nëse shkallëzimi horizontal apo vertikal prodhon përmirësimin e pritur të performancës.

Procesi tipik i testimit të performancës përfshin disa faza të dallueshme. Së pari, një analiza e kërkesaveTë kuptuarit se cilat kohë përgjigjeje, raporte të xhiros, nivele të disponueshmërisë ose kufij gabimesh janë të pranueshme për biznesin. Pastaj, një fazë e planifikimi dhe strategjia i cili përcakton fushëveprimin e testeve, mjedisin, mjetet dhe metrikat që do të monitorohen.

Më poshtë janë projektuar raste testimi Duke mbuluar skenarë të ndryshëm të ngarkesës, kushte të rrjetit dhe vëllime të të dhënave, konfigurohet mjedisi i testimit (hardware, software, rrjet, injektimi i ngarkesës dhe mjetet e monitorimit) dhe testet ekzekutohen, duke mbledhur me kujdes të dhënat e performancës.

Faza kritike është monitorim dhe analizëKjo përfshin korrelacionin e kohëve të reagimit me përdorimin e CPU-së, vonesat e rrjetit me shkallët e gabimeve, rritjet e trafikut me mbingarkesat e bazës së të dhënave, etj. Pas dokumentimit të gjetjeve në raporte të qarta për palët e interesuara, procesi vazhdon me... optimizimi dhe ritestimiKodi, konfigurimet ose burimet përshtaten dhe testet përsëriten derisa të vërtetohet se përmirësimet hyjnë në fuqi.

Mjete dhe korniza për testimin e performancës

Për të vënë në praktikë të gjitha sa më sipër, është e nevojshme të mbështeteni në mjetet e testimit të performancës Specifike, si me burim të hapur ashtu edhe komerciale, që mbulojnë automatizimin, gjenerimin e ngarkesës, monitorimin dhe analizat. Disa kategori relevante janë:

• Mjete me burim të hapurProjekte të tilla si Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder, ose kornizat e testimit të njësive dhe funksionale (JUnit, XCTest, Appium) që janë zgjeruar me skenarë të performancës lejojnë ndërtimin e grupeve shumë të fuqishme të testimit me kosto të ulëta licencimi.
• Testimi i ngarkesës komerciale dhe mjetet APMZgjidhje të tilla si WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest ose Parasoft ofrojnë mjedise të integruara me gjenerim ngarkese të bazuar në cloud, raportim të avancuar dhe mbështetje profesionale.
• Zgjidhje të specializuara dhe të vëzhgueshmeProdukte të tilla si Applications Manager, Instana, Dynatrace, IBM Turbonomic ose platforma monitorimi të rrjetit si SolarWinds, të cilat përqendrohen në monitorimin e vazhdueshëm, zbulimin e anomalive dhe korrelacionin midis performancës së aplikacionit, infrastrukturës dhe përvojës së përdoruesit.
• Mjete specifike për platformënNë rastin e Android-it, për shembull, mjete të tilla si Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace ose metrika e kuadrit të Play Console, lejojnë analiza shumë të imëta të sjelljes në nivel sistemi.

Kur zgjidhni njërën ose tjetrën, është e këshillueshme të merren në konsideratë faktorë të tillë si Lehtësi përdorimi, mbështetje për protokollet dhe teknologjitë, shkallëzueshmëri, integrim me CI/CDModeli i licencimit, zgjerueshmëria dhe cilësia e mbështetjes (mbështetje nga komuniteti ose komerciale) janë gjithashtu faktorë të rëndësishëm. Nuk është e pazakontë të kombinohen disa: një për gjenerimin e ngarkesës, një tjetër për APM dhe një tjetër për vëzhgueshmërinë e infrastrukturës.

Shkurt, analizimi dhe monitorimi i performancës së aplikacionit kërkon një kombinim të metrikave të zgjedhura mirë, mjeteve të përshtatshme dhe proceseve të disiplinuara të testimit, por rezultatet e kompensojnë më shumë se sa: aplikacione më të shpejta, më të qëndrueshme dhe më efikasePërdorues më të kënaqur, më pak incidente prodhimi dhe sigurisht, një ndikim pozitiv i drejtpërdrejtë në reputacionin dhe të ardhurat e markës.

Artikuj të ngjashëm:

Zbuloni Qt Creator IDE: Mjedisi më i fuqishëm për krijimin e aplikacioneve ndërplatformë