Lietojumprogrammu veiktspējas analīze: metrika, testēšana un uzraudzība

Informatec Digital » Resursi » Lietojumprogrammu veiktspējas analīze: metrika, testēšana un uzraudzība

Lai sasniegtu šādu kvalitātes līmeni, nepietiek tikai ar "nedaudz testēt pirms publicēšanas". Tas prasa nepārtrauktas uzraudzības (APM un RUM) kombināciju , labi izstrādātus veiktspējas testus, skaidrus rādītājus un rīkus, kas spēj simulēt visu, sākot no ikdienas lietošanas līdz ārkārtējiem datplūsmas pieaugumiem. Turklāt tas jādara stratēģiski: mērot to, kas patiešām ir svarīgs uzņēmumam, un pēc iespējas automatizējot, lai izvairītos no pastāvīgas reaģēšanas uz problēmām.

Lietojumprogrammu veiktspēja: kas tā ir, kāpēc tā ir svarīga un ko mēs mērām

Runājot par lietojumprogrammu veiktspēju, mēs domājam lietotnes spēju ātri reaģēt, saglabāt stabilitāti un mērogoties , palielinoties lietotāju skaitam vai datu apjomam, būtiski nepalielinot resursu patēriņu vai neapdraudot lietotāja pieredzi. Tas attiecas uz mobilajām, tīmekļa un darbvirsmas lietojumprogrammām , API, mikropakalpojumiem un sarežģītām uzņēmumu sistēmām.

Svarīgākais ir sistemātiski mērīt virkni lietojumprogrammu veiktspējas rādītāju (KPI) , kas ļauj saprast, vai lietotne sasniedz tehniskos un biznesa mērķus, un laikus noteikt, kad kaut kas sāk noiet greizi, pirms gala lietotājs to pamana vai ražošanas vidē ieslēdzas trauksmes signāli.

Starp visbiežāk izmantotajiem rādītājiem, ko izmanto lietotņu veiktspējas novērtēšanai, ir:

• Procesora izmantošana: cik daudz procesora patērē lietojumprogramma un vai ir palielinājumi, kas atklāj pārmērīgus aprēķinus, slikti izstrādātus ciklus vai procesus, kas bloķē atbildi.
• atmiņas lietojumsAizņemtā atmiņas apjoms, noplūžu, lapu kļūmju vai hiperlapošanas parādīšanās, kas norāda, ka sistēma vairāk laika pavada datu pārvietošanai nekā biznesa loģikas izpildei.
• Pieprasījumu skaits minūtē un baiti vienā pieprasījumāTas parāda, cik pieprasījumu lietotne vai API apstrādā un cik daudz datu tā apstrādā katrā pieprasījumā. Tas palīdz redzēt, kā aizmugursistēma mērogojas un vai datu apjoms katrā izsaukumā ir saprātīgs.
• Latentums un reakcijas laiks: cik ilgs laiks nepieciešams lietojumprogrammai, lai atbildētu, sākot no brīža, kad lietotājs veic darbību vai klients nosūta pieprasījumu, līdz brīdim, kad tiek saņemta noderīga atbilde.
• Darbības laiks un pieejamība: pakalpojuma darbības laika procentuālā daļa, ko parasti uzrauga ar atkārtotiem pingiem vai sintētiskām pārbaudēm.
• Kļūdu līmenis: to pieprasījumu īpatsvars, kas beidzas ar kļūdu (HTTP 4xx/5xx kodi, neapstrādāti izņēmumi, funkcionālas kļūmes).
• Apdex vērtējums un lietotāju apmierinātība: indekss, kas vienā vērtībā apkopo apmierināto, toleranto vai neapmierināto lietotāju procentuālo daļu, pamatojoties uz atbildes laikiem.
• Atkritumu savākšanas veiktspēja (GC)Platformās ar automātisku atmiņas pārvaldību (Java, .NET, Android), cik daudz laika tiek pavadīts GC, cik pauzes tas ievieš un kā tas ietekmē centrālā procesora noslodzi un plūstamību.
• Caurlaidspēja vai veiktspēja: apstrādāto darījumu vai pieprasījumu skaits laika vienībā, kas ir kritiski svarīgs sistēmās ar augstu vienlaicīgumu.

