Ujian beban aplikasi CFML: ukur sebelum anda menala

Ujian beban aplikasi CFML: ukur sebelum anda menala

Ujian beban ialah cara mengukur berapa banyak permintaan serentak yang aplikasi Lucee anda boleh tampung sebelum ia mula perlahan atau memulangkan ralat. Matlamatnya bukan untuk memecahkan pelayan, tetapi untuk tahu had sebenar sebelum pelawat anda menemuinya lebih dahulu. Artikel ini menunjukkan cara menyediakan endpoint ujian yang mengukur masa, cara memilih alat beban, metrik yang patut anda baca, dan cara mentafsir keputusan tanpa menipu diri sendiri.

Kenapa Ujian pada Mesin Pembangun Mengelirukan

Ramai pembangun menguji prestasi pada komputer riba sendiri dan menyimpulkan aplikasi itu laju. Kesimpulan itu hampir selalu salah, dan sebabnya bukan rahsia. Mesin pembangun biasanya lebih laju daripada pelayan sebenar dari segi CPU dan memori, pangkalan datanya berjalan di localhost tanpa latensi rangkaian, dan tiada pelawat lain yang berkongsi sumber. Satu permintaan yang kembali dalam 20 milisaat tidak memberitahu apa yang berlaku apabila 500 permintaan tiba serentak.

Tambahan pula, mesin pembangun penuh dengan proses lain: IDE, pelayar, bekas Docker, dan pelbagai perkhidmatan latar belakang. Kesemua itu bersaing untuk CPU yang sama, jadi nombor yang anda ukur bukan nombor aplikasi, tetapi nombor mesin yang sedang sibuk. Ujian beban yang bermakna dijalankan pada persekitaran yang menyerupai pengeluaran, atau sekurang-kurangnya bekas dengan had CPU dan memori yang ditetapkan dengan jelas. Tanpa itu, anda menala berdasarkan nombor yang tidak wujud.

Sediakan Endpoint Ujian yang Mengukur Masa

Sebelum menghantar sebarang alat beban, anda perlu satu endpoint yang boleh diukur. Endpoint ini melakukan kerja sebenar, iaitu satu pertanyaan ke pangkalan data, dan melaporkan masa yang diambilnya dalam milisaat:

<cfset mula = getTickCount()>

<cfquery name="senarai" datasource="kedai">
    SELECT id, nama, harga FROM produk ORDER BY id LIMIT 10
</cfquery>

<cfset tamat = getTickCount()>
<cfset masaMs = tamat - mula>

<cfoutput>
OK;rekod=#senarai.recordCount#;masa_ms=#masaMs#
</cfoutput>

getTickCount() memulangkan masa dalam milisaat, jadi beza antara dua panggilan ialah tempoh kerja itu. Endpoint ini sengaja kecil supaya anda boleh membandingkan satu versi dengan versi seterusnya; kalau endpoint melakukan terlalu banyak perkara, sukar untuk tahu bahagian mana yang perlahan. Simpan sebagai endpoint-beban.cfm dan buka sekali melalui pelayar untuk memastikan ia memulangkan 200.

Warmup JIT: Jangan Ukur Permintaan Pertama

Satu kesilapan klasik ialah menjalankan alat beban dan terus percaya nombor pada saat pertama. JVM menyusun kod pada masa jalanan, iaitu ciri yang dipanggil kompilasi JIT. Laluan kod yang sering dilalui akan disusun kepada kod mesin selepas beberapa ribu panggilan, dan sebelum itu ia berjalan perlahan. Lucee juga menyusun templat .cfm pada permintaan pertama dan menyimpan kelas .cfc dalam cache.

Kerana itu, sentiasa lakukan pemanasan dahulu: hantar beberapa ratus permintaan sebelum anda mula mengukur, dan buang nombor daripada fasa pemanasan itu. Ujian yang mengukur permintaan pertama akan melaporkan masa yang jauh lebih tinggi daripada realiti pengeluaran, dan anda akan menala perkara yang tidak perlu ditambah.

