Analisis prestasi aplikasi: metrik, pengujian dan pemantauan

Informatec Digital » Sumber » Analisis prestasi aplikasi: metrik, pengujian dan pemantauan

Untuk mencapai tahap kualiti tersebut, tidak mencukupi hanya dengan "menguji sedikit sebelum menerbitkan". Ia memerlukan gabungan pemantauan berterusan (APM dan RUM) , ujian prestasi yang direka bentuk dengan baik, metrik yang jelas dan alatan yang mampu mensimulasikan segala-galanya daripada penggunaan harian hinggalah lonjakan trafik yang melampau. Tambahan pula, ia mesti dilakukan secara strategik: mengukur apa yang benar-benar penting kepada perniagaan dan mengautomasikan sebanyak mungkin untuk mengelakkan tindak balas yang berterusan terhadap masalah.

Prestasi aplikasi: apakah itu, mengapa ia penting dan apa yang kami ukur

Apabila kita bercakap tentang prestasi aplikasi, kita merujuk kepada keupayaan aplikasi untuk bertindak balas dengan cepat, kekal stabil dan berskala apabila pengguna atau jumlah data meningkat, tanpa meningkatkan penggunaan sumber secara drastik atau menjejaskan pengalaman pengguna. Ini terpakai kepada aplikasi mudah alih, web dan desktop , API, mikroservis dan sistem perusahaan yang kompleks.

Kuncinya adalah untuk mengukur secara sistematik satu siri metrik prestasi aplikasi (KPI) yang membolehkan anda memahami sama ada aplikasi tersebut memenuhi objektif teknikal dan perniagaan, dan untuk mengesan tepat pada masanya apabila sesuatu mula tidak kena, sebelum pengguna akhir menyedarinya atau penggera berbunyi dalam pengeluaran.

Antara metrik yang paling biasa digunakan untuk menilai prestasi aplikasi ialah:

• penggunaan CPU: berapa banyak pemproses yang digunakan oleh aplikasi dan sama ada terdapat lonjakan yang mendedahkan pengiraan yang berlebihan, gelung yang direka bentuk dengan buruk atau proses yang menyekat tindak balas.
• penggunaan memori: jumlah memori yang digunakan, kemunculan kebocoran, ralat halaman atau hiperpagasi yang menunjukkan bahawa sistem menghabiskan lebih banyak masa memindahkan data daripada melaksanakan logik perniagaan.
• Permintaan seminit dan bait setiap permintaanIni menunjukkan berapa banyak permintaan yang diproses oleh aplikasi atau API dan berapa banyak data yang dikendalikannya dalam setiap permintaan. Ia membantu untuk melihat bagaimana penskalaan bahagian belakang dan sama ada jumlah data setiap panggilan adalah munasabah.
• Latensi dan masa tindak balas: berapa lama masa yang diperlukan oleh aplikasi untuk bertindak balas, dari masa pengguna melakukan tindakan atau klien menghantar permintaan sehingga mereka menerima respons yang berguna.
• Masa operasi dan ketersediaan: peratusan masa perkhidmatan beroperasi, biasanya dipantau dengan ping berulang atau semakan sintetik.
• Kadar ralat: perkadaran permintaan yang berakhir dengan ralat (kod HTTP 4xx/5xx, pengecualian yang tidak dikendalikan, kegagalan fungsi).
• Skor Apdex dan kepuasan pengguna: indeks yang meringkaskan, dalam satu nilai, peratusan pengguna yang berpuas hati, bertolak ansur atau kecewa berdasarkan masa tindak balas.
• Prestasi kutipan sampah (GC)Pada platform dengan pengurusan memori automatik (Java, .NET, Android), berapa banyak masa yang dihabiskan untuk GC, berapa banyak jeda yang diperkenalkannya, dan bagaimana ini mempengaruhi penggunaan dan kelancaran CPU.
• Kadar atau prestasi daya pemprosesan: bilangan transaksi atau permintaan yang diproses setiap unit masa, kritikal dalam sistem dengan keserentakan yang tinggi.