Šo rādītāju izsekošanas mērķis nav apkopot grafikus: tas ir izprast lietojumprogrammas faktisko stāvokli , paredzēt vājās vietas, noteikt prioritātes uzlabojumiem un ar datu palīdzību parādīt, ka optimizācijai ir ietekme gan uz lietotāja pieredzi, gan biznesa rezultātiem.

APM, RUM un reāllaika veiktspējas uzraudzība

Mūsdienu vidē ar izkliedētām arhitektūrām, konteineriem, hibrīdiem mākoņiem un mikropakalpojumiem praktiski nav iespējams kontrolēt veiktspēju bez laba lietojumprogrammu veiktspējas uzraudzības (APM) rīka apvienojumā ar reālu lietotāju uzraudzības (RUM) metodēm un arvien vairāk uzlabotiem novērojamības komponentiem.

APM/RUM risinājumi (piemēram, Elastic, Instana, Applications Manager, Turbonomic risinājumi, kas integrēti ar APM u. c.) nodrošina pilnīgu pārskatāmību par to, kas notiek jūsu lietojumprogrammā: atbildes laiki, izkliedētās izsekošanas, datubāzes vaicājumi, ārējie izsaukumi, kļūdas un anomālijas, kas integrētas ar infrastruktūras rādītājiem.

Reālo lietotāju uzraudzība (RUM) fiksē to, ko redz reāli lietotāji: ekrāna ielādes laikus, saskarnes sasalšanu, pārlūkprogrammas vai mobilās lietotnes kļūdas un uztverto latentumu dažādos reģionos un ierīcēs. Tas papildina sintētiskos etalonus un laboratorijas testus, kas ir būtiski, taču neaizstāj reālās pasaules datus.

No otras puses, mūsdienu APM platformas piedāvā tādas funkcijas kā:

• Reāllaika uzraudzība Galvenie KPI: pieejamība, Apdex, kļūdu līmenis, pārsūtīšanas ātrums, Resursu patēriņš.
• Izplatītie trasējumi lai izsekotu darījumu vairākos mikropakalpojumos, rindās, datubāzēs un ārējos pakalpojumos, identificējot lēnāko saiti.
• Atkarību kartes Automatizēti rīki, kas parāda, kā pakalpojumi, datubāzes, rindas un front-end sistēmas ir saistītas, tādējādi atvieglojot kļūmes pamatcēloņa noteikšanu.
• Koda un pavedienu profilēšana lai atrastu metodes, SQL vaicājumus vai koda sadaļas, kas patērē pārāk daudz centrālā procesora jaudas vai bloķē saskarnes pavedienu.
• Viedie brīdinājumi un mākslīgā intelekta (AIOps) funkcijas kas apvieno mašīnmācīšanos un laika rindu analīzi, lai atklātu anomālijas, samazinātu viltus trauksmes un noteiktu prioritātes kritiskiem incidentiem.

Apvienojot APM, RUM un sintētisko uzraudzību, jūs iegūstat 360 grādu pārskatu par veiktspēju : ko redz lietotājs, ko lietojumprogramma dara iekšēji un kā reaģē pamatā esošā infrastruktūra. Tas ļauj DevOps un ITOps komandām ātri reaģēt uz incidentiem un, vēl labāk, tos novērst.

Galvenie veiktspējas rādītāji mobilajās un tīmekļa lietojumprogrammās

Mobilajās un tīmekļa lietojumprogrammās noteikti veiktspējas rādītāji ir īpaši jutīgi, jo tie tieši ietekmē lietotāju uztveri un produkta panākumus. Šo rādītāju rūpīga uzraudzība nosaka, vai lietotne piesaista lietotāju uzmanību, vai tā tiek atinstalēta pēc otrās lietošanas reizes.

Viens no kritiskajiem punktiem mobilajās ierīcēs ir lietojumprogrammu palaišanas latentums , tas ir, laiks, kas paiet no brīža, kad lietotājs pieskaras ikonai (vai paziņojumam), līdz brīdim, kad viņš ekrānā redz noderīgus datus. Var izšķirt vairākus veidus:

• Aukstā iedarbināšanaLietotne neatrodas atmiņā; sistēmai ir jāizveido process, jāielādē kods, jāinicializē bibliotēkas un jāparāda pirmais ekrāns.
• Pussilts startsProcess pastāv, bet darbība tiek atjaunota vai atjaunota līdz noteiktam stāvoklim.
• Karstā palaišanaJums tikai jāpalielina skats vai jāatsāk aktivitāte ar ļoti nelielu papildu darbu.

Kā atsauci, ļoti ieteicams censties panākt aukstās palaišanas laiku zem 500 ms, jo tas pietuvinās p95 un p99 latentumu (augstākās procentiles) mediānai. Ja daži lietotāji gaida vairākas sekundes, bet citi atver lietotni pussekundē, kaut kas nav līdzsvarā.

Vēl viens kritisks aspekts ir ritināšana un saskarnes sasalšana . Kustīgos ekrānos (plūsmās, sarakstos, galerijās) lietotāji sagaida perfektu plūstamību. Ja sistēma nespēj ģenerēt kadrus ar ierīces atsvaidzes intensitāti (60 Hz, 90 Hz vai pat 120 Hz), rodas raustīšanās un aizķeršanās. Šīs "aizķeršanās" rodas, ja lietotnei satura renderēšanai nepieciešams ilgāks laiks nekā kadra ilgums (piemēram, vairāk nekā 16,7 ms ar 60 kadriem sekundē).

Papildus plūstamībai ir rūpīgi jāuzrauga arī ekrāna pārejas . Cilņu pārslēgšanai, informācijas atvēršanai no saraksta vai dialoglodziņa attēlošanai jānotiek praktiski acumirklī, ar vienmērīgām animācijām un bez mirgošanas vai ilgstošiem tukšiem ekrāniem.

Fonā, bet tikpat svarīgi, ir akumulatora patēriņš un energoefektivitāte. Nevajadzīgi uzdevumi, milzīga atmiņas piešķiršana un intensīva centrālā procesora izmantošana samazina akumulatora darbības laiku un izraisa ierīces pārkaršanu. Android Runtime (ART) ir uzlabojusi efektivitāti, taču, ja jūsu lietotnes iekšējā cilpa rada tūkstošiem jaunu objektu sekundē, piešķiršanas un atkritumu savākšanas izmaksas būs ievērojamas.

Darbplūsma veiktspējas problēmu identificēšanai un labošanai

Lai nepaļautos uz veiksmi, ir ļoti noderīgi izveidot sistemātisku veiktspējas analīzes darbplūsmu , kas apvieno detalizētu manuālu testēšanu laboratorijā ar apkopotu rādītāju vākšanu ražošanas vidē. Tipiska pieeja ietver šādas darbības:

Vispirms ir jāidentificē kritiskie lietotāju ceļojumi , proti, plūsmas, kurām ir vislielākā ietekme uz pieredzi un uzņēmējdarbību:

• Bieža lietotņu palaišana (ikona, paziņojumi, dziļās saites).
• Ekrāni ar nepārtrauktu ritināšanu pāri lielam datu apjomam.
• Galvenās pārejas starp skatiem un aktivitātēm.
• Garas darbības, piemēram, pārlūkošana, audio/video atskaņošana, norēķināšanās utt.

Kad tie ir definēti, tie tiek instrumentēti un analizēti, izmantojot profilēšanas un izsekošanas rīkus , piemēram, Perfetto vai Systrace, lai ar mikrosekundes precizitāti redzētu ierīces darbību, atmiņas profila ģeneratorus, lai atklātu noplūdes un piešķiršanas punktus, vai rīkus, piemēram, Simpleperf, lai noskaidrotu, kuras funkcijas patērē visvairāk centrālā procesora jaudas.

