Saya Buat Performance Testing Dengan k6

Apa itu k6?

k6 ialah alat load testing sumber terbuka yang mesra developer dan fleksibel, dibina oleh Grafana. Ia membantu developer mencegah isu prestasi dan meningkatkan kebolehpercayaan aplikasi dengan mensimulasikan keadaan beban dunia sebenar.

Saya berpeluang menggunakan k6 sebagai sebahagian daripada pasukan API Performance Testing. Saya memainkan peranan besar dalam menjana skrip untuk setiap endpoint API yang dibangunkan. Inilah cara pasukan Data Lake Platform mendapat manfaat daripadanya, bersama beberapa pandangan tentang ujian k6.

Pada asalnya, kandungan ini disediakan untuk dikongsi dengan pasukan, tetapi saya mahu mengembangkannya menjadi artikel awam untuk menerangkan kenapa ia patut menjadi amalan standard bagi mana-mana pasukan yang membina API. Saya tidak mempunyai pengalaman mendalam dengan alat performance testing lain, tetapi saya percaya k6 ialah antara yang paling fleksibel, mudah diubah suai, dan menyeronokkan untuk software engineer yang suka menulis kod.

Apa itu Load Testing?

Load testing ialah proses meletakkan permintaan ke atas sistem dan mengukur responsnya.
Poin utama
- Fokus kepada sejauh mana sistem berfungsi di bawah beban.
- Berbeza daripada functional testing yang menyemak sama ada sistem berfungsi.
- Mengukur aspek kualitatif seperti responsif dan kebolehpercayaan.

Kenapa Buat Performance Testing?

Secara umum, ujian ini membantu kita mengenal pasti bottleneck lebih awal dan menanganinya. Selepas API siap dibangunkan, kami menambah ujian prestasi tambahan. Kami menggunakan Grafana Dashboard untuk menjalankan load test dan mendokumentasikan beban yang mampu ditampung. Sebarang anomali akan ditanda dan disemak untuk penambahbaikan. Ini membantu kami mendahului permintaan pengguna. Ada banyak manfaat lain, seperti:

Manfaat:

Meningkatkan pengalaman pengguna.
Mengenal pasti bottleneck lebih awal.
Bersedia untuk permintaan yang tidak dijangka.
Meningkatkan keyakinan terhadap aplikasi.
Menilai dan mengoptimumkan infrastruktur.

Sebagai Backend Engineer yang mengutamakan integriti dan ketepatan data, ujian oleh Data Engineers dan pasukan Data Solutions sahaja tidak mencukupi. Kami juga perlu memastikan pasukan software engineering boleh menguji ribuan, malah jutaan, rekod transaksi berbeza secara terperinci untuk mengurangkan isu berpotensi. Dalam skrip automasi k6, kami menambah extension untuk menyemak sebarang percanggahan data antara data yang dijangka dengan data stream daripada panggilan API yang dijalankan dalam pipeline. Ini membantu mengesan isu supaya QA boleh melaporkannya dan pasukan boleh menyiasat API dengan lebih lanjut. Kadang-kadang masalah berpunca daripada perubahan column dalam database atau logik yang tersalah takrif sehingga menyebabkan row hilang. Jika tidak dapat diselesaikan dengan cepat, isu tersebut boleh ditanda sebagai known issue.

Alasan Biasa & Jawapan Balas:

"Aplikasi kami terlalu kecil" -> Sistem kecil pun mendapat manfaat.
"Ia mahal/mengambil masa" -> Kos tidak menguji biasanya lebih tinggi.
"Perlu pengetahuan teknikal yang mendalam" -> Terdapat pelbagai tahap kerumitan.
"Kami tiada performance environment" -> Alternatif masih wujud.
"Cloud itu tidak terhad" -> Kecekapan masih penting.

Saya percaya ini ialah amalan yang baik dan sangat meningkatkan kecekapan serta kualiti API. Ia juga memudahkan kerja QA kerana mereka tidak lagi perlu menyemak setiap butiran data stream secara manual. Sekarang, mari kita belajar lebih lanjut tentang k6 dan apa lagi yang boleh dilakukan selain load testing dan stress testing.

Load Testing vs. Performance Testing

                Performance testing != Load testing

Performance testing mengesahkan sejauh mana sistem berfungsi secara keseluruhan, termasuk aspek seperti scalability, elasticity, availability, reliability, resiliency, dan latency.
Load testing hanyalah satu jenis performance testing, dan ia ialah pendekatan yang boleh digunakan untuk menguji banyak aspek prestasi aplikasi. Namun, bukan semua performance testing melibatkan load testing.
Load testing ialah sub-amalan dalam performance testing.

Senario Load Test

Senario load test menggabungkan nilai khusus untuk parameter ujian. Setiap senario mencipta semula situasi atau keadaan tertentu yang akan dihadapi oleh aplikasi.

