Panduan performa untuk Layanan Azure Web PubSub
Salah satu manfaat utama menggunakan Layanan Azure Web PubSub adalah kemudahan penskalaan. Dalam skenario berskala besar, performa adalah faktor penting.
Dalam panduan ini, kami memperkenalkan faktor-faktor yang memengaruhi performa layanan Web PubSub. Kami menjelaskan performa umum dalam skenario kasus penggunaan yang berbeda.
Evaluasi cepat menggunakan metrik
Sebelum melalui faktor-faktor yang berdampak pada performa, mari kita pertama-tama perkenalkan cara mudah untuk memantau tekanan layanan Anda. Ada metrik yang disebut Beban Server di Portal.
Ini menunjukkan tekanan komputasi layanan Azure Web PubSub Anda. Anda dapat menguji skenario Anda sendiri dan memeriksa metrik ini untuk memutuskan apakah akan meningkatkan skala. Latensi di dalam layanan Azure Web PubSub akan tetap rendah jika Beban Server di bawah 70%.
Catatan
Jika Anda menggunakan unit 50 atau lebih besar dan skenario Anda terutama mengirim ke grup kecil (ukuran <grup 20), Anda perlu memeriksa pengiriman ke grup kecil untuk referensi. Dalam skenario tersebut ada biaya perutean besar yang tidak termasuk dalam Beban Server.
Di bawah ini adalah konsep terperinci untuk mengevaluasi performa.
Definisi istilah
Masuk: Pesan masuk ke Layanan Azure Web PubSub.
Keluar: Pesan keluar dari Layanan Azure Web PubSub.
Bandwidth: Ukuran total semua pesan dalam 1 detik.
Gambaran Umum
Panduan ini menjawab pertanyaan-pertanyaan berikut:
Apa performa Layanan Azure Web PubSub yang khas untuk setiap ukuran unit?
Apakah Layanan Azure Web PubSub memenuhi persyaratan saya untuk throughput pesan (misalnya, mengirim 100.000 pesan per detik)?
Untuk skenario spesifik saya, bagaimana cara memilih ukuran unit yang tepat?
Untuk menjawab pertanyaan-pertanyaan tersebut, panduan ini terlebih dahulu memberikan penjelasan tingkat tinggi tentang faktor-faktor yang memengaruhi performa. Kemudian mengilustrasikan pesan masuk dan keluar maksimum untuk kasus penggunaan umum: Kirim ke grup melalui subprotokl Web PubSub, upstream, dan rest api .
Panduan ini tidak dapat mencakup semua skenario (dan kasus penggunaan, ukuran pesan, pola pengiriman pesan, serta contoh lain yang berbeda). Tetapi memberikan beberapa informasi dasar untuk memahami keterbatasan performa.
Wawasan performa
Bagian ini menjelaskan metodologi evaluasi performa, kemudian mencantumkan semua faktor yang memengaruhi performa. Di akhir, terdapat metode untuk membantu Anda mengevaluasi persyaratan performa.
Metodologi
Throughput dan latensi adalah dua aspek umum dalam pemeriksaan performa. Throughput maksimum (bandwidth masuk dan keluar) didefinisikan sebagai throughput maksimum yang dicapai ketika 99 persen pesan memiliki latensi kurang dari 1 detik. Ini bukan batas yang sulit.
Faktor performa
Secara teoritis, kapasitas Layanan Azure Web PubSub dibatasi oleh sumber daya komputasi: CPU, memori, dan jaringan. Misalnya, lebih banyak koneksi ke Layanan Azure Web PubSub menyebabkan layanan menggunakan lebih banyak memori. Untuk lalu lintas pesan yang lebih besar (misalnya, setiap pesan lebih besar dari 2.048 byte), Layanan Azure Web PubSub perlu menghabiskan lebih banyak siklus CPU untuk memproses lalu lintas.
Biaya perutean pesan juga membatasi performa. Layanan Azure Web PubSub berperan sebagai perantara pesan, yang merutekan pesan di antara sekumpulan klien. Skenario atau API yang berbeda memerlukan kebijakan perutean yang berbeda.
Untuk echo, klien mengirim pesan ke upstream, dan upstream menggemakan pesan kembali ke klien. Pola ini memiliki biaya perutean terendah. Namun untuk broadcast, kirim ke grup, dan kirim ke koneksi, Layanan Azure Web PubSub perlu mencari koneksi target melalui struktur data terdistribusi internal. Pemrosesan ekstra ini menggunakan lebih banyak CPU, memori, dan bandwidth jaringan. Akibatnya, performa menjadi lebih lambat.
Singkatnya, faktor-faktor berikut memengaruhi kapasitas masuk dan keluar:
Ukuran unit (CPU/memori)
Jumlah koneksi
Ukuran pesan
Laju pengiriman pesan
Skenario kasus penggunaan (biaya perutean)
Menemukan ukuran unit yang tepat
Bagaimana Anda dapat mengevaluasi kapasitas masuk/keluar atau menemukan ukuran unit mana yang cocok untuk kasus penggunaan tertentu?
Setiap ukuran unit memiliki bandwidth masuk maksimum dan bandwidth keluarnya sendiri. Pengalaman pengguna yang lancar tidak dijamin setelah lalu lintas masuk atau keluar melebihi ambang batas.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections: Jumlah koneksi yang mengirim pesan.
- outboundConnections: Jumlah koneksi yang menerima pesan.
- messageSize: Ukuran satu pesan (nilai rata-rata). Pesan kecil yang kurang dari 1.024 byte memiliki dampak performa yang serupa dengan pesan 1.024 byte.
- sendInterval: Interval untuk mengirim pesan. Misalnya, 1 detik berarti mengirim satu pesan setiap detik. Interval yang lebih kecil berarti mengirim lebih banyak pesan dalam jangka waktu tertentu. Misalnya, 0,5 detik berarti mengirim dua pesan setiap detik.
- Koneksi ions: Ambang batas maksimum yang diterapkan untuk Layanan Azure Web PubSub untuk setiap ukuran unit. Koneksi yang melebihi ambang batas akan dibatasi.
Asumsikan bahwa hulu cukup kuat dan bukan penyempitan performa. Kemudian, periksa bandwidth masuk dan keluar maksimum untuk setiap ukuran unit.
Studi kasus
Bagian berikut membahas tiga kasus penggunaan umum: mengirim ke grup melalui subprotokol Web PubSub, memicu CloudEvent, memanggil rest api. Untuk setiap skenario, bagian mencantumkan kapasitas masuk dan keluar saat ini untuk Layanan Azure Web PubSub. Bagian ini juga menjelaskan faktor utama yang memengaruhi performa.
Dalam semua kasus penggunaan, ukuran pesan default adalah 2.048 byte, dan interval kirim pesan adalah 1 detik.
Mengirim ke grup melalui subprotokol Web PubSub
Layanan ini mendukung subprotokol khusus yang disebut json.webpubsub.azure.v1, yang memberdayakan klien untuk melakukan publikasi/berlangganan secara langsung bukan bolak-balik ke server upstram. Skenario ini efisien karena tidak ada server yang terlibat dan semua lalu lintas melewati koneksi WebSocket layanan klien.
Anggota grup dan jumlah grup adalah dua faktor yang memengaruhi performa. Untuk menyederhanakan analisisnya, kami mendefinisikan dua jenis grup:
- Grup besar: Jumlah grupnya selalu 10. Jumlah anggota grup sama dengan (jumlah koneksi maksimum) / 10. Misalnya, untuk Unit 1, jika ada 1.000 jumlah koneksi, maka setiap grup memiliki 1000 / 10 = 100 anggota.
- Grup kecil: Setiap grup memiliki 10 koneksi. Jumlah grup sama dengan (jumlah koneksi maksimum) / 10. Misalnya, untuk Unit 1, jika ada 1.000 jumlah koneksi, maka kita memiliki 1000 / 10 = 100 grup.
Kirim ke grup membawa biaya perutean ke Layanan Azure Web PubSub karena harus menemukan koneksi target melalui struktur data terdistribusi. Seiring dengan koneksi pengiriman yang meningkat, biayanya juga meningkat.
Grup besar
Untuk kirim ke grup besar, bandwidth keluar menjadi hambatan sebelum dibatasi oleh biaya perutean. Tabel berikut mencantumkan bandwidth keluar maksimum.
| Kirim ke grup besar | Unit 1 | Unit 2 | Unit 10 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Jumlah anggota grup | 100 | 200 | 1,000 | 5\.000 | 10,000 | 5\.000 | 10,000 | 20.000 |
| Jumlah grup | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Pesan masuk per detik | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Bandwidth masuk | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps | 60 KBps |
| Pesan masuk per detik | 3.000 | 6.000 | 30.000 | 150.000 | 300.000 | 600.000 | 1.500.000 | 3,000,000 |
| Bandwidth keluar | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1.200 MBps | 3.000 MBps | 6.000 MBps |
Grup kecil
Biaya perutean cukup signifikan untuk mengirimkan pesan ke banyak grup kecil. Saat ini, implementasi Layanan Azure Web PubSub mencapai batas biaya perutean di Unit 50. Menambahkan lebih banyak CPU dan memori tidak membantu, sehingga Unit 100 tidak dapat meningkatkan lebih lanjut secara desain. Jika Anda membutuhkan lebih banyak bandwidth masuk, perlu meningkatkan skala untuk menggunakan Premium_P2(unit >100).
| Kirim ke grup kecil | Unit 1 | Unit 2 | Unit 10 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Jumlah anggota grup | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Jumlah grup | 100 | 200 | 1,000 | 5\.000 | 10,000 | 20.000 | 50.000 | 100.000 |
| Pesan masuk per detik | 200 | 400 | 2.000 | 10,000 | 10,000 | 20.000 | 50.000 | 100.000 |
| Bandwidth masuk | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Pesan masuk per detik | 2.000 | 4.000 | 20.000 | 100.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Bandwidth keluar | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Catatan
Jumlah grup, jumlah anggota grup yang tercantum dalam tabel bukan batas keras. Nilai parameter ini dipilih untuk menetapkan skenario tolok ukur yang stabil.
Memicu Peristiwa Cloud
Layanan memberikan handler klien ke webhook induk menggunakan protokol HTTP CloudEvents.
Untuk setiap acara, upaya ini merumuskan permintaan HTTP POST ke induk yang terdaftar dan mengharapkan respons HTTP.
Catatan
Web PubSub juga mendukung HTTP 2.0 untuk pengiriman peristiwa upstram. Hasil di bawah ini diuji menggunakan HTTP 1.1. Jika server aplikasi Anda mendukung HTTP 2.0, performanya akan lebih baik.
Echo
Dalam hal ini, server aplikasi menulis ulang pesan asli kembali di respons http. Perilaku echo menentukan bahwa bandwidth masuk maksimum sama dengan bandwidth keluar maksimum. Untuk detailnya, lihat tabel berikut.
| Echo | Unit 1 | Unit 2 | Unit 10 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Pesan masuk/keluar per detik | 500 | 1,000 | 5\.000 | 25.000 | 50.000 | 100.000 | 250.000 | 500,000 |
| Bandwidth masuk/keluar | 1 MBps | 2 MBps | 10 MBps | 50 MBps | 100 MBps | 200 MBps | 500 MBps | 1.000 MBps |
REST API
Azure Web PubSub menyediakan API yang andal untuk mengelola klien dan mengirimkan pesan real time.
Kirim ke pengguna melalui REST API
Tolok ukur menetapkan nama pengguna ke semua klien sebelum mereka mulai tersambung ke Layanan Azure Web PubSub.
| Kirim ke pengguna melalui REST API | Unit 1 | Unit 2 | Unit 10 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Pesan masuk/keluar per detik | 180 | 360 | 1.800 | 9.000 | 18.000 | 36.000 | 90.000 | 180.000 |
| Bandwidth masuk/keluar | 360 KBps | 720 KBps | 3,6 MBps | 18 MBps | 36 MBps | 72 MBps | 180 MBps | 360 MBps |
Siaran melalui REST API
Bandwidth sama dengan yang untuk dikirim ke grup besar.
| Siaran melalui REST API | Unit 1 | Unit 2 | Unit 10 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Pesan masuk per detik | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Pesan masuk per detik | 3.000 | 6.000 | 30.000 | 150.000 | 300.000 | 600.000 | 1.500.000 | 3,000,000 |
| Bandwidth masuk | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps | 6 KBps |
| Bandwidth keluar | 6 MBps | 12 MBps | 60 MBps | 300 MBps | 600 MBps | 1.200 MBps | 3.000 MB | 6.000MB |
Langkah berikutnya
Gunakan sumber daya ini untuk mulai membangun aplikasi Anda sendiri: