Kinerja

Kumpulkan harapan pengguna pada tahap definisi produk, kuantifikasi persyaratan bisnis, dan gunakan hal tersebut sebagai dasar untuk arsitektur serta desain produk selanjutnya

Komponen dalam solusi yang dirancang dengan baik dapat diskalakan secara independen; misalnya dengan menambahkan instance layanan lain, namun, menambahkan atau menghapus komponen dapat menimbulkan efek knock-on pada bagian lain dari solusi; misalnya, menambahkan server web lain untuk melayani lonjakan lalu lintas web mungkin memerlukan lebih banyak antrean pesan untuk berkomunikasi dengan layanan back-end. Mengetahui ketergantungan penskalaan sejak awal dapat membantu memahami perilaku operasional solusi serta menghindari kehabisan sumber daya akibat penskalaan berlebihan pada satu sumber daya

Solusi hybrid cloud yang dirancang dengan baik memanfaatkan arsitektur multi-platform untuk strategi penskalaan dan bursting guna mengoptimalkan kinerja serta keamanan, biaya operasi, dan harapan pengguna akhir; misalnya menjalankan beban kerja pada infrastruktur on-premises dengan jaminan kinerja yang kuat dan biaya operasi tetap, lalu melakukan bursting atau penskalaan ke penyedia layanan cloud publik selama periode beban kerja puncak.

Memindahkan data itu mahal. Solusi yang dirancang dengan baik memanfaatkan portabilitas dan mobilitas beban kerja kontainer dengan menempatkan layanan sedekat mungkin dengan data yang mereka konsumsi

Solusi harus memilih platform dan sumber daya yang tepat untuk memaksimalkan nilai arsitekturnya. Solusi hybrid cloud mampu menjangkau beberapa cloud, termasuk lingkungan lokal, yang memberi arsitek kebebasan untuk memilih bauran sumber daya yang optimal guna memenuhi kebutuhan kinerja solusi mereka

Solusi harus dirancang untuk meningkatkan atau mengurangi kapasitas pemrosesan dengan menambahkan atau menghapus unit diskret (server, layanan, antarmuka jaringan, dan sebagainya), bukan dengan mengubah kapasitas unit yang sudah ada, misalnya dengan menambahkan lebih banyak CPU ke server. Untuk mencapai hal ini, solusi harus mengadopsi prinsip-prinsip arsitektur berikut:

• Komponen tanpa status adalah komponen yang tidak mempertahankan status klien atau sesi (misalnya identitas pengguna atau input data yang diberikan pada pemanggilan sebelumnya) di antara interaksi, sehingga menghilangkan dependensi antara klien dan satu instance spesifik dari komponen tersebut. Ketiadaan ketergantungan antara komponen dan konsumennya ini memungkinkan solusi untuk meningkatkan atau menurunkan skala dengan menambahkan atau menghapus instance komponen tanpa berdampak pada konsumen layanan komponen. Contoh yang baik dari komponen stateless adalah kasir di toko kelontong; selama setidaknya ada satu kasir yang tersedia, pembeli dapat melakukan checkout dan membayar bahan makanan mereka, dan kasir dapat ditambahkan atau dikurangi sesuai dengan volume permintaan pembeli. Sebaliknya, bayangkan jika pembeli ditugaskan ke kasir tertentu di awal perjalanan belanja mereka. Jika kasir yang ditugaskan menjadi macet atau, lebih buruk lagi, tidak tersedia, pembeli harus menunggu atau memulai dari awal, dan kinerja keseluruhan toko kelontong (diukur dalam jumlah pembeli per jam) akan menurun.

• Hindari tugas yang berjalan lama. Jika solusi harus mendukung tugas yang berjalan lama (misalnya melakukan perhitungan ilmiah yang kompleks), tugas tersebut harus dirancang untuk mendukung penskalaan masuk atau keluar melalui mekanisme interupsi dan fasilitas checkpoint yang memungkinkan solusi menghentikan dan memulai kembali tugas ketika sumber daya ditambahkan atau dihapus dari solusi.

• Data berada di bagian ujung. Komponen tanpa status secara teori dapat diskalakan tanpa batas dan dapat digunakan kembali oleh berbagai klien. Solusi berkinerja tinggi mendorong state yaitu data pengguna dan aplikasi ke aplikasi klien serta basis data di ujung arsitektur solusi, dan tidak menyimpan state pada lapisan arsitektur perantara.

Sumber daya:
Dengan status vs Tanpa status