Senario load test juga sering dipanggil jenis load test. Beberapa senario paling umum disenaraikan di bawah.

Contoh Kod

import http from 'k6/http'
import { sleep, check } from 'k6'
import { Rate, Trend } from 'k6/metrics'

// Custom defined metrics
const lowerThan2sRate = new Rate('lower_than_2s')
const durationInSeconds = new Trend('duration_in_seconds')

// This BASE_URL won't work if you're using Docker.
// You'll need to know the IP address of the host.
// Then replace localhost with the IP address.
const BASE_URL = 'http://localhost:3000'

export const options = {
    vus: 1000,          // 1000 users will be simulated
    duration: '1m',     // the test will run for 1 minute
    thresholds: {       // you can define threshold here. all criteria of a successful test
        lower_than_2s: [{               // custom defined metrics
            threshold: 'rate>0.75',     // the result rate should be above 75 percents
            abortOnFail: true,          // if the criteria wasn't met, then the test is aborted
        }],
    }
}

export default function(data) {
    // We need this to pass the authorization and authentication middleware
    const params = {
        headers: {
            'Content-Type': 'application/json',
            Authorization: `Bearer ${data.token}`
        }
    }


    data.incomeExpenseTypes.forEach(t => {
        const payload = {
            value: 10000,
            description: 'Test',
            income_expense_type_id: t.id,
            is_income: false
        }
        const res = http.post(`${BASE_URL}/income-expense`, JSON.stringify(payload), params)

        // this check function will run at each iteration
        // making sure that the checks criteria is met
        check(res, {
            'is success': (r) => r.json().success,
            'duration below 2s': r => r.timings.duration < 2000
        })

        // lowerThan2sRate is added by one if the duration is below 2s
        lowerThan2sRate.add(res.timings.duration < 2000)

        // we know that the duration is in millisecond
        // but for demonstartion purposes, we convert it to second
        durationInSeconds.add(res.timings.duration / 1000)
    })

    // sleep for one second at each iteration
    sleep(1)
}

Parameter ujian

Ini ialah senarai tidak lengkap bagi parameter ujian yang biasa:

Virtual users (VUs): Aktiviti 1 VU mewakili aktiviti 1 pengguna sebenar.
Iterations: Jumlah ulangan skrip yang akan dijalankan oleh VU.
Throughput: Ukuran berapa banyak beban yang dijana oleh ujian mengikut masa.
Load profile: Bentuk trafik yang dijana oleh ujian dari masa ke masa.
Duration: Masa yang diambil untuk menjalankan keseluruhan ujian dan setiap stage individu.

Shakeout Test

Ujian kecil untuk menyemak isu besar. Kadang-kadang dikenali sebagai smoke test, ia menyemak isu besar sebelum lebih banyak masa dan sumber digunakan.

Biasanya menggunakan satu atau beberapa VU yang berjalan untuk tempoh yang pendek. Jika ujian gagal, sebarang isu mesti diselesaikan dahulu.

Name: Shakeout Test
Total VUs: 5
Ramp-up: 0 seconds
Duration: 10 minutes
Ramp-Down: 0 seconds

Average Load Test

Mensimulasikan beban produksi biasa. Biasanya merangkumi tempoh ramp-up dan ramp-down untuk mensimulasikan pengguna yang masuk secara beransur-ansur dan berinteraksi dengan sistem. Ujian ini mengekalkan simulasi beban steady-state selama kira-kira satu jam.

Name: Average Load Test
Total VUs: 100
Ramp-up: 30 minutes
Steady state: 60 minutes
Ramp-down: 10 minutes
Total duration: 100 minutes

Stress Test

Mensimulasikan trafik yang dijangka dialami aplikasi pada waktu atau musim paling tinggi.

Ini ialah senario ujian yang baik untuk rush hour atau tempoh jualan apabila aplikasi menerima beban luar biasa tinggi.

Soak Test

Soak test, juga dipanggil endurance test:

Ujian dengan tempoh yang lebih panjang daripada purata.
Sesetengah bottleneck prestasi, seperti yang disebabkan oleh masalah memory management, hanya muncul selepas tempoh masa yang lebih panjang.

Name: Soak Test
Total VUs: 50
Ramp-up: 30 minutes
Steady state: 480 minutes
Ramp-down: 10 minutes
Total duration: 520 minutes (8 hours and 40 minutes)

Spike Test

Spike test mencipta semula keadaan apabila aplikasi mengalami peningkatan trafik yang tiba-tiba dan sangat besar. Spike test sesuai untuk mensimulasikan acara berjadual seperti:

pelancaran produk atau jualan tiket konsert
tarikh akhir, contohnya hari terakhir penghantaran cukai

Name: Spike Test
Total VUs: 300
Ramp-up: 1 minute
Steady state: 20 minutes
Ramp-down: 5 minutes
Total duration: 26 minutes