Мониторинг на производителността — какво е, метрики и събиране на данни

Какво е мониторинг на производителността

Мониторинг на производителността е практиката за количествена оценка на поведението на приложението чрез събиране на метрики за време на изпълнение, използване на памет, честота на кадрите и консумация на енергия. За разлика от отчитането на сривове, което записва само фатални повреди, мониторингът на производителността проследява постепенната деградация: приложението работи, но по-бавно, отколкото трябва.

Според Google (2024), 53% от потребителите затварят приложението, ако се зарежда повече от 3 секунди. Всяка допълнителна секунда забавяне намалява конверсията средно с 20% в различните категории. Това прави мониторинга на производителността не просто техническа практика, а бизнес необходимост за мобилните продукти.

Съвременният мониторинг на производителността обхваща четири нива: клиентска част (iOS, Android), мрежа (API заявки, WebSocket), backend услуги и инфраструктура. В мобилната разработка фокусът е върху клиентските метрики, тъй като повечето проблеми с производителността възникват точно на устройството на потребителя.

Ключови метрики на мобилното приложение

За пълноценен мониторинг е необходимо да се проследяват пет групи метрики, всяка от които отговаря за свой аспект на потребителското изживяване. FPS (frames per second) показва плавността на анимациите и скролването — стойност под 30 кадъра в секунда се усеща като забавяне.

Метрики на времето

Време за студен старт на приложението — от момента на докосване на иконата до пълна готовност на интерфейса. Време за горещ старт — връщане от фонов режим. Време за отговор на потребителско действие (tap-to-response). Времето за стартиране за Android се измерва чрез ActivityManager, за iOS — чрез dyld и premain време. Според Firebase Performance, медианното време за студен старт за топ 100 приложения е 1,8 секунди.

Метрики на паметта и CPU

Консумацията на оперативна памет не трябва да надвишава 80% от наличния обем на устройството, в противен случай системата започва да разтоварва приложението от фонов режим. Отпечатъкът на паметта се проследява чрез Xcode Instruments (iOS) и Android Profiler. Изтичанията на памет се откриват чрез нарастване на консумацията при повтарящи се операции — например при преминаване между екрани.

Мрежови метрики

Време за изпълнение на HTTP заявка, размер на отговора, честота на таймаути и грешки. Мрежовото забавяне е особено критично за мобилни приложения, работещи в условия на нестабилна връзка (3G, метро, асансьор, роуминг). Препоръчва се проследяване на времето за отговор p95 — именно то показва изживяването на най-“тежките” потребители с най-лошите мрежови условия.

Real User Monitoring и Synthetic Monitoring

Real User Monitoring (RUM) събира данни от реални устройства на потребителите в производствена среда. Този метод показва действителните забавяния, които потребителите изпитват, като взема предвид техните устройства, версии на ОС, мрежа и геолокация. RUM дава най-точната картина на производителността, но зависи от това кои потребители са попаднали в извадката.

Synthetic Monitoring, от друга страна, изпълнява предварително зададени сценарии на тестови устройства в контролирани условия. Позволява откриване на регресия, преди да достигне до потребителите, и възпроизвеждане на проблеми в еднаква среда. Firebase Test Lab и BrowserStack предоставят синтетични тестове на реални устройства без ръчно стартиране.

Оптималната стратегия е комбинация от двата подхода: синтетичните тестове улавят регресии в CI етапа, а RUM дава реалната картина в продукция. Според Datadog (2024), екипите, използващи и двата метода, откриват 35% повече проблеми с производителността, преди да станат инциденти.

Настройка на Firebase Performance Monitoring

Firebase Performance Monitoring е безплатен инструмент от Google за събиране на метрики за производителност на iOS и Android. Той автоматично измерва времето за стартиране на приложението, HTTP заявките и рендирането на екрани, без да е необходимо да пишете код. За инсталиране е достатъчно да добавите SDK към проекта и да активирате модула Performance в конзолата на Firebase.

Автоматично събиране на метрики

След свързване на SDK, Firebase Performance автоматично създава trace за всяка HTTP заявка чрез URLSession (iOS) или OkHttp (Android). Рендирането на екрани се измерва за UIViewController и Activity, като се записва времето от onCreate/viewDidLoad до завършване на първото рендиране. Всички метрики се агрегират в конзолата на Firebase с разбивка по версии на приложението, устройства и държави.

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())
        // изпълнение на плащане
        trace.stop()
    }
}

Кодът създава персонализиран trace за сценария на плащане с атрибут за сума. Чрез този trace в конзолата на Firebase можете да видите медианата и p95 време за изпълнение на плащането, групирани по версии на приложението и устройства.

HTTP мониторинг

Firebase автоматично прихваща мрежови заявки и записва URL, код на отговор, размер на payload и време за изпълнение. За OkHttp на Android автоматичната инструментация работи без допълнителна конфигурация. Мрежовите заявки се показват в конзолата с групиране по endpoint-и, което позволява бързо откриване на забавяне на конкретно API.

Персонализирани trace за бизнес логика

Стандартните метрики покриват общата производителност, но за диагностика на бизнес процеси се изисква инструментация на конкретни сценарии. Персонализираните trace позволяват измерване на времето за изпълнение на удостоверяване, зареждане на новинарски поток, обработка на изображение или синхронизация на данни.

Всеки персонализиран trace трябва да има смислено име във формат “сценарий-действие” и да съдържа атрибути за филтриране. Например, trace “image-upload” с атрибути “file_size” и “compression_quality” ще позволи откриване на зависимостта на времето за зареждане от размера на изображението. Препоръчва се да не създавате повече от 20 персонализирани trace на един екран — прекомерната инструментация създава шум и усложнява анализа.

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")
    // зареждане на изображение
    trace?.stop()
}

Примерът в Swift създава trace за зареждане на изображение с атрибути за размер на файла и ниво на компресия. В конзолата на Firebase тези атрибути стават полета за групиране и филтриране на метрики.

Прагове за задействане и алармиране

Събирането на метрики без система за известяване е безполезно. Алармирането трябва да информира екипа за излизане на метриките извън допустимите граници, като праговете за задействане се делят на три нива: предупреждение (warning), критично (critical) и аварийно (outage). Всяко ниво определя канала за известяване: warning — в Slack канала на екипа, critical — в PagerDuty на дежурния инженер, outage — масово изпращане до всички заинтересовани страни.

За мобилни метрики се препоръчва използването на динамични прагове, базирани на персентили: p95 време за студен старт надвишава 4 секунди — критичен аларм. Статичните прагове (например CPU > 90%) работят по-зле, тъй като не отчитат нормалните колебания на натоварването в зависимост от часа на деня и деня от седмицата. Firebase Performance поддържа конфигуриране на аларми чрез Firebase Console с изпращане до Slack, PagerDuty и имейл, с възможност за ескалация при липса на потвърждение.

Според Incident Management Survey (2024), екипите, които конфигурират аларми на базата на персентили, а не на средни стойности, пропускат 45% по-малко инциденти. Средната стойност (average) изглажда пиковете — p95 гарантирано показва най-лошия сценарий за потребителите, независимо от часа на деня и сезонните колебания на натоварването.