Merancang solusi sebagai sekumpulan komponen yang sangat kohesif dan digabungkan secara longgar memungkinkan komponen untuk diskalakan secara independen sesuai dengan permintaan layanan yang mereka berikan. Pendekatan arsitektur seperti arsitektur berorientasi layanan, dan layanan mikro menanamkan praktik ini sebagai prinsip desain inti, yaitu sekumpulan layanan yang sangat kohesif yang berkomunikasi melalui API tingkat tinggi yang digabungkan secara longgar.

Memindahkan data antar komponen solusi sering kali merupakan elemen transaksi yang paling memakan waktu. Komponen harus dirancang untuk mengoptimalkan frekuensi dan volume komunikasi sesuai dengan bandwidth yang tersedia. Misalnya, aplikasi yang melakukan panggilan berulang untuk mengambil nilai individual dari database mungkin berkinerja “cukup baik” ketika digunakan di jaringan lokal, tetapi dapat mengalami penurunan kinerja ketika komponen database dipindahkan ke penyedia layanan cloud.

Gaya arsitektur transfer keadaan representasional (REST) yang umum digunakan dalam aplikasi berbasis web merupakan contoh yang baik dari keseimbangan yang ditunjukkan oleh solusi yang dirancang dengan baik; status representatif penuh dari suatu sumber daya ditransfer sebagai dokumen JSON, XML, atau format lainnya yang menyeimbangkan jumlah informasi yang ditransfer dengan latensi tinggi dari interaksi berbasis web.

Caching membantu membatasi permintaan terhadap sumber daya dan layanan yang menghasilkan data. Pertimbangkan penggunaan caching untuk data yang berumur panjang, relatif statis, dan/atau data yang 'mahal' untuk diproduksi. Solusi yang dirancang dengan baik menerapkan mekanisme caching di seluruh lapisan arsitektur solusi menempatkan cache sedekat mungkin dengan konsumen untuk membatasi komunikasi antara konsumen dan cache serta meningkatkan waktu respons secara keseluruhan.

Arsitek perlu mengingat bahwa caching dapat menjadi berlebihan. Mekanisme caching yang dirancang dengan buruk atau cache yang terlalu besar dapat memengaruhi kinerja solusi secara keseluruhan. Arsitek harus mengevaluasi jenis serta strategi caching, kemudian mengukur efektivitas cache selama pengujian dan analisis kinerja.

Pesan asinkron yang menggunakan antrean pesan, model callback, atau mekanisme lain memungkinkan solusi untuk menskalakan secara efisien serta menurun dengan baik di bawah beban ketika sumber daya habis. Solusi yang dirancang dengan baik memanfaatkan komunikasi yang tidak sinkron, terutama antrean pesan, untuk memberikan pengalaman yang responsif kepada pengguna akhir dan untuk menghindari 'kehilangan' permintaan pengguna ketika komponen gagal. Mekanisme yang sama juga dapat digunakan untuk menghubungkan sistem yang memiliki tingkat layanan atau jam operasi yang berbeda; misalnya aplikasi 24x7 yang terhubung ke sistem catatan 9 hingga 5 dengan antrean pesan memungkinkan aplikasi menerima permintaan pengguna akhir bahkan ketika sistem catatan tidak tersedia.

Solusi berubah seiring waktu, dan kinerjanya dapat berubah bersamanya. Membangun instrumentasi kinerja yang memungkinkan tim pengembangan, pengujian, dan operasi mengumpulkan metrik kinerja aplikasi secara non-intrusif membantu mengembangkan dan menguji produk yang kuat dengan menggunakan metode berbasis bukti. Instrumentasi juga membantu dalam functional testing, analisis cacat, dan menjadi bantuan yang sangat berharga untuk mempertahankan kinerja solusi serta membantu menentukan sumber masalah kinerja dalam produksi. Instrumentasi yang dapat dikonfigurasi dan non-intrusif mendukung pemantauan produk, memastikan observabilitas solusi dalam operasi sehingga mendukung tim DevOps dan SRE.

Dari perspektif bisnis, kinerja solusi secara keseluruhan sangat penting dan harus tercermin dalam persyaratan non-fungsional yang holistik. Namun, untuk pengujian kinerja tingkat unit, pengujian kinerja awal yang menerapkan paradigma shift-left serta analisis akar penyebab masalah kinerja mungkin memerlukan penetapan persyaratan tingkat rendah, seperti membatasi durasi panggilan individual, latensi jaringan, dan sebagainya.

