OpenResty FAQ | Struktur Jaringan untuk Pengujian, Fitur Terkait SSL, DSL, Alat `ab`

API7.ai

December 1, 2022

OpenResty (NGINX + Lua)

Seri artikel OpenResty telah diperbarui sejauh ini, dan kita telah selesai mempelajari bagian tentang pengujian. Selamat karena tidak tertinggal, aktif belajar dan mempraktikkan operasi, serta antusias meninggalkan pemikiran Anda.

Banyak pertanyaan yang diajukan dalam komentar sangat berharga, dan beberapa yang lebih khas dan menarik telah diekstrak khusus sebagai Q&A hari ini.

Mari kita lihat lima pertanyaan ini hari ini.

Pertanyaan 1: Bagaimana membangun struktur jaringan untuk pengujian?

Q: Apakah klien yang menjalankan wrk harus ditempatkan pada mesin di jaringan eksternal atau mesin di LAN yang sama dengan server? Mana dari kedua ini yang lebih bermakna untuk pengujian kinerja?

A: Untuk menguji layanan terkait web, memilih alat pengujian yang tepat hanyalah awal yang baik, dan bagaimana membangun struktur jaringan untuk pengujian juga merupakan bagian penting dari tindak lanjut.

Secara umum, kita ingin menguji batas kinerja layanan saja, mengesampingkan semua gangguan jaringan. Untuk tujuan ini, kita dapat memiliki dua cara untuk membangun jaringan untuk melakukan uji tekanan.

Metode pertama adalah dengan menempatkan wrk dan aplikasi server pada mesin yang sama dengan kinerja yang baik. Misalnya, kita dapat mengaktifkan delapan pekerja di NGINX dan membagi sisa sumber daya CPU ke wrk, sehingga hanya ada komunikasi jaringan lokal, meminimalkan dampak jaringan.

Metode kedua adalah dengan membangun LAN dengan router khusus dan menghubungkan mesin tempat wrk berada ke mesin tempat server berada.

Anda tidak disarankan untuk menguji langsung di jaringan yang sudah ada karena sebagian besar jaringan memiliki switch dan firewall, yang dapat membatasi pengujian tekanan volume lalu lintas besar dan menyebabkan hasil pengujian yang tidak akurat.

Selain itu, saya ingin menyebutkan beberapa kata lagi tentang alat pengujian kinerja. Pertama, alat pengujian kinerja mungkin memiliki masalah Coordinated Omission, yang harus Anda perhatikan khususnya saat menganalisis data latensi alat.

Coordinated Omission berarti bahwa saat melakukan pengujian kinerja, tidak cukup hanya menghitung waktu antara mengirim dan menerima respons, yang hanya merupakan waktu layanan, sehingga statistik akan melewatkan banyak masalah potensial. Oleh karena itu, kita juga perlu memasukkan waktu tunggu permintaan pengujian, yang secara keseluruhan adalah waktu respons yang menjadi perhatian pengguna. Tentu saja, jika program sisi server Anda mungkin memblokir, Anda hanya perlu mempertimbangkan masalah ini. Jika tidak, Anda dapat mengabaikannya.

Pertanyaan 2: Bisakah test::nginx menguji fitur terkait SSL?

Q: Apakah tidak mungkin menguji fitur terkait SSL dengan test::nginx?

A: Ini tidak benar. test::nginx dapat menguji fitur terkait SSL; Anda dapat merujuk ke ssl.t. File kasus uji ini menguji seluruh proses sertifikat SSL. Pertama, seperti yang dapat Anda lihat, kasus uji menggunakan kode Lua untuk membaca kunci publik dan pribadi dari sertifikat lokal; kemudian, ia menyiapkan sertifikat melalui API HTTP; akhirnya, ia menggunakan cosocket untuk melakukan jabat tangan SSL dan akses untuk memverifikasi apakah sertifikat valid.

Sebenarnya, tidak hanya SSL, tetapi juga fitur yang termasuk dalam OpenResty dapat diganti dengan menggunakan test::nginx.