Ir svarīgi uzsvērt, ka detalizētai veiktspējas analīzei ir nepieciešama atsevišķu šo maršrutu palaišanas reižu atkļūdošana, kontrolētā veidā reproducējot problēmas. Apkopoto datu analīze ir vērtīga modeļu un regresiju noteikšanai, taču tā neaizstāj padziļinātu konkrētu trasējumu analīzi.

Paralēli ieteicams iestatīt nepārtrauktu metriku vākšanu automatizētās testēšanas vidēs un ražošanas vidē: startēšanas laiki, bloķēšanas ātrumi, kadru metrikas (piemēram, izmantojot FrameMetricsAggregator operētājsistēmā Android), Play Console lauka metrikas, ritināšanas makroetaloni utt. Šie rādītāji ļauj redzēt reālo mainīgumu starp ierīcēm, OS versijām un tīkla apstākļiem.

Lietotnes un sistēmas iestatījumi precīziem mērījumiem

Viena no biežākajām kļūdām ir veiktspējas mērīšana nereālos apstākļos. Lai rezultāti būtu noderīgi, gan APK, gan sistēma ir rūpīgi jākonfigurē, nodrošinot, ka testa vide atgādina ražošanas vidi, vienlaikus kontrolējot troksni.

Lietotnes pusē ir svarīgi neveikt mērīšanu, ņemot vērā atkļūdošanas versijas . Atkļūdošanas varianti pievieno pārbaudes, žurnālus un karodziņus, kas būtiski maina izpildlaikus. Operētājsistēmā Android 10+ manifestā var izmantot atribūtu `profileable android:shell="true"` , lai iespējotu profilēšanu, ņemot vērā laidienu versijas, saglabājot gandrīz reālistisku darbību.

Ieteicams arī izmantot koda samazināšanu ražošanas vidē (ProGuard, R8 utt.), jo koda lielums un organizācija ievērojami ietekmē veiktspēju. Tomēr jums vajadzētu pārskatīt noteikumus: dažas konfigurācijas var izslēgt izsekošanas punktus, kas ir svarīgi mērīšanai, un tie būs jāpielāgo testa versijai.

Runājot par kompilāciju, ir vērts lietotni novest zināmā stāvoklī, parasti un nepārprotami ātruma režīmā vai ātruma profila režīmā . Abi šie režīmi samazina no DeX interpretētā koda apjomu un nepieciešamību pēc fona JIT kompilācijas, kas stabilizē rezultātus. Ātruma profila režīms cenšas vairāk līdzināties reālās pasaules ražošanas darbībai, taču tas prasa lietotnes "iesildīšanu" un profilu (piemēram, bāzes profilu) pārvaldību.

No sistēmas viedokļa, kad nepieciešami ļoti augstas precizitātes mērījumi (mikro-etalonuzdevumi), ir ierasts kalibrēt ierīci : veikt A/B testus tajā pašā terminālī un OS versijā, iestatīt centrālā procesora/grafiskā procesora frekvences, atspējot mazus kodolus vai termiskos ierobežojumus, izmantojot tādus skriptus kā lockClocks utt. Tas neatspoguļo reālo pasauli, bet samazina troksni ļoti specifiskos scenārijos.

Lai mērījumi būtu tuvāki lietotāja pieredzei (startēšana, akumulatora patēriņš, lietotāja saskarnes avārijas), ieteicams izmantot testēšanas sistēmas, piemēram, Macrobenchmark , kas automatizē daudzus no šiem soļiem un ļauj izvairīties no smalkām, bet kritiskām konfigurācijas kļūdām.

Tipiski veiktspējas problēmu modeļi

Gandrīz visās lietojumprogrammās, kas tiek rūpīgi analizētas, parādās noteikti atkārtoti problēmu modeļi , par kuriem ir vērts zināt, jo parasti ir diezgan skaidri risinājumi, ja tie tiek atklāti laikus.

Viena no visbiežāk sastopamajām problēmām ir lēna startēšana pārejas aktivitātes dēļ . Tas notiek, ja pēc startēšanas nolūka (ikonas, paziņojuma, dziļās saites) tiek palaista starpposma aktivitāte, kas nezīmē nevienu kadru, un pēc tam sākas "īstā" aktivitāte. Izsekošanas datos tas parādās kā divi secīgi `activityStart` notikumi bez vizuāla darba starp tiem. Šis "lēciens" pievieno startēšanas latentumu, nesniedzot nekādu vērtību. Risinājums parasti ietver inicializācijas pārveidošanu atkārtoti izmantojamā komponentā vai tās tiešu integrēšanu galvenajā darbībā.