Jadi, persyaratan kinerja tingkat tinggi biasanya ditentukan pada tingkat proses atau transaksi, misalnya "Proses asal pinjaman harus selesai dalam waktu kurang dari 2 menit", tanpa memperhatikan bagaimana kinerja langkah-langkah proses individual dan subproses berkontribusi terhadap hasil akhir. Menyusun anggaran kinerja yang mengalokasikan target untuk setiap langkah dalam proses pada tahap pengembangan memberikan target yang terukur bagi tim pengembangan fitur, membantu mengidentifikasi area masalah yang potensial, serta memfokuskan upaya pengoptimalan dan remediasi kinerja pada area yang paling memberikan manfaat.

Anggaran kinerja harus mempertimbangkan semua lapisan solusi, mulai dari perangkat keras hingga kode aplikasi. Mengabaikan salah satu lapisan tersebut berisiko membuat solusi tidak mampu memenuhi harapan pengguna.

Saat menguji kinerja, buktinya ada pada hasilnya; hanya dengan menguji solusi secara menyeluruh kita dapat memastikan bahwa solusi tersebut memenuhi persyaratannya. Hal ini mencerminkan sifat holistik dari analisis kinerja. Pengujian komponen individual (misalnya database, middleware, dan sebagainya) memberikan insight yang berharga terhadap analisis kinerja solusi serta membantu mengidentifikasi kemacetan kinerja. Namun, pengujian komponen saja tidaklah cukup, karena interaksi antar komponen dapat menyebabkan kemacetan yang tidak terduga atau hambatan lain yang dapat menghasilkan hasil yang tidak optimal.

Berfokus pada persepsi pengguna berarti terutama memperhatikan waktu respons yang dirasakan serta respons keseluruhan antarmuka pengguna. Penurunan kapasitas biasanya tidak terlihat oleh pengguna sampai kinerja produk mulai terpengaruh. Sebuah studi pada tahun 1968 menemukan bahwa terdapat tiga urutan besaran yang berbeda dalam interaksi manusia-komputer:

• Waktu respons 100 ms dianggap instan. Manusia memiliki waktu reaksi rata-rata sekitar 250 ms, sehingga respons yang berada di bawah nilai tersebut dianggap sangat cepat atau seketika.
• Waktu respons 1 detik atau kurang umumnya cukup cepat sehingga pengguna merasa tidak diperlambat oleh kinerja sistem.
• Waktu respons lebih dari 10 detik menyebabkan pengguna benar-benar kehilangan perhatian.

Dari sini disimpulkan bahwa waktu respons 2 detik akan menjadi ideal, sehingga 2 detik atau sedikit lebih merupakan target waktu respons yang baik untuk hybrid cloud, jika memungkinkan. Tentu saja, harapan pengguna bergantung pada apa yang mereka lakukan, misalnya, tidak ada yang mengharapkan animasi penekanan tombol berlangsung selama 2 detik, tetapi 2-3 detik merupakan target umum yang baik untuk aplikasi yang menghadap pengguna.

Berangkat dari prinsip ini, solusi harus menggabungkan pengujian waktu respons pengguna sebagai bagian dari siklus jaminan kualitas dengan menggunakan alat pengujian antarmuka pengguna. Meskipun latensi panggilan API penting bagi kinerja produk secara keseluruhan, kinerja yang dirasakan oleh pengguna merupakan faktor kunci dalam menarik dan mempertahankan basis pengguna.

Pengguna sering memiliki harapan yang berbeda tentang apa yang dianggap sebagai kinerja ’baik’. Misalnya, 'power user' yang menggunakan aplikasi beberapa kali sehari setiap hari memiliki ekspektasi kinerja yang sangat berbeda dibandingkan seseorang yang menggunakan aplikasi yang sama mungkin hanya sebulan sekali. Pengguna juga sering kesulitan mengukur apa arti kinerja “baik” bagi mereka, sehingga sering terjebak pada persyaratan seperti “cukup cepat” (yang merupakan target yang sulit untuk dipenuhi). Selain itu, persepsi individu terhadap kinerja produk yang menghadap pengguna dapat berbeda-beda. Misalnya, bagi sebagian orang waktu login 10 detik masih dapat diterima (terutama jika itu merupakan kejadian tunggal), sementara bagi yang lain hal tersebut mungkin terlalu lambat (terutama jika login sering menjadi bagian dari alur kerja).