Matlamat menjejaki metrik ini bukanlah untuk mengumpul graf: ia adalah untuk memahami keadaan sebenar aplikasi , menjangkakan kesesakan, mengutamakan penambahbaikan dan menunjukkan, dengan data, bahawa pengoptimuman mempunyai kesan ke atas pengalaman pengguna dan hasil perniagaan.

APM, RUM dan pemantauan prestasi masa nyata

Dalam persekitaran moden, dengan seni bina teragih, kontena, awan hibrid dan mikroservis, adalah mustahil untuk mengawal prestasi tanpa alat pemantauan prestasi aplikasi (APM) yang baik yang digabungkan dengan teknik pemantauan pengguna sebenar (RUM) dan, semakin banyak, komponen kebolehcerapan yang canggih.

Penyelesaian APM/RUM (seperti yang disepadukan dengan Elastic, Instana, Applications Manager, Turbonomic dengan APM, dll.) memberikan keterlihatan menyeluruh tentang apa yang berlaku dalam aplikasi anda: masa tindak balas, jejak teragih, pertanyaan pangkalan data, panggilan luaran, ralat dan anomali, yang disepadukan dengan metrik infrastruktur.

Pemantauan Pengguna Sebenar (RUM) merekodkan apa yang dilihat oleh pengguna sebenar: masa pemuatan skrin, antara muka yang terhenti, ralat pelayar atau aplikasi mudah alih dan kependaman yang dirasakan merentasi rantau dan peranti yang berbeza. Ini melengkapi penanda aras sintetik dan ujian makmal, yang penting, tetapi tidak menggantikan data dunia sebenar.

Sebaliknya, platform APM moden menawarkan ciri-ciri seperti:

• Pemantauan masa nyata KPI utama: ketersediaan, Apdex, kadar ralat, kelajuan pemindahan, Penggunaan sumber.
• Jejak teragih untuk menjejaki transaksi merentasi berbilang perkhidmatan mikro, barisan, pangkalan data dan perkhidmatan luaran, mengenal pasti pautan paling perlahan.
• Peta kebergantungan Alatan automatik yang menunjukkan bagaimana perkhidmatan, pangkalan data, barisan dan bahagian hadapan berkaitan, menjadikannya lebih mudah untuk mengesan punca kegagalan.
• Pemprofilan kod dan thread untuk mencari kaedah, pertanyaan SQL atau bahagian kod yang menggunakan terlalu banyak CPU atau menyekat thread antara muka.
• Amaran pintar dan AIOps yang menggabungkan pembelajaran mesin dan analisis siri masa untuk mengesan anomali, mengurangkan penggera palsu dan mengutamakan insiden kritikal.

Dengan menggabungkan APM, RUM dan pemantauan sintetik, anda memperoleh keterlihatan 360 darjah ke dalam prestasi : apa yang dilihat pengguna, apa yang dilakukan oleh aplikasi secara dalaman dan bagaimana infrastruktur asas bertindak balas. Ini membolehkan pasukan DevOps dan ITOps bertindak balas dengan cepat terhadap insiden dan, lebih baik lagi, mencegahnya.

Metrik prestasi utama dalam aplikasi mudah alih dan web

Dalam aplikasi mudah alih dan web, metrik prestasi tertentu amat sensitif kerana ia secara langsung mempengaruhi persepsi pengguna dan kejayaan produk. Pemantauan rapi penunjuk ini membezakan antara aplikasi yang menarik perhatian pengguna dan aplikasi yang dinyahpasang selepas penggunaan kedua.

Salah satu perkara kritikal dalam mudah alih ialah latensi pelancaran aplikasi , iaitu masa yang berlalu dari masa pengguna mengetik ikon (atau pemberitahuan) sehingga mereka melihat data berguna pada skrin. Beberapa jenis boleh dibezakan:

• Permulaan sejukAplikasi ini tiada dalam memori; sistem mesti mencipta proses, memuatkan kod, memulakan pustaka dan memaparkan skrin pertama.
• Permulaan separa panasProses ini wujud, tetapi aktiviti tersebut dicipta semula atau dipulihkan kepada keadaan asal.
• Permulaan Panas: anda hanya perlu mengembang semula paparan anda atau menyambung semula aktiviti, dengan sedikit kerja tambahan.

Sebagai rujukan, adalah sangat disyorkan untuk menyasarkan masa pelancaran sejuk di bawah 500 ms, kerana ini akan membawa latensi p95 dan p99 (persentil tertinggi) hampir dengan median. Jika sesetengah pengguna menunggu beberapa saat manakala yang lain membuka aplikasi dalam setengah saat, ada sesuatu yang tidak seimbang.

Satu lagi aspek kritikal ialah penatalan dan pembekuan antara muka . Pada skrin bergerak (suapan, senarai, galeri), pengguna menjangkakan kelancaran yang sempurna. Apabila sistem gagal menjana bingkai pada kadar penyegaran peranti (60 Hz, 90 Hz atau 120 Hz), kegagapan dan kegagapan berlaku. "Kegagapan" ini berlaku apabila aplikasi mengambil masa lebih lama daripada tempoh bingkai (contohnya, lebih daripada 16,7 ms pada 60 FPS) untuk memaparkan kandungan.

Selain kelancaran, peralihan skrin mesti dipantau dengan teliti . Menukar tab, membuka butiran daripada senarai atau memaparkan dialog hendaklah berlaku secara serta-merta, dengan animasi yang lancar dan tiada skrin berkelip atau kosong yang berpanjangan.

Di latar belakang, tetapi sama pentingnya, ialah penggunaan bateri dan kecekapan tenaga. Tugas yang tidak perlu, peruntukan memori yang besar dan penggunaan CPU yang intensif mengurangkan hayat bateri dan menyebabkan peranti terlalu panas. Android Runtime (ART) telah meningkatkan kecekapan, tetapi jika gelung dalaman aplikasi anda mencipta beribu-ribu objek baharu sesaat, kos peruntukan dan pengumpulan sampah akan ketara.

Aliran kerja untuk mengenal pasti dan membetulkan masalah prestasi

Untuk mengelakkan bergantung pada nasib, adalah sangat membantu untuk mewujudkan aliran kerja analisis prestasi yang sistematik yang menggabungkan ujian manual terperinci di makmal dengan pengumpulan metrik agregat dalam pengeluaran. Pendekatan biasa merangkumi langkah-langkah berikut:

Pertama, adalah perlu untuk mengenal pasti perjalanan pengguna yang kritikal , iaitu aliran yang mempunyai impak terbesar terhadap pengalaman dan perniagaan:

• Pelancaran aplikasi yang kerap (ikon, pemberitahuan, pautan dalam).
• Skrin dengan penatalan berterusan pada sejumlah besar data.
• Peralihan utama antara pandangan dan aktiviti.
• Aliran panjang seperti melayari, main balik audio/video, pembayaran, dsb.

Setelah ditakrifkan, ia diinstrumentasikan dan dianalisis menggunakan alat pemprofilan dan pengesanan seperti Perfetto atau Systrace untuk melihat apa yang dilakukan oleh peranti dengan ketepatan mikrosaat, penjana profil memori untuk mengesan kebocoran dan titik panas peruntukan, atau alat seperti Simpleperf untuk mengetahui fungsi mana yang menggunakan CPU paling banyak.

Adalah penting untuk ditekankan bahawa analisis prestasi terperinci memerlukan penyahpepijatan larian individu bagi laluan ini, menghasilkan semula masalah secara terkawal. Menganalisis data agregat adalah berharga untuk mengesan corak dan regresi, tetapi ia tidak menggantikan analisis mendalam tentang jejak tertentu.