Vēl viens klasisks piemērs ir nevajadzīga piešķiršana, kas aktivizē atkritumu savākšanu . Ja Systrace vai atmiņas profili ilgstošas ​​darbības laikā rāda atkritumu savākšanas ciklus, kas darbojas ik pēc dažām sekundēm, ir ļoti iespējams, ka kods atkārtoti un pastāvīgi piešķir objektus intensīvos ciklos. Risinājums nav noņemt katru jaunu objektu, bet gan risināt karstos punktus, atkārtoti izmantojot struktūras vai lietojot apvienošanas modeļus, kad tas ir nepieciešams.

Kadri ar bloķēšanu bieži tiek atrasti arī grafikas cauruļvadā . Veselīgā trasē Choreographer.doFrame() izsaukumi notiek regulārā ritmā (piemēram, ik pēc 16,7 ms). Pietuvinot apgabalus ar šādu ritmu, var atklāt dārgus skatus, pārāk sarežģītus izkārtojumus, lietotāja interfeisa pavedienā darbojošās I/O operācijas vai nepareizi konfigurētus RecyclerViews.

Tieši RecyclerView ir daudzu problēmu avots: visa datu kopa tiek padarīta nederīga ar `notifyDataSetChanged()`, ja faktiski ir mainījušies tikai daži elementi, nepareizi konfigurēti pārstrādāto skatu kopumi ligzdotos RecyclerView elementos vai netiek veikta pietiekama datu iepriekšēja ielāde, sasniedzot saraksta beigas. Tas viss rada dārgu renderēšanu, ritināšanas lēcienus un ievērojamu gaidīšanas laiku lietotājam.

Veiktspējas pārbaude: veidi, soļi un labākā prakse

Papildus ražošanas uzraudzībai jebkurai nopietnai stratēģijai ir nepieciešams stabils lietojumprogrammu veiktspējas testēšanas plāns kontrolētā vidē. Šī testēšana ļauj pārbaudīt jaudu, stabilitāti un mērogojamību, pirms lietotāji tiek pakļauti izmaiņām vai jaunām versijām.

Ir vairāki testu veidi, katram no tiem ir savs konkrēts mērķis:

• Slodzes testiTie novērtē lietotnes darbību paredzamās lietotāju vai darījumu slodzes apstākļos, mērot reakcijas laikus, caurlaidspēju un resursu patēriņu, lai pirms izvietošanas atklātu sastrēgumus.
• Stresa testiTie spiež sistēmu ārpus tās ierastajām robežām, lai redzētu, cik tālu to var padot, kā tā var sabojāties un kā tā atjaunojas. Tie ir galvenie jaudas plānošanā un Melnās piektdienas tipa maksimuma pārvaldībā.
• Izturības/mērcēšanas testiTie uztur ilgstošu slodzi stundām vai dienām ilgi, lai atklātu lēnas degradācijas, atmiņas noplūžu vai resursu izsīkuma problēmas.
• Maksimālie testiTie simulē pēkšņus un atkārtotus slodzes palielinājumus (piemēram, kampaņas, funkciju palaišanu, tiešraides), lai pārbaudītu, vai lietojumprogramma un infrastruktūra spēj tikt galā ar pēkšņām izmaiņām.
• Tilpuma testiViņi analizē lietotnes darbību, kad lietotāju skaits ievērojami palielinās. datu apjomu (datubāzes lielums, faili, ziņojumi), atbildes laiku validācija, krātuves uzticamība un datu zudumi.
• Mērogojamības testiViņi pārbauda, ​​kā lietojumprogramma reaģē, pakāpeniski palielinot slodzi, un vai horizontāla vai vertikāla mērogošana nodrošina paredzēto veiktspējas uzlabojumu.