Untuk membantu mengukur dan mengelola harapan pengguna, disarankan untuk:

•  Buat persyaratan non-fungsional dengan pemahaman yang baik tentang basis pengguna serta pola penggunaan aplikasi yang khas.
  
  
•  Hubungi pengguna pada awal siklus desain solusi untuk memahami fitur mana yang paling sering mereka gunakan dan yang mereka harapkan memiliki daya tanggap tinggi, serta fitur mana yang lebih jarang digunakan sehingga dapat mentoleransi waktu respons yang lebih lambat
  .
  
• Gunakan persentil untuk menentukan ambang waktu respons rata-rata atau median. Hal ini memungkinkan beberapa variasi acak yang tak terhindarkan dari respons produk dan memastikan bahwa beberapa outlier tidak menyebabkan kegagalan penerimaan produk secara keseluruhan.
  
  
•  Sertakan pengujian waktu respons yang realistis serta masukan dalam rilis dan pratinjau awal solusi. Pengujian kinerja yang ditunda hingga akhir pengembangan solusi terkadang dapat menyebabkan tim tidak mampu mengatasi masalah kinerja tanpa harus membatalkan bagian signifikan dari arsitektur solusi. Memperbaiki masalah kinerja pada akhir siklus pengembangan sangat mahal.
  
  
• Pastikan desain UI menyertakan elemen seperti spinner dan bilah status, sehingga pengguna menyadari bahwa aplikasi sedang berjalan dan berkinerja. Hal ini membantu menghindari frustrasi yang tidak perlu akibat persepsi bahwa kinerja produk lambat.
  
  
• Jika diperlukan, lakukan riset terhadap solusi serupa dan yang ’terbaik di kelasnya,’ analisis tren industri serta publikasi terkait, dan wawancara pakar materi untuk menetapkan target waktu respons dan kapasitas yang tepat.

Monitor dan berkomunikasi batas kinerja kepada klien.

Penyalahgunaan atau kesalahan konfigurasi produk atau komponen solusi dapat menjadi sumber kinerja yang buruk serta pengalaman pengguna yang negatif. Untuk menghindari situasi ini, arsitek harus:

• Waspadai kendala kinerja dalam solusi dan komunikasikan secara proaktif kepada pengguna. Misalnya, jika solusi menggunakan saluran komunikasi yang lambat atau berbandwidth rendah, arsitek harus membuat pengguna akhir memahami bahwa mengunduh gambar beresolusi tinggi dapat mengalami gangguan.

• Memungkinkan sistem untuk mendeteksi dan mengomunikasikan ketika permintaan berada di luar parameter desain solusi jika memungkinkan. Misalnya, mintalah sistem secara aktif memperingatkan pengguna ketika mereka mencoba mengunduh file besar melalui saluran yang lambat.

Pendekatan umum dalam pengujian kinerja adalah menguji apakah solusi memenuhi target waktu respons pada beban maksimum yang diharapkan. Asumsinya adalah bahwa jika solusi berkinerja baik pada beban maksimum tersebut, maka solusi juga akan berkinerja baik pada beban yang lebih rendah. Tantangan dari pendekatan ini adalah bahwa metode tersebut hanya menyediakan satu titik data pada beban puncak yang diuji, sehingga hampir menyerupai pengujian lulus/gagal.

Solusi yang dirancang dengan baik diuji menggunakan pendekatan eksploratif untuk mengevaluasi daya tanggapnya pada berbagai tingkat beban yang bervariasi dalam ukuran, campuran jenis pengguna, serta campuran fungsi yang diuji. Pendekatan ini memberikan informasi yang bernilai dan bersifat multi-dimensi bagi tim solusi mengenai bagaimana komponen solusi saling berinteraksi dalam memengaruhi kinerja, potensi hambatan yang muncul, serta cara menskalakan solusi untuk menangani beban kerja yang lebih kecil maupun lebih besar.

Pendekatan ini memungkinkan penghindaran pengujian tambahan jika target beban yang diharapkan berubah dan terdapat kebutuhan untuk mengumpulkan metrik kinerja pada kondisi beban yang berbeda. Interpolasi atau ekstrapolasi dependensi kinerja yang ada terhadap besaran beban memungkinkan perhitungan metrik kinerja untuk setiap tingkat beban dalam spektrum yang awalnya diuji (mulai dari nol hingga titik breakpoint, dan seterusnya).