Secara selari, adalah dinasihatkan untuk menyediakan pengumpulan metrik berterusan dalam persekitaran ujian automatik dan dalam pengeluaran: masa permulaan, kadar penyekatan, metrik bingkai (contohnya, melalui FrameMetricsAggregator pada Android), metrik medan Play Console, penanda aras makro skrol, dsb. Metrik ini membolehkan anda melihat kebolehubahan sebenar antara peranti, versi OS dan keadaan rangkaian.

Tetapan aplikasi dan sistem untuk pengukuran yang tepat

Salah satu kelemahan yang paling biasa ialah mengukur prestasi dalam keadaan yang tidak realistik. Agar hasilnya berguna, kedua-dua APK dan sistem mesti dikonfigurasikan dengan teliti, memastikan persekitaran ujian menyerupai pengeluaran sambil mengawal hingar.

Di bahagian aplikasi, adalah penting untuk tidak mengukur terhadap binaan debug . Varian debug menambah semakan, log dan bendera yang mengubah masa jalan dengan ketara. Dalam Android 10+, anda boleh menggunakan atribut `profileable android:shell="true"` dalam manifes untuk mendayakan pemprofilan terhadap binaan keluaran, mengekalkan tingkah laku yang hampir realistik.

Anda juga dinasihatkan untuk menggunakan pengurangan kod pengeluaran (ProGuard, R8, dll.), kerana saiz dan organisasi kod membuat perbezaan prestasi yang ketara. Walau bagaimanapun, anda harus menyemak semula peraturan: sesetengah konfigurasi mungkin menghapuskan titik penjejakan yang penting untuk pengukuran, dan ini perlu diselaraskan untuk versi ujian.

Berkenaan penyusunan, adalah berbaloi untuk membawa aplikasi ke dalam keadaan yang diketahui, biasanya dan jelas mod kelajuan atau mod profil kelajuan . Kedua-duanya mengurangkan jumlah kod yang ditafsirkan daripada DeX dan keperluan untuk penyusunan JIT latar belakang, yang menstabilkan keputusan. Mod profil kelajuan cuba menyerupai tingkah laku pengeluaran dunia sebenar dengan lebih dekat, tetapi ia memerlukan "pemanasan" aplikasi dan mengurus profil (contohnya, Profil Garis Asas).

Dari perspektif sistem, apabila pengukuran kesetiaan yang sangat tinggi (penanda aras mikro) diperlukan, adalah perkara biasa untuk menentukur peranti : jalankan ujian A/B pada terminal dan versi OS yang sama, tetapkan frekuensi CPU/GPU, lumpuhkan teras kecil atau pengehadan terma dengan skrip seperti lockClocks, dsb. Ini tidak mewakili dunia sebenar, tetapi ia mengurangkan hingar untuk senario yang sangat spesifik.

Untuk pengukuran yang lebih dekat dengan pengalaman pengguna (permulaan, penggunaan bateri, ranap UI), adalah disyorkan untuk menggunakan rangka kerja pengujian seperti Macrobenchmark yang mengautomasikan banyak langkah ini dan mengelakkan ralat konfigurasi yang halus tetapi kritikal.

Corak tipikal masalah prestasi

Dalam hampir semua aplikasi yang dianalisis secara menyeluruh, corak masalah berulang tertentu muncul yang perlu diketahui, kerana biasanya terdapat penyelesaian yang agak jelas jika ia dikesan tepat pada waktunya.

Salah satu isu yang paling biasa ialah permulaan yang perlahan disebabkan oleh aktiviti jumper . Ini berlaku apabila, selepas niat permulaan (ikon, pemberitahuan, pautan dalam), aktiviti perantaraan dilancarkan yang tidak melukis sebarang bingkai, dan kemudian aktiviti "sebenar" bermula. Dalam jejak, ini muncul sebagai dua peristiwa `activityStart` berturut-turut tanpa kerja visual di antaranya. "Lompatan" ini menambah latensi permulaan tanpa memberikan sebarang nilai. Penyelesaiannya biasanya melibatkan pemfaktoran semula permulaan ke dalam komponen yang boleh diguna semula atau mengintegrasikannya terus ke dalam aktiviti utama.

