Pagsubaybay sa Pagganap — ano ito, mga sukatan at pangongolekta ng datos

Ano ang pagsubaybay sa pagganap

Pagsubaybay sa pagganap ay ang praktika ng dami ng pagtatasa ng pag-uugali ng application sa pamamagitan ng pangongolekta ng mga sukatan ng oras ng pagpapatupad, paggamit ng memorya, dalas ng frame, at pagkonsumo ng enerhiya. Hindi tulad ng pag-uulat ng crash na nagtatala lamang ng mga nakamamatay na pagkabigo, sinusubaybayan ng pagsubaybay sa pagganap ang unti-unting pagbaba: gumagana ang application ngunit mas mabagal kaysa sa nararapat.

Ayon sa Google (2024), 53% ng mga gumagamit ay nagsasara ng application kung maglo-load ito nang higit sa 3 segundo. Ang bawat karagdagang segundo ng pagkaantala ay nagbabawas ng conversion ng average na 20% sa bawat kategorya. Ginagawa nitong hindi lamang isang teknikal na praktika kundi isang pangangailangan sa negosyo para sa mga produktong mobile ang pagsubaybay sa pagganap.

Sinasaklaw ng modernong pagsubaybay sa pagganap ang apat na antas: panig ng kliyente (iOS, Android), network (mga kahilingan sa API, WebSocket), mga serbisyo sa backend, at imprastraktura. Sa pag-develop ng mobile, ang pokus ay sa mga sukatan ng kliyente, dahil ang karamihan sa mga problema sa pagganap ay lumilitaw mismo sa aparato ng gumagamit.

Mga pangunahing sukatan ng mobile application

Para sa kumpletong pagsubaybay, kailangang subaybayan ang limang grupo ng mga sukatan, bawat isa ay responsable para sa isang aspeto ng karanasan ng gumagamit. Ang FPS (frames per second) ay nagpapakita ng kinis ng mga animation at pag-scroll — ang halagang mas mababa sa 30 frame bawat segundo ay nararamdaman bilang pagbagal.

Mga sukatan ng oras

Oras ng malamig na pagsisimula ng application — mula sa pagtapik sa icon hanggang sa ganap na kahandaan ng interface. Oras ng mainit na pagsisimula — pagbabalik mula sa background. Oras ng tugon sa aksyon ng gumagamit (tap-to-response). Oras ng pagsisimula para sa Android ay sinusukat sa pamamagitan ng ActivityManager, para sa iOS — sa pamamagitan ng dyld at premain na oras. Ayon sa Firebase Performance, ang median na oras ng malamig na pagsisimula para sa top-100 na application ay 1.8 segundo.

Mga sukatan ng memorya at CPU

Ang pagkonsumo ng RAM ay hindi dapat lumampas sa 80% ng magagamit na dami sa aparato, kung hindi ay magsisimulang i-unload ng system ang application mula sa background. Ang bakas ng memorya ay sinusubaybayan sa pamamagitan ng Xcode Instruments (iOS) at Android Profiler. Ang mga pagtagas ng memorya ay natutukoy sa pamamagitan ng pagtaas ng pagkonsumo sa mga paulit-ulit na operasyon — halimbawa, pag-navigate sa pagitan ng mga screen.

Mga sukatan ng network

Oras ng pagpapatupad ng kahilingan sa HTTP, laki ng tugon, dalas ng time-out at mga error. Ang latency ng network ay partikular na kritikal para sa mga mobile application na gumagana sa mga kondisyon ng hindi matatag na koneksyon (3G, metro, elevator, roaming). Inirerekomenda na subaybayan ang oras ng tugon p95 — ito mismo ang nagpapakita ng karanasan ng pinaka “mabibigat” na gumagamit na may pinakamasamang kondisyon ng network.

Real User Monitoring at Synthetic Monitoring

Ang Real User Monitoring (RUM) ay nangongolekta ng datos mula sa mga tunay na aparato ng gumagamit sa kapaligiran ng produksyon. Ang pamamaraang ito ay nagpapakita ng aktwal na mga pagkaantala na nararanasan ng mga gumagamit, isinasaalang-alang ang kanilang mga aparato, bersyon ng OS, network, at geolokasyon. Ang RUM ay nagbibigay ng pinakatumpak na larawan ng pagganap, ngunit depende sa kung aling mga gumagamit ang napasama sa sampol.

Ang Synthetic Monitoring naman ay nagsasagawa ng mga paunang natukoy na senaryo sa mga aparato ng pagsubok sa kontroladong kondisyon. Pinapayagan nitong matukoy ang regression bago ito umabot sa mga gumagamit at muling gawin ang mga problema sa parehong kapaligiran. Ang Firebase Test Lab at BrowserStack ay nagbibigay ng mga sintetikong pagsubok sa mga tunay na aparato nang walang manu-manong pagsisimula.

Ang optimal na estratehiya ay kombinasyon ng parehong diskarte: ang mga sintetikong pagsubok ay humuhuli ng mga regression sa yugto ng CI, at ang RUM ay nagbibigay ng tunay na larawan sa produksyon. Ayon sa Datadog (2024), ang mga team na gumagamit ng parehong pamamaraan ay nakakatuklas ng 35% higit pang mga problema sa pagganap bago maging insidente ang mga ito.