Ketika Anda tidak yakin apakah fitur tertentu dapat diimplementasikan dengan test::nginx, Anda dapat mencari kasus uji dari lua-nginx-module dan proyek open source OpenResty lainnya terlebih dahulu, dan Anda biasanya dapat menemukan contoh yang sesuai. Bagaimanapun, test::nginx sangat bisa dimainkan dan bervariasi, dan beberapa kombinasi dan trik yang tidak terduga menunggu untuk ditemukan.

Pertanyaan 3: Apa sebenarnya DSL itu?

Q: Apa sebenarnya DSL dan test::nginx?

A: DSL adalah singkatan dari Domain Specific Language. Tujuan DSL berbeda dari bahasa pengembangan umum. Ini bukan untuk memenuhi kebutuhan domain umum tetapi beberapa domain. DSL yang paling terkenal adalah SQL, Structured Query Language yang digunakan dalam domain database.

Adapun test::nginx, itu adalah DSL yang dibuat untuk memenuhi kebutuhan pengujian NGINX dan OpenResty. Sebenarnya, penulis OpenResty telah menciptakan banyak ide DSL dan membawa banyak percobaan dan solusi baru ke komunitas OpenResty. Namun, seperti yang disebutkan dalam artikel sebelumnya, DSL adalah pedang bermata dua, dan kriteria utama untuk mengukur nilai DSL adalah apakah itu dapat meningkatkan produktivitas bagi pengguna akhir.

Pertanyaan 4: Masalah instalasi test::nginx

Q: Setelah menjalankan git clone, apakah saya perlu menjalankan perintah berikut untuk menginstal test::nginx?

cd test-nginx perl Makefile.PL make sudo make install

A: Sebenarnya, ini tidak perlu. Di sini Anda dapat merujuk ke beberapa proyek open source.

Langkah 1: instal melalui manajer paket

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Langkah 2: git clone test::nginx terbaru

git clone https://github.com/openresty/test-nginx.git test-nginx

Langkah 3: sertakan direktori test-nginx saat Anda menggunakan perintah prove

prove -Itest-nginx/lib -r t

Seperti yang saya sebutkan sebelumnya, panduan terbaik untuk menginstal OpenResty dan proyek sekitarnya ada di CI, bukan di dokumentasi. Ini mungkin berbeda dari proyek lain, terutama karena OpenResty mempertahankan fork sendiri atau versi tertentu dari beberapa proyek sekitarnya dan karena OpenResty juga sangat bergantung pada CI. Oleh karena itu, Anda harus menggunakan dan menguji OpenResty dengan cara yang sama seperti yang dibangun di CI untuk memastikan konsistensi dengan yang resmi.

Pertanyaan 5: Apakah alat pengujian ab baik atau tidak?

Q: Bagaimana saya ingat Yichun Zhang sering menyebutkan ab sebagai alat pengujian terbaik di Google Groups?

A: Seperti yang saya sebutkan dalam artikel, ab bukanlah alat pengujian kinerja yang baik dalam hal fitur alat karena tidak dapat menghasilkan tekanan permintaan yang cukup. Namun, kinerja program sisi server sekarang sangat kuat. Kami menggunakan ab alih-alih wrk di test::nginx karena dalam mode TEST_NGINX_BENCHMARK, test::nginx menggunakan ab atau weighttp, tergantung pada versi protokol HTTP, sebagai alat untuk pengujian kinerja.

Selain itu, saya harap Anda memperhatikan bahwa teknologi internet berubah sangat cepat, dan setiap dari kita perlu memperbarui pengetahuan dan keterampilan kita tepat waktu. Misalnya, menurut saya, pilihan test::nginx ini sekarang perlu diperbarui, dan Yichun Zhang mungkin tidak tahu keberadaan wrk pada saat itu. Tentu saja, mungkin akan ada alat pengujian kinerja yang lebih baik daripada wrk seiring waktu, dan kita harus memiliki pikiran yang positif dan terbuka untuk belajar dan memilih.

Hari ini, saya terutama menjawab pertanyaan yang disebutkan di atas. Saya berharap melalui komunikasi dan Q&A, saya dapat membantu Anda mengubah apa yang Anda pelajari menjadi apa yang Anda dapatkan. Anda juga dipersilakan untuk meneruskan artikel ini sehingga kita dapat berkomunikasi dan berkembang bersama.