Panduan ini menetapkan persyaratan teknis untuk perencanaan dan pelaksanaan pengujian kinerja dengan Performance Testing Service (PTS). Ikuti persyaratan ini untuk mengevaluasi kapasitas sistem Anda dalam kondisi nyata, mencegah risiko di lingkungan produksi, serta memvalidasi bahwa infrastruktur Anda mampu menangani pola lalu lintas yang diharapkan.
Lingkup
Persyaratan ini berlaku untuk semua proyek yang melibatkan pengujian kinerja. Panduan ini mencakup:
Lingkungan sistem
Metrik pengujian
Model bisnis dan model pengujian
Volume data
Jenis pengujian
Sesi dan skenario bisnis
Pemantauan dan analisis bottleneck
Tuning
Uji stres terdistribusi dengan PTS
Lingkungan sistem
Pilih lingkungan
Lingkungan sistem diklasifikasikan menjadi lingkungan produksi, pengujian, dan lingkungan lainnya. Pengujian kinerja biasanya dijalankan di lingkungan produksi atau lingkungan pengujian khusus. Masing-masing memiliki kelebihan dan kekurangan:
| Environment | Advantages | Disadvantages |
|---|---|---|
| Production | Pengukuran akurat terhadap infrastruktur nyata | Memerlukan pembersihan data pengujian; berisiko terhadap layanan aktif jika tidak dijadwalkan dengan hati-hati |
| Test | Terisolasi dari lalu lintas aktif; risiko terkendali | Mahal untuk mereplikasi produksi dalam skala penuh; hasil mungkin tidak mencerminkan perilaku produksi |
Production environment: Jalankan uji stres selama jam sepi untuk menghindari gangguan pada layanan aktif. Uji stres full-link Alibaba Cloud menyediakan pendekatan yang lebih efisien untuk pengujian di lingkungan produksi. Setelah pengujian, bersihkan data pengujian atau saring dari laporan Business Intelligence (BI).
Test environment: Bangun dalam skala sebagian dari produksi—biasanya setengah, seperempat, atau seperdelapan. Strategi umum meliputi penerapan kluster pengujian terpisah untuk aplikasi tertentu dalam produksi, atau berbagi database antarlingkungan. Impor data termasuk dari produksi (biasanya 6 hingga 12 bulan terakhir) untuk menjaga relevansi data.
Persyaratan lingkungan pengujian
Sesuaikan lingkungan pengujian sedekat mungkin dengan produksi:
| Requirement | Details |
|---|---|
| Architecture | Arsitektur sistem yang sama dengan produksi |
| Instance specifications | Tipe instans Elastic Compute Service (ECS) atau spesifikasi kontainer yang sama |
| Software versions | Versi sistem operasi, middleware, database, dan aplikasi yang sama |
| Configuration parameters | Parameter sistem operasi, middleware, database, dan aplikasi yang sama |
| Data volume | Orde besaran yang sama dengan produksi |
| Scaling approach | Kurangi jumlah load generator dan turunkan skala sumber daya lainnya secara proporsional. Targetkan setengah atau seperempat konfigurasi produksi |
Investigasi lingkungan pengujian
Sebelum pengujian, investigasi setiap lapisan lingkungan pengujian untuk menetapkan garis dasar pemantauan dan analisis bottleneck:
| Layer | What to investigate | Purpose |
|---|---|---|
| System architecture | Komposisi sistem, fungsi lapisan, perbedaan dari produksi | Analisis bottleneck dan evaluasi kinerja produksi |
| Operating system | Platform dan versi OS | Pemantauan Alat |
| Middleware | Jenis dan versi middleware | Pemantauan tool dan analisis bottleneck |
| Database | Jenis dan versi database | Pemantauan tool dan analisis bottleneck |
| Application | Instans yang berjalan dan parameter-parameternya | Deteksi masalah dan analisis bottleneck |
Gunakan tool Application Performance Management (APM) seperti Application Real-Time Monitoring Service (ARMS) untuk melacak masalah di lapisan middleware, database, dan aplikasi.
Metrik pengujian
Kategori metrik
Lacak metrik dalam empat kategori:
| Category | Key metrics |
|---|---|
| Business | Pengguna konkuren, transaksi per detik (TPS), tingkat keberhasilan, waktu respons (RT) |
| Resource | Utilisasi CPU, utilisasi memori, I/O disk, I/O jaringan, parameter kernel (semaphore, jumlah file terbuka) |
| Application | Thread idle, koneksi database, jumlah garbage collection (GC), jumlah full GC, durasi metode |
| Frontend | Waktu pemuatan halaman, waktu resolusi DNS, waktu koneksi, waktu transfer |
Tentukan ambang batas metrik
Tentukan ambang batas untuk setiap metrik sebelum pengujian. Tanpa ambang batas yang jelas, hasil pengujian tidak memiliki makna yang dapat ditindaklanjuti—pemangku kepentingan berbeda (pengembangan, operasi, bisnis) memiliki ekspektasi berbeda dan memperhatikan metrik yang berbeda.
Tolok ukur metrik bisnis:
| Metric | Guideline |
|---|---|
| Response time (RT) | Pertahankan di bawah 1 detik untuk sebagian besar layanan. Sistem berkinerja tinggi seperti Taobao biasanya mencapai RT dalam puluhan milidetik. Tentukan apakah ambang batas Anda berlaku untuk nilai rata-rata, median, p95, atau p99—mengagregasi waktu respons sebagai rata-rata sederhana dapat menyembunyikan lonjakan latensi yang memengaruhi pengguna nyata |
| TPS | Bervariasi tergantung skala sistem: 50–1.000 untuk usaha kecil-menengah, 1.000–50.000 untuk bank, 30.000–300.000 untuk platform bertrafik tinggi seperti Taobao |
| Success rate | Standar industri melebihi 99,6% di bawah beban |
Pedoman metrik sumber daya:
Batasi utilisasi CPU hingga 75% atau di bawahnya
Hindari penggunaan partisi swap sepenuhnya
Idealnya, ketika sistem mencapai batas kapasitasnya, sumber daya (CPU, memori, I/O) harus menjadi bottleneck, bukan masalah di tingkat aplikasi. Menambahkan sumber daya pada sistem yang dibatasi oleh sumber daya akan meningkatkan kapasitasnya; menambahkan sumber daya pada sistem yang dibatasi oleh aplikasi tidak akan berdampak
Model bisnis
Peran model bisnis
Setiap operasi bisnis (login, pencarian, checkout, pembayaran) mengonsumsi jumlah sumber daya sistem yang berbeda. Kombinasi jenis bisnis dan proporsi relatifnya menentukan kapasitas sistem secara keseluruhan. Jika campuran lalu lintas pengujian tidak sesuai dengan produksi, hasilnya tidak memiliki nilai praktis.
Sebagai contoh, dalam e-commerce, jenis promosi dan kategori produk yang berbeda mengubah rasio operasi yang banyak membaca (read-heavy) versus banyak menulis (write-heavy). Pemodelan lalu lintas yang akurat di PTS menangkap pola-pola ini dan mengungkap bottleneck sistem yang sebenarnya.
Pilih jenis bisnis
Pilih operasi bisnis ber-volume tinggi, berisiko tinggi, dan pertumbuhan tinggi sebagai kasus uji representatif.
Untuk sistem yang sudah berjalan di produksi:
Kumpulkan jenis dan volume bisnis pada periode puncak yang berbeda. Jika campuran tersebut sangat bervariasi antarperiode, definisikan beberapa model bisnis
Identifikasi jendela waktu dengan konsumsi sumber daya tinggi atau anomali selama jam puncak, lalu investigasi akar penyebabnya
Tinjau insiden produksi sebelumnya. Jika suatu insiden disebabkan oleh operasi bisnis yang tidak termasuk dalam pengujian sebelumnya, tambahkan ke model pengujian mendatang
Untuk sistem yang belum berjalan di produksi:
Tentukan jenis bisnis dan proporsinya melalui wawancara pemangku kepentingan dan analisis kebutuhan
Nilai apakah operasi bisnis tertentu dapat melonjak selama promosi atau acara tertentu
Setelah pengujian awal, tinjau konsumsi sumber daya per operasi. Jika operasi dengan proporsi rendah mengonsumsi sumber daya secara tidak proporsional, sesuaikan bobotnya dalam model
Volume data
Volume data dasar
Volume data dasar mengacu pada data yang sudah ada di database—catatan historis, data referensi, dan data bisnis yang terakumulasi. Volume data yang ada secara langsung memengaruhi kinerja kueri: pencarian di ribuan catatan berperilaku sangat berbeda dibandingkan pencarian di jutaan catatan.
Persyaratan:
Sesuaikan volume data lingkungan pengujian dengan orde besaran yang sama seperti produksi
Pertimbangkan pertumbuhan data selama tiga tahun ke depan. Jika data tumbuh pesat, muat data tambahan ke lingkungan pengujian
Saat memasukkan akun pengujian ke lingkungan produksi, rencanakan logika persiapan dan pembersihan data secara menyeluruh
Uji stres full-link juga memerlukan orde besaran yang sama antara lingkungan pengujian dan produksi
Volume data terparameterisasi
Data terparameterisasi menggerakkan variabilitas input pengujian (ID pengguna, ID produk, kata kunci pencarian). Set parameter kecil menyebabkan cache hit yang menggelembungkan hasil kinerja.
Persyaratan:
Maksimalkan volume data terparameterisasi. Jika diperlukan, bersihkan cache atau hasilkan data tambahan secara programatik
Distribusikan data terparameterisasi secara realistis. Jika operasi bisnis memiliki pola distribusi geografis (misalnya, kueri inventaris berbasis wilayah), refleksikan hal tersebut dalam data pengujian
Model pengujian
Model pengujian diturunkan dari model bisnis. Dalam kebanyakan kasus, keduanya identik. Namun, jika operasi bisnis tidak dapat disimulasikan (karena kendala teknis atau kebijakan keamanan), hapus dari model pengujian dan hitung ulang proporsi yang tersisa.
Jika operasi yang dihapus membawa risiko signifikan (misalnya, alur pembayaran), evaluasi risiko tersebut secara terpisah. Jika risikonya tinggi, cari pendekatan pengujian alternatif daripada hanya mengeluarkannya.
Jenis pengujian
Jenis pengujian kinerja terbagi menjadi dua kategori luas—load testing dan stress testing—dengan beberapa varian khusus:
| Test type | VUs / throughput | Duration | When to use | Required? |
|---|---|---|---|---|
| Single-transaction benchmark testing | Rendah | Singkat | Menetapkan kinerja dasar untuk operasi individual | Opsional |
| Single-transaction load testing | Bertahap | Sedang | Mengevaluasi konsumsi sumber daya untuk operasi tertentu. Direkomendasikan untuk sistem yang belum berjalan di produksi | Opsional |
| Mixed-transaction load testing (capacity testing) | Rata-rata produksi | Sedang hingga panjang | Menentukan kapasitas sistem keseluruhan di bawah beban kerja campuran yang realistis | Required |
| Mixed-transaction stress testing | Di atas rata-rata | Sedang | Menemukan titik patah dengan mendorong beban melebihi puncak yang diharapkan | Opsional |
| Business mutation testing | Lonjakan pada satu operasi | Singkat | Memvalidasi perilaku sistem saat operasi tertentu melonjak secara tak terduga | Opsional |
| Mixed-transaction stability testing | Rata-rata produksi | Panjang (jam+) | Memverifikasi kinerja berkelanjutan selama periode panjang | Required |
| Mixed-transaction reliability testing | Rata-rata produksi | Panjang | Menguji failover, pemulihan, dan degradasi di bawah kondisi gangguan | Opsional |
| Batch testing | Bervariasi | Bervariasi | Mengukur kinerja pemrosesan batch | Opsional |
| Batch impact testing on mixed transactions | Campuran | Panjang | Menilai bagaimana pekerjaan batch memengaruhi kinerja transaksi online konkuren | Opsional |
Strategi progresi
Mulai dengan jenis pengujian yang lebih sederhana dan lanjutkan ke yang lebih kompleks. Jalankan benchmark single-transaction terlebih dahulu untuk menetapkan garis dasar, lalu lanjutkan ke load testing transaksi campuran, kemudian ke pengujian stres dan stabilitas. Minimal, jalankan dua jenis yang wajib: mixed-transaction load testing dan mixed-transaction stability testing.
Tidak ada satu jenis pengujian pun yang mengungkap semua risiko. Jenis pengujian berbeda menargetkan mode kegagalan berbeda. Prioritaskan berdasarkan profil risiko sistem Anda.
Sesi bisnis
Sesi bisnis adalah urutan terurut panggilan API yang merepresentasikan alur kerja pengguna lengkap. Sebagai contoh, sesi e-commerce khas mungkin mengikuti pola berikut:
Jelajahi katalog produk
Cari produk tertentu
Buka halaman detail produk
Tambahkan item ke keranjang
Login
Selesaikan checkout
Lakukan pembayaran
Akurasi sesi ini secara langsung memengaruhi seberapa baik pengujian mencerminkan kinerja dunia nyata.
Persyaratan:
Rancang sesi berdasarkan aturan bisnis produksi aktual dan alur kerja pengguna
Sertakan jeda realistis antarlangkah untuk mensimulasikan waktu berpikir pengguna. Tanpa waktu berpikir, pengujian menghasilkan laju permintaan tidak realistis yang tidak sesuai dengan pola lalu lintas produksi
Tambahkan checkpoint (assertion) pada titik-titik kunci untuk memverifikasi tanggapan server. Untuk detailnya, lihat Parameter respons antarmuka
Parameterisasi semua data variabel (kredensial pengguna, ID produk, kueri pencarian) dan maksimalkan volume datanya
Skenario
Skenario uji stres menggabungkan beberapa panggilan API HTTP/HTTPS atau URL menjadi workload yang mensimulasikan lalu lintas produksi nyata. Setiap skenario menetapkan profil beban: mode tekanan, metode ramp-up, dan durasi.
Persyaratan kritis: Proporsi TPS setiap operasi bisnis dalam pengujian harus sesuai dengan proporsi bisnis aktual selama jam puncak produksi.
Mode RPS dan mode konkurensi
PTS mendukung dua mode beban. Pilih mode yang sesuai dengan cara sistem Anda menerima lalu lintas nyata:
Open workload model (mode RPS – direkomendasikan): Anda mengontrol laju kedatangan permintaan. Gunakan mode ini ketika sistem Anda menghadapi lalu lintas masuk yang tidak terkendali, seperti aplikasi web publik. Ini adalah skenario paling umum.
Closed workload model (mode konkurensi): Anda mengontrol jumlah pengguna konkuren. Gunakan mode ini ketika sistem Anda mengontrol akses masuk, seperti call center dengan jumlah agen tetap.
Jika sistem nyata Anda merupakan open workload tetapi Anda menguji dengan closed workload model, hasil pengujian tidak mencerminkan perilaku produksi sebenarnya. Model konkurensi secara implisit mengatur laju permintaan berdasarkan waktu respons, yang menyembunyikan masalah kinerja yang muncul di bawah kondisi lalu lintas nyata.
Contoh: Dua antarmuka A dan B memiliki rasio produksi 1:4, dengan waktu respons masing-masing 1 ms dan 100 ms.
| Mode | Configuration | Result |
|---|---|---|
| RPS mode (recommended) | Atur A ke 100 RPS, B ke 400 RPS | Rasio langsung 1:4. Model bisnis sesuai dengan produksi |
| Concurrency mode | Atur A ke 1 pengguna konkuren, B ke 400 pengguna konkuren | Harus mengkompensasi perbedaan RT 100x. Rasio menjadi 1:400 dalam konkurensi untuk mencapai throughput 1:4 |
Mode RPS menghilangkan kebutuhan menghitung penyesuaian konkurensi berdasarkan perbedaan waktu respons, memberikan kontrol lebih tepat atas campuran lalu lintas.
Pemantauan
Mengapa pemantauan komprehensif penting
Pemantauan selama pengujian kinerja memiliki dua tujuan: deteksi bottleneck secara real-time dan analisis akar penyebab pasca pengujian. Tanpa metrik komprehensif di semua lapisan, mengidentifikasi sumber bottleneck menjadi tebakan semata.
Metrik yang dipantau
| Layer | Key metrics |
|---|---|
| Operating system | Utilisasi CPU (User, Sys, Wait, Idle), utilisasi memori (termasuk swap), I/O disk, I/O jaringan, parameter kernel |
| Middleware | Kolam thread, kolam koneksi Java Database Connectivity (JDBC), metrik Java Virtual Machine (JVM) (frekuensi GC, frekuensi full GC, ukuran heap) |
| Database | Pernyataan SQL lambat, lock, rasio hit cache, session, jumlah proses |
| Application | Durasi metode, pemrosesan sinkron vs. asinkron, buffering, perilaku cache |
Analisis bottleneck
Bottleneck kinerja biasanya terbagi dalam empat kategori: sumber daya sistem operasi, konfigurasi middleware, masalah database, dan logika aplikasi.
Fokus analisis berdasarkan lapisan
| Layer | Focus areas |
|---|---|
| Operating system | CPU, memori, I/O disk, I/O jaringan |
| Middleware | Kolam thread, kolam koneksi JDBC, metrik JVM (frekuensi GC, frekuensi full GC, ukuran heap) |
| Database | Pernyataan SQL lambat, lock waits, deadlock, rasio hit cache, session, jumlah proses |
| Application | Durasi metode, efisiensi algoritma, pemrosesan sinkron vs. asinkron, penggunaan cache, buffering |
| Load generator | Konsumsi sumber daya pada mesin load generator. Dalam kebanyakan kasus, load generator tidak mungkin menjadi bottleneck. PTS memiliki mekanisme perlindungan dan penjadwalan bawaan yang menangani hal ini secara otomatis |
Analisis terarah di setiap lapisan memungkinkan tuning yang efisien: perbaiki bottleneck sebenarnya, bukan menambahkan sumber daya yang tidak berdampak.
Tuning
Setelah mengidentifikasi bottleneck, lakukan tuning sistem dan uji ulang untuk memverifikasi peningkatan. Area tuning umum meliputi:
| Layer | Tuning targets |
|---|---|
| Middleware | Ukuran kolam thread, ukuran kolam koneksi database, parameter JVM |
| Database | Optimasi SQL lambat, penyelesaian deadlock dan lock wait, peningkatan rasio hit cache, penyesuaian parameter proses dan session |
| Application | Waktu eksekusi metode, optimasi algoritma, konversi sinkron ke asinkron, strategi cache, ukuran buffer |
| System resources | Konsumsi CPU atau memori tinggi biasanya disebabkan oleh pengaturan aplikasi atau konfigurasi parameter yang suboptimal—bukan karena kekurangan perangkat keras. Atasi masalah di tingkat aplikasi sebelum melakukan scaling sumber daya |
Uji stres terdistribusi dengan PTS
Performance Testing Service (PTS) adalah platform berbasis SaaS untuk uji stres terdistribusi. Tidak diperlukan instalasi atau penerapan tambahan.
Simulasi lalu lintas
PTS menghasilkan lalu lintas pengujian dari node Content Delivery Network (CDN) di ratusan kota dan beberapa carrier di seluruh dunia. Pendekatan ini mensimulasikan pola akses pengguna akhir yang realistis, termasuk distribusi geografis dan routing spesifik carrier.
Desain skenario
Rekam skenario menggunakan plugin perekaman browser utama, atau susun eksekusi API berurutan dan paralel melalui antarmuka visual—tanpa perlu coding
Parameterisasi permintaan menggunakan file data, fungsi bawaan, operasi string, dan ekstraksi respons. PTS berfungsi sebagai pabrik data yang memformat parameter permintaan melalui encoding sederhana
Pertahankan status cookie dan session di seluruh panggilan API, dengan instruksi yang dapat diperluas yang mendukung think time multi-form dan regulasi lalu lintas
Debug skenario dan API individual sebelum menjalankan pengujian skala penuh
Kontrol beban
Dua mode beban: Mode konkurensi dan mode requests per second (RPS)
Startup cepat: Luncurkan uji stres dalam hitungan menit
Penyesuaian real-time: Perubahan lalu lintas berlaku dalam hitungan detik
Kemampuan pulse: Hasilkan lonjakan instan jutaan kueri per detik (QPS)
Kontrol keamanan: Hentikan lalu lintas uji stres segera saat diperlukan
Pelaporan
PTS mengumpulkan data real-time selama setiap pengujian, termasuk konkurensi, TPS, RT, dan log sampel untuk setiap API. Laporan dihasilkan secara otomatis untuk analisis pasca pengujian.
Industri yang didukung
PTS mendukung workload di bidang e-commerce, media, keuangan dan asuransi, logistik, periklanan dan pemasaran, serta jejaring sosial.