Pag-set up ng Firebase Performance Monitoring

Ang Firebase Performance Monitoring ay isang libreng tool mula sa Google para sa pangongolekta ng mga sukatan ng pagganap sa iOS at Android. Awtomatiko itong sumusukat ng oras ng pagsisimula ng application, mga kahilingan sa HTTP, at pag-render ng screen nang hindi nangangailangang magsulat ng code. Para sa pag-install, sapat na idagdag ang SDK sa proyekto at i-activate ang modyul na Performance sa console ng Firebase.

Awtomatikong pangongolekta ng sukatan

Pagkatapos ikonekta ang SDK, awtomatikong gumagawa ang Firebase Performance ng trace para sa bawat kahilingan sa HTTP sa pamamagitan ng URLSession (iOS) o OkHttp (Android). Ang pag-render ng screen ay sinusukat para sa UIViewController at Activity, na nagtatala ng oras mula onCreate/viewDidLoad hanggang sa pagkumpleto ng unang render. Lahat ng sukatan ay pinagsama-sama sa console ng Firebase na may paghahati ayon sa mga bersyon ng application, aparato, at bansa.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // pagpapatupad ng pagbabayad
        trace.stop()
    }
}

Gumagawa ang code ng custom na trace para sa senaryo ng pagbabayad na may katangian ng halaga. Sa pamamagitan ng trace na ito sa console ng Firebase, makikita ang median at p95 na oras ng pagpapatupad ng pagbabayad, na naka-grupo ayon sa mga bersyon ng application at aparato.

Pagsubaybay sa HTTP

Awtomatikong hinaharang ng Firebase ang mga kahilingan sa network at nagtatala ng URL, code ng tugon, laki ng payload, at oras ng pagpapatupad. Para sa OkHttp sa Android, gumagana ang awtomatikong instrumentasyon nang walang karagdagang pagsasaayos. Ang mga kahilingan sa network ay ipinapakita sa console na may pagpapangkat ayon sa mga endpoint, na nagbibigay-daan sa mabilis na pagtuklas ng pagbagal ng isang partikular na API.

Mga custom na trace para sa lohika ng negosyo

Sinasaklaw ng mga karaniwang sukatan ang pangkalahatang pagganap, ngunit para sa pagsusuri ng mga proseso ng negosyo ay kinakailangan ang instrumentasyon ng mga partikular na senaryo. Ang mga custom na trace ay nagpapahintulot na sukatin ang oras ng pagpapatupad ng pagpapatunay, pag-load ng feed ng balita, pagproseso ng imahe, o pag-sync ng datos.

Ang bawat custom na trace ay dapat may makabuluhang pangalan sa format na “senaryo-aksyon” at naglalaman ng mga katangian para sa pag-filter. Halimbawa, ang trace na “image-upload” na may mga katangiang “file_size” at “compression_quality” ay magbibigay-daan upang matukoy ang pag-asa ng oras ng pag-load sa laki ng imahe. Inirerekomenda na huwag lumikha ng higit sa 20 custom na trace bawat screen — ang labis na instrumentasyon ay lumilikha ng ingay at nagpapahirap sa pagsusuri.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // pag-load ng imahe
    trace?.stop()
}

Ang halimbawa sa Swift ay gumagawa ng trace para sa pag-load ng imahe na may mga katangian ng laki ng file at antas ng compression. Sa console ng Firebase, ang mga katangiang ito ay nagiging mga patlang para sa pagpapangkat at pag-filter ng mga sukatan.

Mga hangganan ng alerto at abiso

Ang pangongolekta ng mga sukatan nang walang sistema ng abiso ay walang silbi. Ang abiso ay dapat magpaalam sa team tungkol sa paglabas ng mga sukatan mula sa pinapayagang mga hangganan, kung saan ang mga hangganan ng alerto ay hinati sa tatlong antas: babala (warning), kritikal (critical), at pagkasira (outage). Ang bawat antas ay tumutukoy sa channel ng abiso: warning — sa Slack channel ng team, critical — sa PagerDuty ng nakatalagang inhinyero, outage — mass na pagpapadala sa lahat ng stakeholders.

Para sa mga sukatan ng mobile, inirerekomenda na gumamit ng mga dinamikong hangganan batay sa mga porsyento: lumalampas ng 4 na segundo ang p95 na oras ng malamig na pagsisimula — kritikal na alerto. Ang mga statikong hangganan (halimbawa, CPU > 90%) ay mas masahol na gumagana dahil hindi isinasaalang-alang ang normal na pagbabagu-bago ng pagkarga depende sa oras ng araw at araw ng linggo. Ang Firebase Performance ay sumusuporta sa pag-configure ng mga alerto sa pamamagitan ng Firebase Console na may pagpapadala sa Slack, PagerDuty, at email, na may kakayahang mag-eskalasyon kung walang kumpirmasyon.

Ayon sa Incident Management Survey (2024), ang mga team na nag-co-configure ng mga alerto batay sa mga porsyento, hindi sa mga average na halaga, ay nakakaligtaan ng 45% na mas kaunting insidente. Ang average na halaga (average) ay nagpapakinis ng mga pagtaas — ang p95 ay garantisadong nagpapakita ng pinakamasamang senaryo para sa mga gumagamit, anuman ang oras ng araw at pana-panahong pagbabagu-bago ng pagkarga.