Satu lagi contoh klasik ialah peruntukan yang tidak perlu yang mencetuskan pengumpulan sampah . Jika Systrace atau profil memori menunjukkan kitaran GC berjalan setiap beberapa saat semasa operasi yang berjalan lama, kemungkinan besar terdapat kod yang berulang kali dan sentiasa memperuntukkan objek dalam gelung intensif. Penyelesaiannya bukanlah untuk mengalih keluar setiap objek baharu, tetapi untuk menangani titik panas, menggunakan semula struktur atau menggunakan corak pengumpulan apabila sesuai.

Bingkai dengan penyekatan juga kerap ditemui dalam saluran grafik . Dalam jejak yang sihat, panggilan ke Choreographer.doFrame() berlaku pada kadens biasa (contohnya, setiap 16,7 ms). Zum masuk pada kawasan dengan kadens ini boleh mendedahkan pandangan yang mahal, susun atur yang terlalu kompleks, operasi I/O yang berjalan pada thread UI atau RecyclerViews yang salah konfigurasi.

RecyclerView merupakan punca kepada pelbagai masalah: membatalkan keseluruhan set data dengan `notifyDataSetChanged()` apabila hanya beberapa elemen yang telah berubah, tidak mengkonfigurasi kolam paparan kitar semula dengan betul dalam RecyclerViews bersarang atau tidak melakukan prapengambilan data yang mencukupi apabila sampai ke penghujung senarai. Semua ini mengakibatkan pemaparan yang mahal, lompatan skrol dan masa menunggu yang ketara untuk pengguna.

Ujian prestasi: jenis, langkah dan amalan terbaik

Selain pemantauan pengeluaran, sebarang strategi yang serius memerlukan pelan pengujian prestasi aplikasi yang mantap dalam persekitaran terkawal. Pengujian ini membolehkan anda mengesahkan kapasiti, kestabilan dan kebolehskalaan sebelum mendedahkan pengguna kepada perubahan atau keluaran baharu.

Terdapat beberapa jenis ujian, setiap satunya mempunyai objektif khusus:

• Ujian bebanMereka menilai tingkah laku aplikasi di bawah beban pengguna atau transaksi yang diramalkan, mengukur masa tindak balas, daya pemprosesan dan penggunaan sumber untuk mengesan kesesakan sebelum penggunaan.
• Ujian tekananMereka mendorong sistem melebihi had normalnya untuk melihat sejauh mana ia boleh didorong, bagaimana ia gagal, dan bagaimana ia pulih. Mereka adalah kunci untuk perancangan kapasiti dan pengurusan puncak jenis Black Friday.
• Ujian ketahanan/rendamanMereka mengekalkan beban yang berterusan selama berjam-jam atau berhari-hari untuk mendedahkan masalah degradasi perlahan, kebocoran memori atau kekurangan sumber.
• Ujian puncakMereka mensimulasikan peningkatan beban secara tiba-tiba dan berulang (cth., kempen, pelancaran ciri, siaran langsung) untuk mengesahkan bahawa aplikasi dan infrastruktur boleh mengendalikan perubahan mendadak.
• Ujian isipaduMereka menganalisis bagaimana aplikasi berfungsi apabila bilangan pengguna meningkat dengan ketara. jumlah data (saiz pangkalan data, fail, mesej), mengesahkan masa tindak balas, kebolehpercayaan storan dan kehilangan data.
• Ujian kebolehskalaanMereka menyemak bagaimana aplikasi bertindak balas apabila beban ditingkatkan secara beransur-ansur, dan sama ada penskalaan secara mendatar atau menegak menghasilkan peningkatan prestasi yang dijangkakan.