Pendekatan tipikal untuk pengujian kinerja mengikuti pola yang disederhanakan, yaitu “mengukur waktu respons pada beban/throughput tertentu”. Pendekatan ini menjawab pertanyaan apakah waktu respons transaksi utama pada tingkat beban puncak memenuhi perjanjian tingkat layanan (SLA) yang ditetapkan. Biasanya, tingkat beban yang diuji terbatas pada kategori "low", "peak", dan "stress". Pendekatan ini dapat menjawab pertanyaan mengenai waktu respons pada beban normal, tetapi tidak memberikan gambaran yang lengkap tentang kinerja sistem dalam berbagai situasi operasional yang mungkin terjadi.

Pendekatan *Pengujian Kinerja Eksplorasi* yang lebih canggih menargetkan pembuatan *Performance Snapshot* dari solusi yang diuji. Snapshot ini mencakup serangkaian metrik kinerja yang komprehensif, yang dikumpulkan pada spektrum beban terluas yang didukung - mulai dari pengukuran pengguna tunggal hingga beban pasca-breakpoint (jika memungkinkan, kecuali ketika sistem mengalami crash). Hal ini mencakup kumpulan waktu respons transaksi, throughput transaksi dan data, serta data konsumsi sumber daya yang dikumpulkan pada kondisi beban yang terus meningkat. Dengan istilah "transaksi", yang dimaksud adalah bagian kerja yang dibatasi oleh sistem - mulai dari transaksi makro seperti Login atau Update Account, hingga sub-transaksi individual (seperti panggilan autentikasi dalam transaksi Login), atau klik http sederhana.

Kumpulan data kinerja yang komprehensif, *Performance Snapshot*, mencakup metrik kinerja tersebut untuk berbagai rentang beban: rentang “linear” pada beban rendah (di mana utas yang diproses secara individual tidak merasakan keberadaan satu sama lain dan waktu respons tidak meningkat seiring meningkatnya beban), rentang "non-linear" di mana waktu respons meningkat seiring bertambahnya beban, titik jenuh di mana throughput berhenti meningkat meskipun beban ditambah dan mencapai tingkat jenuh, serta rentang pasca-breakpoint di mana kinerja menurun setelah throughput mencapai maksimum dan waktu respons melampaui tingkat SLA.

Mencakup berbagai tingkat beban biasanya tidak memerlukan lebih banyak upaya dari tim pengujian dibandingkan hanya melakukan pengujian pada tingkat "peak" dan "stress" serta pengujian ketahanan, karena skrip pengujian yang sama digunakan (dan upaya utama biasanya adalah membuat skrip tersebut). Namun, keuntungan dari pembuatan kinerja snapshot tersebut adalah sebagai berikut:

• Tidak perlu menghabiskan waktu dan usaha untuk mencoba menebak pengaturan pengujian yang tepat yang menghasilkan throughput transaksi yang 'tepat' ("peak" atau "stress"); cukup tingkatkan beban Anda dan cakup *semua* tingkat beban serta throughput yang didukung.

• Seseorang dapat menentukan pada tingkat beban berapa waktu respons mulai meningkat, pada titik mana waktu respons melampaui tingkat SLA, serta pada titik mana throughput mencapai tingkat maksimum.

• Hal ini memungkinkan pengukuran kapasitas sistem secara langsung, misalnya besaran beban pada saat kondisi breakpoint tercapai (ketika waktu respons melampaui SLA, throughput mencapai tingkat maksimum, atau penggunaan sumber daya sistem memasuki 'zona merah' yang ditentukan misalnya penggunaan CPU mencapai 90%, atau sistem mengalami crash - mana pun yang terjadi terlebih dahulu). Dengan demikian, tidak perlu lagi menggunakan pendekatan berbasis perkiraan dalam analisis dan perencanaan kapasitas.

• Jika kondisi operasi produksi yang diharapkan berubah (misalnya beban rata-rata dan puncak yang diharapkan ditentukan ulang oleh bisnis), tidak perlu menjalankan kembali pengujian kinerja: metrik kinerja yang dibutuhkan untuk besaran beban yang berbeda dapat dengan mudah diperoleh melalui interpolasi atau ekstrapolasi dari hasil pengujian yang sudah ada.

• Meliputi seluruh spektrum beban, alih-alih hanya beberapa tingkat yang telah ditentukan, memungkinkan kita memastikan bahwa kita memiliki pandangan menyeluruh tentang kinerja sistem dan tidak melewatkan potensi masalah kinerja yang mungkin muncul jika produk tidak diuji pada kondisi ekstrem.