p50, p95 dan p99: Tiga Nombor yang Berbeza

Purata kependaman ialah nombor yang paling mudah dikira dan paling mudah menipu. Purata menyembunyikan ekor, iaitu permintaan yang paling lambat, sedangkan ekor itulah yang dirasai pelawat. Gantikan purata dengan tiga persentil ini:

Apabila p50 rendah tetapi p99 tinggi, aplikasi anda laju bagi kebanyakan orang tetapi sesekali tersangkut lama, selalunya kerana menunggu sambungan pangkalan data atau kutipan sampah. Nombor p99 yang meletup ialah isyarat awal masalah yang belum kelihatan pada purata.

Kadar Ralat Berbanding Kependaman

Kependaman bukan satu-satunya nombor yang perlu dipantau. Aplikasi yang membalas dalam 5 milisaat tetapi memulangkan ralat kepada 10 peratus permintaan ialah aplikasi yang rosak, bukan aplikasi yang laju. Sentiasa ukur kadar ralat bersama kependaman.

Urutan biasa apabila beban naik ialah begini: kependaman naik perlahan, kemudian kependaman p99 meletup, dan akhirnya kadar ralat mula naik apabila giliran permintaan penuh atau sambungan pangkalan data habis. Titik di mana kadar ralat melepasi sifar ialah had sebenar aplikasi anda, dan ia hampir selalu datang lebih awal daripada yang anda sangka.

Had Sambungan Pangkalan Data: Leher Lazim

Bagi aplikasi CFML yang bercakap dengan pangkalan data, leher botol paling lazim bukanlah CPU atau memori, tetapi kolam sambungan. Setiap pertanyaan memerlukan satu sambungan, dan bilangan sambungan yang boleh dibuka serentak adalah terhad, sama ada oleh tetapan Lucee, pemacu JDBC, atau pelayan pangkalan data itu sendiri.

Apabila had itu dicapai, permintaan baharu menunggu sambungan kosong, dan masa menunggu itulah yang menolak p99 naik mendadak. Kemudian, apabila semua utas pekerja sibuk menunggu, permintaan mula ditolak dan kadar ralat naik. Cara paling cepat untuk mengesannya ialah memantau bilangan sambungan aktif dan giliran menunggu semasa ujian, bersama log permintaan yang lambat. Untuk menala saiz heap dan utas supaya leher botol ini tidak menjatuhkan pelayan, baca panduan menala JVM, dan untuk memahami ralat memori yang boleh muncul akibatnya, lihat artikel out-of-memory.

Baca Metrik Lucee Semasa Ujian

Semasa alat beban berjalan, baca metrik enjin dalam masa nyata supaya anda tahu apa yang berlaku di dalam JVM. Blok ini memulangkan versi enjin, memori heap yang terpakai dan maksimum, bilangan kolam memori, dan bilangan sumber data yang didaftarkan:

<cfset rt = createObject("java", "java.lang.Runtime").getRuntime()>
<cfset pool = getMemoryUsage()>
<cfset meta = getApplicationMetaData()>

<cfoutput>
enjin=#server.lucee.version#
jvm_heap_terpakai_mb=#numberFormat((rt.totalMemory() - rt.freeMemory()) / 1048576, "0.0")#
jvm_heap_maks_mb=#numberFormat(rt.maxMemory() / 1048576, "0.0")#
kolam_memori=#pool.recordCount#
datasource=#structCount(meta.datasources)#
</cfoutput>

getMemoryUsage() memulangkan perincian setiap kolam memori, dan beza antara totalMemory() dan freeMemory() ialah heap yang benar-benar terpakai. Pantau tiga perkara semasa ujian: heap yang naik tanpa turun menandakan kebocoran, kutipan sampah yang kerap menandakan heap terlalu kecil, dan bilangan sambungan yang memuncak menandakan kolam sambungan hampir habis. Apabila salah satu daripada ini berlaku, panduan caching dan prestasi menerangkan cara mengurangkan kerja yang tidak perlu.