Proses pengujian prestasi biasa merangkumi beberapa fasa yang berbeza. Pertama, analisis keperluan : memahami masa tindak balas, nisbah daya pemprosesan, tahap ketersediaan dan had ralat yang boleh diterima untuk perniagaan. Kemudian, fasa perancangan dan strategi di mana skop ujian, persekitaran, alat dan metrik yang akan dipantau ditakrifkan.

Seterusnya, kes ujian direka bentuk untuk merangkumi senario beban yang berbeza, keadaan rangkaian dan jumlah data; persekitaran ujian dikonfigurasikan (perkakasan, perisian, rangkaian, suntikan beban dan alat pemantauan); dan ujian dijalankan, mengumpul data prestasi dengan teliti.

Fasa kritikal ialah pemantauan dan analisis : mengaitkan masa tindak balas dengan penggunaan CPU, latensi rangkaian dengan kadar ralat, lonjakan trafik dengan beban pangkalan data, dan sebagainya. Selepas mendokumentasikan penemuan dalam laporan yang jelas untuk pihak berkepentingan, proses beralih kepada pengoptimuman dan pengujian semula : kod, konfigurasi atau sumber diselaraskan dan ujian diulang sehingga penambahbaikan disahkan.

Alat dan rangka kerja untuk ujian prestasi

Untuk melaksanakan semua perkara di atas, adalah perlu untuk bergantung pada alat ujian prestasi tertentu , baik sumber terbuka mahupun komersial, yang merangkumi automasi, penjanaan beban, pemantauan dan analisis. Beberapa kategori yang berkaitan adalah:

• Alat sumber terbukaProjek seperti Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder atau rangka kerja pengujian unit dan fungsian (JUnit, XCTest, Appium) yang diperluas dengan senario prestasi membolehkan pembinaan suit ujian yang sangat berkuasa dengan kos pelesenan yang rendah.
• Pengujian beban komersial dan alat APMPenyelesaian seperti WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest atau Parasoft menyediakan persekitaran bersepadu dengan penjanaan beban berasaskan awan, pelaporan lanjutan dan sokongan profesional.
• Penyelesaian khusus dan boleh diperhatikanProduk seperti Pengurus Aplikasi, Instana, Dynatrace, IBM Turbonomic atau platform pemantauan rangkaian seperti SolarWinds, yang menumpukan pada pemantauan berterusan, pengesanan anomali dan korelasi antara prestasi aplikasi, infrastruktur dan pengalaman pengguna.
• Alat khusus platformDalam kes Android, sebagai contoh, alat seperti Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace atau metrik bingkai Play Console, membolehkan analisis yang sangat halus terhadap tingkah laku peringkat sistem.

Apabila memilih antara satu atau yang lain, adalah dinasihatkan untuk mempertimbangkan faktor-faktor seperti kemudahan penggunaan, sokongan untuk protokol dan teknologi, kebolehskalaan, integrasi dengan CI/CD , model pelesenan, kebolehpanjangan dan kualiti sokongan (sokongan komuniti atau komersial). Ia juga tidak luar biasa untuk menggabungkan beberapa: satu untuk penjanaan beban, satu lagi untuk APM dan satu lagi untuk kebolehcerapan infrastruktur.

Pendek kata, menganalisis dan memantau prestasi aplikasi memerlukan gabungan metrik yang dipilih dengan baik, alat yang sesuai dan disiplin dalam proses pengujian, tetapi hasilnya lebih daripada sekadar mengimbangi: aplikasi yang lebih pantas, lebih stabil dan lebih cekap , pengguna yang lebih berpuas hati, lebih sedikit insiden pengeluaran dan, sudah tentu, kesan positif langsung terhadap reputasi jenama dan pendapatan.

Artikel berkaitan:

Temui Qt Creator IDE: Persekitaran yang paling berkuasa untuk mencipta apl merentas platform