• Memastikan bahwa pengujian mencakup pencapaian titik henti kinerja sistem berarti kita mengetahui di mana hambatan kinerja terjadi, serta tautan, komponen, atau lapisan mana yang akan gagal terlebih dahulu ketika beban meningkat. Hal ini memungkinkan pemberian masukan yang berguna dan berbasis bukti kepada tim arsitektur dan desain untuk meningkatkan ketahanan serta kinerja produk.

Ada beberapa jenis pengujian kinerja yang dapat dijalankan pada suatu solusi. Solusi yang dirancang dengan baik memanfaatkan semuanya.

• Tolok ukur manual adalah sebagaimana tersirat dari namanya: menjalankan fungsi solusi secara manual untuk memperoleh gambaran langsung tentang bagaimana solusi merespons pengguna.
• Tes kalibrasi adalah pengujian yang dilakukan untuk membandingkan hasil alat pengujian otomatis dengan sumber lain, seperti pengujian manual atau metrik kinerja bawaan, guna memvalidasi kebenaran skrip pengujian dan hasil alat pengujian.
•  Uji rendam, atau uji daya tahan, adalah pengujian solusi di bawah beban dalam jangka waktu yang lama untuk memastikan bahwa solusi tetap stabil di bawah beban dan tidak mengalami penurunan kinerja seiring waktu, dapat dioperasikan secara andal, serta menunjukkan konsumsi sumber daya yang diharapkan (yaitu tidak terjadi kebocoran memori).
• Tes puncak menguji solusi di bawah beban kerja puncak yang diharapkan, misalnya pada hari tersibuk dalam setahun, untuk memastikan stabilitas solusi serta mengumpulkan metrik utama seperti waktu respons dan konsumsi sumber daya di bawah beban maksimum yang diperkirakan.
• Tes stres dan lonjakan digunakan untuk menguji solusi pada kelipatan (misalnya 2x atau 3x) dari beban puncak yang diharapkan selama interval pendek (uji stres) atau bahkan beban yang lebih tinggi untuk waktu yang sangat singkat (uji lonjakan). Pengujian ini membantu mengidentifikasi hambatan dalam solusi serta membantu tim solusi mengenali dependensi penskalaan dalam solusi.
• Pengujian beban variabel, atau uji breakpoint digunakan untuk menguji solusi di bawah berbagai tingkat beban guna memahami kinerja solusi pada berbagai besaran beban serta membantu tim solusi menemukan tren dan batas sumber daya dalam solusi. Pengujian ini juga memungkinkan untuk mengidentifikasi titik henti produk, mengukur kapasitas solusi, dan mendeteksi komponen terlemah dalam produk (yang paling mungkin mengalami kegagalan).

Bertujuan untuk memperoleh hasil maksimal dari berbagai data kinerja yang diperoleh selama pengujian:

• Terapkan metode kreatif dan eksploratif untuk menganalisis hasil pengujian. Gunakan pendekatan *what-if* untuk mengeksplorasi skenario tambahan.
• Petakan hasil kinerja ke lingkungan dengan ukuran dan arsitektur yang berbeda untuk memprediksi kinerja solusi pada berbagai platform dan penerapan.
• Tangkap setiap inkonsistensi dalam data kinerja yang diperoleh dengan mendeteksi pola dan tren yang tidak terduga (misalnya *meningkatkan* beban justru menghasilkan *berkurangnya* tingkat transaksi).
• Gunakan teknik pemodelan untuk menghubungkan kapasitas sistem yang diukur dengan ukuran basis pengguna yang sesuai berdasarkan pola penggunaan yang diasumsikan.
• Selalu ingat untuk menilai dampak kinerja timbal balik dari berbagai alur kerja yang dapat dieksekusi secara bersamaan dalam produksi.
• Gunakan berbagai sumber data kinerja: mulai dari proyek percontohan hingga pengujian unit dan fungsional, sampai sinyal emas DevOps dan SRE. Setiap sumber data memiliki nilai dalam analisis kinerja.
• Bagikan hasil analisis secara lebih sering dengan para pemangku kepentingan. Hal ini sering membantu memperoleh input yang berguna dari pihak lain, meningkatkan kesadaran tentang kemajuan pengujian kinerja dan analisis, membantu orang lain lebih memahami area *teknis* seperti kinerja dan kapasitas, serta meningkatkan visibilitas upaya validasi non-fungsional secara keseluruhan.