Tipisks veiktspējas testēšanas process ietver vairākas atšķirīgas fāzes. Pirmkārt, prasību analīze : izpratne par to, kādi reakcijas laiki, caurlaidspējas koeficienti, pieejamības līmeņi un kļūdu robežas ir pieņemamas uzņēmumam. Pēc tam plānošanas un stratēģijas fāze , kurā tiek definēts testu apjoms, vide, rīki un uzraugāmie rādītāji.

Pēc tam tiek izstrādāti testa gadījumi , lai aptvertu dažādus slodzes scenārijus, tīkla apstākļus un datu apjomus; tiek konfigurēta testa vide (aparatūra, programmatūra, tīkls, slodzes ievadīšana un uzraudzības rīki); un tiek veikti testi, rūpīgi apkopojot veiktspējas datus.

Kritiskā fāze ir uzraudzība un analīze : reakcijas laiku korelācija ar centrālā procesora noslodzi, tīkla latentuma korelācija ar kļūdu līmeni, datplūsmas maksimuma pieaugums ar datubāzes pārslodzi utt. Pēc tam, kad secinājumi ir dokumentēti skaidros ziņojumos ieinteresētajām personām, process pāriet uz optimizāciju un atkārtotu testēšanu : kods, konfigurācijas vai resursi tiek pielāgoti, un testi tiek atkārtoti, līdz uzlabojumi tiek apstiprināti.

Rīki un ietvari veiktspējas testēšanai

Lai visu iepriekš minēto ieviestu praksē, ir jāpaļaujas uz īpašiem veiktspējas testēšanas rīkiem — gan atvērtā pirmkoda, gan komerciāliem —, kas aptver automatizāciju, slodzes ģenerēšanu, uzraudzību un analīzi. Dažas atbilstošas ​​kategorijas ir:

• Atvērtā pirmkoda rīkiTādi projekti kā Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder vai vienību un funkcionālās testēšanas ietvari (JUnit, XCTest, Appium), kas ir paplašināti ar veiktspējas scenārijiem, ļauj izveidot ļoti jaudīgus testu komplektus ar zemām licencēšanas izmaksām.
• Komerciālās slodzes testēšana un APM rīkiTādi risinājumi kā WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest vai Parasoft nodrošina integrētas vides ar mākonī balstītu slodzes ģenerēšanu, uzlabotu atskaišu veidošanu un profesionālu atbalstu.
• Specializēti un novērojami risinājumiTādi produkti kā Applications Manager, Instana, Dynatrace, IBM Turbonomic vai tīkla uzraudzības platformas, piemēram, SolarWinds, kas koncentrējas uz nepārtrauktu uzraudzību, anomāliju noteikšanu un korelāciju starp lietotņu veiktspēju, infrastruktūru un lietotāja pieredzi.
• Platformai specifiski rīkiPiemēram, Android gadījumā tādi rīki kā Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace vai Play Console kadru metrikas ļauj veikt ļoti precīzu sistēmas līmeņa uzvedības analīzi.

Izvēloties starp vienu vai otru, ieteicams ņemt vērā tādus faktorus kā lietošanas ērtums, protokolu un tehnoloģiju atbalsts, mērogojamība, integrācija ar CI/CD , licencēšanas modelis, paplašināmība un atbalsta kvalitāte (kopienas vai komerciāls atbalsts). Nav arī nekas neparasts apvienot vairākus: vienu slodzes ģenerēšanai, otru APM un vēl vienu infrastruktūras novērojamībai.

Īsāk sakot, lietojumprogrammu veiktspējas analīzei un uzraudzībai ir nepieciešama labi izvēlētu rādītāju, atbilstošu rīku un disciplīnas testēšanas procesos kombinācija, taču rezultāts to vairāk nekā kompensē: ātrākas, stabilākas un efektīvākas lietotnes , apmierinātāki lietotāji, mazāk ražošanas incidentu un, protams, tieša pozitīva ietekme uz zīmola reputāciju un ieņēmumiem.

Saistītais raksts:

Atklājiet Qt Creator IDE: visspēcīgākā vide starpplatformu lietotņu izveidei