Alat Beban: ab, hey dan k6

Tiga alat yang paling senang dimulakan ialah ab, hey dan k6. Setiap satu sesuai untuk tahap yang berbeza.

ab datang bersama apache2-utils dan cukup untuk ujian pantas. Ia menghantar beberapa permintaan serentak dan melaporkan masa purata serta persentil:

# ab: 2000 permintaan, 50 serentak
ab -n 2000 -c 50 http://127.0.0.1:8888/endpoint-beban.cfm

hey ialah satu binari Go yang lebih pantas dan melaporkan histogram kependaman:

# hey: 2000 permintaan, 50 serentak
hey -n 2000 -c 50 http://127.0.0.1:8888/endpoint-beban.cfm

k6 ialah alat paling lengkap kerana ia menerima skrip dan threshold yang gagal secara automatik apabila metrik melepasi had:

# k6: 50 pengguna maya selama 30 saat
k6 run --vus 50 --duration 30s beban-k6.js

Ketiga-tiga blok ini ditandakan sebagai tidak diuji oleh rig kerana ia menjalankan alat luar terhadap pelayan, tetapi arahan di atas ialah bentuk yang tepat. Laraskan port kepada persekitaran anda, dan jangan sekali-kali menghalakan alat beban kepada laman hidup atau pelayan pengeluaran, kerana ujian beban ialah trafik sintetik yang boleh menjatuhkan laman sebenar.

Mengulang Ujian Selepas Perubahan

Ujian beban bukan sekali jalan. Nilai sebenarnya muncul apabila anda mengulanginya selepas setiap perubahan dan membandingkan nombor. Ubah satu perkara sahaja pada satu masa, jalankan ujian yang sama, dan simpan p50, p95, p99 dan kadar ralat dalam satu fail supaya anda boleh melihat regresi.

Sebaik-baiknya ujian ini menjadi sebahagian daripada proses penghantaran. Apabila anda menyebarkan versi baharu melalui proses deploy tanpa henti, jalankan ujian beban ringkas terhadap versi baharu dan bandingkan dengan versi sebelumnya sebelum trafik sebenar dialihkan. Kalau p99 naik mendadak tanpa sebab yang diketahui, log dan pemantauan akan membantu menjejak permintaan yang perlahan, dan thread dump akan menunjukkan utas yang sedang tersekat.

Soalan Lazim

Adakah ujian beban perlu dijalankan pada mesin yang sama dengan pengeluaran?

Tidak semestinya, tetapi ia perlu menyerupai pengeluaran dari segi CPU, memori, latensi pangkalan data dan had sumber. Ujian pada komputer riba pembangun memberi nombor yang terlalu optimistik dan menyesatkan.

Kenapa p99 lebih penting daripada purata kependaman?

Purata menyembunyikan permintaan paling lambat, manakala p99 menunjukkan ekor yang dirasai pelawat semasa trafik puncak. p99 yang tinggi menandakan masalah seperti menunggu sambungan pangkalan data yang tidak kelihatan pada purata.

Apakah tanda pertama aplikasi mencecah hadnya?

Kependaman p99 mula meletup, diikuti kadar ralat yang naik daripada sifar. Apabila permintaan mula ditolak atau memulangkan ralat, aplikasi sudah melepasi hadnya.

Berapa lama warmup yang perlu sebelum mengukur?

Hantar beberapa ratus hingga beberapa ribu permintaan dahulu supaya JIT JVM menyusun laluan panas dan cache Lucee terisi, kemudian buang nombor daripada fasa pemanasan itu sebelum mula mengukur.

Bolehkah saya menghalakan alat beban kepada laman yang sedang hidup?

Tidak. Ujian beban ialah trafik sintetik yang boleh menjatuhkan laman sebenar. Sentiasa uji pada persekitaran ujian atau pementasan, bukan pada laman hidup.

Sumber

• Apache HTTP server benchmarking tool (ab)
• hey, GitHub
• k6 documentation, Grafana
• Tuning the JVM, Lucee documentation