Panduan performa untuk Layanan Azure SignalR
Salah satu keuntungan utama menggunakan Azure SignalR Service adalah kemudahan penskalaan aplikasi SignalR. Dalam skenario berskala besar, performa adalah faktor penting.
Artikel ini menjelaskan:
- Faktor-faktor yang memengaruhi performa aplikasi SignalR.
- Performa khas dalam skenario kasus penggunaan yang berbeda.
- Lingkungan dan alat yang dapat Anda gunakan untuk membuat laporan performa.
Evaluasi cepat menggunakan metrik
Anda dapat dengan mudah memantau layanan Anda di portal Azure. Dari halaman Metrik instans SignalR, Anda dapat memilih metrik Beban Server untuk melihat "tekanan" layanan Anda.
Bagan menunjukkan tekanan komputasi layanan SignalR Anda. Anda dapat menguji skenario Anda dan memeriksa metrik ini untuk memutuskan apakah akan meningkatkan skala. Latensi di dalam layanan SignalR 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) atau koneksi tunggal, Anda perlu memeriksa pengiriman ke grup kecil atau mengirim ke koneksi untuk referensi. Dalam skenario tersebut ada biaya perutean besar yang tidak termasuk dalam Beban Server.
Definisi istilah
Masuk: Pesan masuk ke Azure SignalR Service.
Keluar: Pesan keluar dari Azure SignalR Service.
Bandwidth: Ukuran total semua pesan dalam 1 detik.
Mode default: Mode kerja default saat instans Azure SignalR Service dibuat. Azure SignalR Service mengharapkan server aplikasi untuk membuat koneksi dengannya sebelum menerima koneksi klien apa pun.
Mode tanpa server: Mode saat Azure SignalR Service hanya menerima koneksi klien. Tidak ada koneksi server yang diizinkan.
Gambaran Umum
Azure SignalR Service mendefinisikan tujuh Tingkat standar untuk kapasitas performa yang berbeda. Panduan ini menjawab pertanyaan-pertanyaan berikut:
Apa performa Azure SignalR Service yang khas untuk setiap tingkatan (unit)?
Apakah Azure SignalR Service memenuhi persyaratan saya untuk throughput pesan (misalnya, mengirim 100.000 pesan per detik)?
Untuk skenario spesifik saya, bagaimana cara memilih tingkat yang tepat?
Apa jenis server aplikasi (ukuran komputer virtual) yang cocok untuk saya? Berapa banyak yang harus saya sebarkan?
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 pada setiap tingkatan untuk kasus penggunaan umum: echo, siaran, kirim ke grup, dan kirim ke koneksi (obrolan peer-to-peer).
Panduan ini tidak dapat mencakup semua skenario (dan kasus penggunaan, ukuran pesan, pola pengiriman pesan, serta contoh lain yang berbeda). Namun, panduan ini menjelaskan beberapa metode untuk membantu Anda:
- Mengevaluasi perkiraan persyaratan Anda untuk pesan masuk atau keluar.
- Menemukan tingkat yang sesuai dengan memeriksa tabel 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. Untuk Azure SignalR Service, setiap tingkat SKU memiliki kebijakan pembatasan throughput masing-masing. Kebijakan ini mendefinisikan throughput maksimum yang diizinkan (bandwidth masuk dan keluar) sebagai throughput maksimum yang dicapai saat 99 persen pesan memiliki latensi yang kurang dari 1 detik.
Latensi adalah rentang waktu dari koneksi yang mengirim pesan hingga menerima pesan respons dari Azure SignalR Service. Ambil gema sebagai contoh. Setiap koneksi klien menambahkan stempel waktu dalam pesan. Hub server aplikasi mengirim pesan aslinya kembali ke klien. Ini membuat penundaan penyebaran menjadi mudah dihitung oleh setiap koneksi klien. Stempel waktu dilampirkan untuk setiap pesan di siaran, kirim ke grup, dan kirim ke koneksi.
Untuk menyimulasikan ribuan koneksi klien bersamaan, beberapa komputer virtual dibuat dalam VPN di Azure. Semua komputer virtual ini tersambung ke instans Azure SignalR Service yang sama.
Dalam mode default Azure SignalR Service, komputer virtual server aplikasi disebarkan di VPN yang sama dengan komputer virtual klien. Semua komputer virtual klien dan komputer virtual server aplikasi disebarkan dalam jaringan yang sama dari wilayah yang sama untuk menghindari latensi lintas wilayah.
Faktor performa
Faktor-faktor berikut memengaruhi performa SignalR.
- Tingkat SKU (CPU/memori)
- Jumlah koneksi
- Ukuran pesan
- Laju pengiriman pesan
- Jenis transportasi (WebSocket, Server-Sent-Event, atau Long-Polling)
- Skenario kasus penggunaan (biaya perutean)
- Koneksi layanan dan server aplikasi (dalam mode server)
Sumber daya komputer
Secara teoritis, kapasitas Azure SignalR Service dibatasi oleh sumber daya komputasi: CPU, memori, dan jaringan. Misalnya, lebih banyak koneksi ke Azure SignalR Service dapat menyebabkan layanan menggunakan lebih banyak memori. Untuk lalu lintas pesan yang lebih besar (misalnya, setiap pesan ukurannya lebih dari 2.048 byte), Azure SignalR Service perlu menggunakan lebih banyak siklus CPU untuk memproses lalu lintas. Sementara itu, bandwidth jaringan Azure juga memberlakukan batas untuk lalu lintas maksimum.
Jenis transportasi
Jenis transportasi adalah faktor lain yang memengaruhi performa. Ketiga jenis tersebut adalah:
- WebSocket: WebSocket adalah protokol komunikasi dua arah dan dupleks penuh melalui satu koneksi TCP.
- Server-Sent-Event: Server-Sent-Event adalah protokol unidirectional untuk mendorong pesan dari server ke klien.
- Polling Panjang: Polling Panjang mengharuskan klien untuk secara berkala melakukan polling informasi dari server melalui permintaan HTTP.
Untuk API yang sama di kondisi yang sama, WebSocket memiliki performa terbaik, Server-Sent-Event lebih lambat, dan Long-Polling adalah yang paling lambat. Azure SignalR Service merekomendasikan WebSocket secara default.
Biaya perutean pesan
Biaya perutean pesan juga membatasi performa. Azure SignalR Service memiliki peran sebagai router pesan, yang merutekan pesan dari sekumpulan klien atau server ke klien atau server lain. Skenario atau API yang berbeda memerlukan kebijakan perutean yang berbeda.
Untuk echo, klien mengirim pesan ke dirinya sendiri, dan tujuan perutean juga dirinya sendiri. Pola ini memiliki biaya perutean terendah. Namun untuk siaran, kirim ke grup, dan kirim ke koneksi, Azure SignalR Service 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.
Dalam mode default, server aplikasi mungkin juga menjadi hambatan dalam skenario tertentu. Azure SignalR SDK harus memanggil hub, sementara mempertahankan koneksi langsung dengan setiap klien melalui sinyal heartbeat.
Dalam mode tanpa server, klien mengirim pesan melalui posting HTTP, yang tidak seefisien WebSocket.
Protokol
Faktor lainnya adalah protokol: JSON dan MessagePack. MessagePack berukuran lebih kecil dan dikirim lebih cepat daripada JSON. MessagePack mungkin tidak meningkatkan performa. Performa Azure SignalR Service tidak sensitif terhadap protokol karena tidak mendekode payload pesan selama penerusan pesan dari klien ke server atau sebaliknya.
Menemukan SKU yang sesuai
Bagaimana Anda dapat mengevaluasi kapasitas masuk/keluar atau menemukan tingkat mana yang cocok untuk kasus penggunaan tertentu?
Asumsikan bahwa server aplikasi cukup kuat dan bukan hambatan performa. Kemudian, periksa bandwidth masuk dan keluar maksimum untuk setiap tingkatan.
Evaluasi cepat
Untuk evaluasi cepat, asumsikan pengaturan default berikut:
- Jenis transportasinya adalah WebSocket.
- Ukuran pesannya adalah 2.048 byte.
- Pesan dikirim setiap 1 detik.
- Azure SignalR Service berada dalam mode default.
Setiap tingkat memiliki bandwidth masuk dan keluar maksimumnya masing-masing. Pengalaman pengguna yang lancar tidak dijamin setelah koneksi masuk atau keluar melebihi batas.
Echo memberikan bandwidth masuk maksimum karena memiliki biaya perutean terendah. Siaran memiliki karakter bandwidth pesan keluar maksimum.
Jangan melebihi nilai yang disorot dalam dua tabel berikut ini.
| 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 |
| Bandwidth masuk | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Bandwidth keluar | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Siaran | 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 |
| Bandwidth masuk | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Bandwidth keluar | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Bandwidth masuk dan bandwidth keluar adalah ukuran pesan total per detik. Berikut adalah rumus untuk keduanya:
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: Waktu pengiriman satu pesan. Biasanya 1 detik per pesan, yang berarti mengirim satu pesan setiap detik. Interval yang lebih singkat berarti mengirim lebih banyak pesan dalam suatu periode waktu. Misalnya, 0,5 detik per pesan berarti mengirim dua pesan setiap detik.
Koneksi: Ambang maksimum yang diterapkan untuk Azure SignalR Service di setiap tingkatan. Jika jumlah koneksi ditingkatkan lebih lanjut, ia menderita pembatasan koneksi.
Catatan
Anda perlu meningkatkan skala ke SKU Premium_P2 untuk memiliki ukuran unit yang lebih besar dari 100.
Evaluasi untuk kasus penggunaan kompleks
Ukuran pesan yang lebih besar atau laju pengiriman yang berbeda
Kasus penggunaan sebenarnya lebih rumit. Ini mungkin mengirim pesan yang lebih besar dari 2.048 byte, atau tingkat pesan pengiriman bukan satu pesan per detik. Mari kita ambil siaran Unit 100 sebagai contoh untuk menemukan cara mengevaluasi performanya.
Tabel berikut menunjukkan kasus penggunaan siaran yang sebenarnya. Namun, ukuran pesan, jumlah koneksi, dan laju pengiriman pesan berbeda dari yang kami asumsikan di bagian sebelumnya. Pertanyaannya adalah bagaimana cara mengetahui jumlahnya (ukuran pesan, jumlah koneksi, atau laju pengiriman pesan) jika hanya mengetahui dua darinya.
| Siaran | Ukuran pesan | Pesan masuk bersamaan | Koneksi | Interval kirim |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100.000 | 5 detik |
| 2 | 256 KB | 1 | 8.000 | 5 detik |
Rumus berikut mudah digunakan berdasarkan rumus sebelumnya:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Untuk Unit 100, bandwidth keluar maksimum adalah 400 MB dari tabel sebelumnya. Untuk ukuran pesan 20 KB, koneksi keluar maksimum harus 400 MB * 5 / 20 KB = 100.000, yang cocok dengan nilai nyata.
Kasus penggunaan campuran
Kasus penggunaan sebenarnya biasa mencampurkan empat kasus penggunaan dasar bersama: echo, siaran, kirim ke grup, dan kirim ke koneksi. Metodologi yang Anda gunakan untuk mengevaluasi kapasitasnya adalah:
- Membagi kasus penggunaan campuran menjadi empat kasus penggunaan dasar.
- Menghitung bandwidth pesan masuk dan keluar maksimum dengan menggunakan rumus sebelumnya secara terpisah.
- Menjumlahkan penghitungan bandwidth untuk mendapatkan total bandwidth masuk/keluar maksimum.
Kemudian pilih tingkat yang sesuai dari tabel bandwidth masuk/keluar maksimum.
Catatan
Untuk mengirim pesan ke ratusan atau ribuan grup kecil, atau untuk ribuan klien yang mengirim pesan satu sama lain, biaya perutean akan menjadi dominan. Perhitungkan dampak ini sebagai pertimbangan.
Untuk kasus penggunaan pengiriman pesan ke klien, pastikan bahwa server aplikasi bukan penyempitan. Bagian "Studi kasus" berikut memberikan panduan mengenai jumlah server aplikasi yang Anda perlukan dan jumlah koneksi server yang seharusnya Anda konfigurasi.
Studi kasus
Bagian berikut menjelaskan empat kasus penggunaan umum untuk transportasi WebSocket: echo, siaran, kirim ke grup,dan kirim ke koneksi. Untuk setiap skenario, bagian ini mencantumkan kapasitas masuk dan keluar saat ini untuk Azure SignalR Service. Bagian ini juga menjelaskan faktor utama yang memengaruhi performa.
Dalam mode default, server aplikasi membuat lima koneksi server dengan Azure SignalR Service. Server aplikasi menggunakan Azure SignalR Service SDK secara default. Dalam hasil pengujian performa berikut, koneksi server ditingkatkan menjadi 15 (atau lebih untuk menyiarkan dan mengirim pesan ke grup besar).
Kasus penggunaan yang berbeda memiliki persyaratan yang berbeda untuk server aplikasi. Siaran memerlukan sedikit server aplikasi. Echo atau kirim ke koneksi memerlukan banyak server aplikasi.
Dalam semua kasus penggunaan, ukuran pesan default adalah 2.048 byte, dan interval kirim pesan adalah 1 detik.
Mode default
Klien, server aplikasi web, dan Azure SignalR Service diperlukan dalam mode default. Setiap klien mewakili satu koneksi.
Echo
Pertama, aplikasi web menyambungkan ke Azure SignalR Service. Kedua, banyak klien menyambungkan ke aplikasi web, yang mengalihkan klien ke Azure SignalR Service dengan token akses dan titik akhir. Kemudian, klien membuat koneksi WebSocket dengan Azure SignalR Service.
Setelah membuat koneksi, semua klien mulai mengirim pesan berisi stempel waktu ke hub tertentu setiap detik. Hub mengirimkan pesan kembali ke klien aslinya. Setiap klien menghitung latensi saat menerima kembali pesan baliknya.
Dalam diagram berikut, 5 hingga 8 (lalu lintas yang disorot merah) berada dalam perulangan. Perulangan berjalan selama durasi default (5 menit) dan menyimpan statistik semua latensi pesan.
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 | 1,000 | 2.000 | 10,000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Bandwidth masuk/keluar | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Dalam kasus penggunaan ini, setiap klien memanggil hub yang ditentukan di server aplikasi. Hub hanya memanggil metode yang ditentukan di sisi klien asli. Hub ini adalah hub paling ringan untuk echo.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Bahkan untuk hub sederhana ini, tekanan lalu lintas pada server aplikasi terlihat semakin jelas seiring beban pesan masuk echo yang meningkat. Tekanan lalu lintas ini memerlukan banyak server aplikasi untuk tingkat SKU besar. Tabel berikut mencantumkan jumlah server aplikasi untuk setiap tingkatan.
| 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 |
| Jumlah server aplikasi | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Catatan
Jumlah koneksi klien, ukuran pesan, laju pengiriman pesan, tingkat SKU, dan CPU/memori server aplikasi memengaruhi performa echo secara keseluruhan.
Siaran
Untuk siaran, saat aplikasi web menerima pesan, aplikasi web menyiarkan ke semua klien. Semakin banyak klien yang disiarkan, semakin banyak lalu lintas pesan yang ada untuk semua klien. Lihat diagram berikut.
Sejumlah kecil klien menyiarkan. Bandwidth pesan masuk kecil, tetapi bandwidth keluar sangat besar. Bandwidth pesan keluar meningkat seiring koneksi klien atau laju siaran yang meningkat.
Tabel berikut meringkas koneksi klien maksimum, jumlah pesan masuk/keluar, dan bandwidth.
| Siaran | 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Pesan masuk per detik | 2.000 | 4.000 | 20.000 | 100.000 | 200.000 | 400.000 | 1\.000.000 | 2.000.000 |
| Bandwidth masuk | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Bandwidth keluar | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Klien penyiaran yang memposting pesan tidak lebih dari empat. Keempatnya memerlukan lebih sedikit server aplikasi dibandingkan echo karena jumlah pesan masuknya sedikit. Dua server aplikasi cukup untuk SLA dan pertimbangan performa. Tetapi Anda harus meningkatkan koneksi server default untuk menghindari ketidakseimbangan, terutama untuk Unit yang lebih besar dari 50.
| Siaran | 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 server aplikasi | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Catatan
Tingkatkan koneksi server default dari 5 ke 40 di setiap server aplikasi untuk menghindari kemungkinan koneksi server yang tidak seimbang ke Azure SignalR Service.
Jumlah koneksi klien, ukuran pesan, laju pengiriman pesan, dan tingkat SKU memengaruhi performa siaran secara keseluruhan.
Kirim ke grup
Kasus penggunaan kirim ke grup memiliki pola lalu lintas yang sama dengan siaran. Perbedaannya adalah setelah klien membuat koneksi WebSocket dengan Azure SignalR Service, mereka harus bergabung ke grup sebelum mengirimkan pesan ke grup tertentu. Diagram berikut mengilustrasikan arus lalu lintasnya.
Anggota grup dan jumlah grup adalah dua faktor yang memengaruhi performa. Untuk menyederhanakan analisisnya, kami mendefinisikan dua jenis grup:
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.
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.
Kirim ke grup menyebabkan adanya biaya perutean untuk Azure SignalR Service karena harus menemukan koneksi target melalui struktur data terdistribusi. Seiring dengan koneksi pengiriman yang meningkat, biayanya juga meningkat.
Grup kecil
Biaya perutean cukup signifikan untuk mengirimkan pesan ke banyak grup kecil. Saat ini, implementasi Azure SignalR Service 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 memerlukan lebih banyak bandwidth masuk, hubungi dukungan pelanggan.
| 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 |
Banyak koneksi klien yang memanggil hub, sehingga jumlah server aplikasi juga sangat penting untuk performa. Tabel berikut mencantumkan jumlah server aplikasi yang disarankan.
| 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 server aplikasi | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Catatan
Jumlah koneksi klien, ukuran pesan, laju pengiriman pesan, biaya perutean, tingkat SKU, dan CPU/memori server aplikasi memengaruhi performa kirim ke grup kecil secara keseluruhan.
Jumlah grup, jumlah anggota grup yang tercantum dalam tabel bukan batas keras. Nilai parameter ini dipilih untuk menetapkan skenario tolok ukur yang stabil. Misalnya, tidak masalah untuk menetapkan setiap conneciton ke grup yang berbeda. Di bawah konfigurasi ini, performa hampir dikirim ke koneksi.
Grup besar
Untuk kirim ke grup besar, bandwidth keluar menjadi hambatan sebelum dibatasi oleh biaya perutean. Tabel berikut mencantumkan bandwidth keluar maksimum, yang nilainya hampir sama dengan siaran.
| 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 | 500 | 1,000 | 2.000 | 5\.000 | 10,000 | 20.000 |
| Jumlah grup | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Pesan masuk per detik | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Bandwidth masuk | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Pesan masuk per detik | 2.000 | 4.000 | 20.000 | 100.000 | 200.000 | 400.000 | 1\.000.000 | 2.000.000 |
| Bandwidth keluar | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Jumlah koneksi pengiriman tidak lebih dari 40. Beban pada server aplikasi cukup ringan, sehingga jumlah aplikasi web yang disarankan sedikit.
| 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 server aplikasi | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Catatan
Tingkatkan koneksi server default dari 5 ke 40 di setiap server aplikasi untuk menghindari kemungkinan koneksi server yang tidak seimbang ke Azure SignalR Service.
Jumlah koneksi klien, ukuran pesan, laju pengiriman pesan, biaya perutean, dan tingkat SKU memengaruhi performa kirim ke grup besar secara keseluruhan.
Kirim ke koneksi
Dalam kasus penggunaan kirim ke koneksi, saat klien membuat koneksi ke Azure SignalR Service, setiap klien memanggil hub khusus untuk mendapatkan ID koneksinya masing-masing. Tolok ukur performa mengumpulkan semua ID koneksi, mengacaknya, dan menetapkannya kembali ke semua klien sebagai target pengiriman. Klien terus mengirim pesan ke koneksi target hingga pengujian performa selesai.
Biaya perutean kirim ke koneksi serupa dengan biaya untuk kirim ke grup kecil.
Ketika jumlah koneksi meningkat, biaya perutean menjadi faktor penting yang membatasi performa keseluruhan. Terutama, Unit 20 menandai ambang di mana layanan mencapai hambatan perutean. Peningkatan lebih lanjut dalam jumlah unit tidak menghasilkan peningkatan performa kecuali ada pergeseran ke Premium_P2(unit >=100), yang meningkatkan kemampuan perutean.
Tabel berikut adalah ringkasan statistik setelah beberapa kali menjalankan tolok ukur kirim ke koneksi.
| Kirim ke koneksi | Unit 1 | Unit 2 | Unit 20 | Unit 50 | Unit 100 | Unit 200 | Unit 500 | Unit 1000 |
|---|---|---|---|---|---|---|---|---|
| Koneksi | 1,000 | 2.000 | 20.000 | 50.000 | 100.000 | 200.000 | 500,000 | 1\.000.000 |
| Pesan masuk/keluar per detik | 1,000 | 2.000 | 20.000 | 20.000 | 20.000 | 40.000 | 100.000 | 200.000 |
| Bandwidth masuk/keluar | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Catatan
Meskipun stagnasi dalam pesan masuk/keluar per detik setelah Unit 20, kapasitas untuk lebih banyak koneksi terus bertambah. Dalam skenario bisnis nyata, sering kali jumlah koneksi, bukan aktivitas pengiriman pesan bersamaan, yang membentuk hambatan. Tidak jarang semua koneksi secara aktif mengirim pesan pada frekuensi tinggi seperti yang dilakukan pengujian tolok ukur.
Kasus penggunaan ini memerlukan beban tinggi di sisi server aplikasi. Lihat jumlah server aplikasi yang disarankan di tabel berikut.
| Kirim ke koneksi | 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 server aplikasi | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Catatan
Jumlah koneksi klien, ukuran pesan, laju pengiriman pesan, biaya perutean, tingkat SKU, dan CPU/memori server aplikasi memengaruhi performa kirim ke koneksi secara keseluruhan.
ASP.NET SignalR
Azure SignalR Service menyediakan kapasitas performa yang sama dengan ASP.NET SignalR.
Mode Tanpa server
Klien dan Azure SignalR Service diperlukan dalam mode tanpa server. Setiap klien mewakili satu koneksi. Klien mengirimkan pesan melalui REST API ke klien lain atau menyiarkan pesan ke semua.
Mengirim pesan dengan kepadatan tinggi melalui REST API tidak seefisien menggunakan WebSocket. Ini mengharuskan Anda untuk membuat koneksi HTTP baru setiap saat, yang merupakan biaya tambahan dalam mode tanpa server.
Siaran melalui REST API
Semua klien membuat koneksi WebSocket dengan Azure SignalR Service. Kemudian beberapa klien mulai menyiarkan melalui REST API. Pengiriman pesan (masuk) semuanya melalui HTTP Post, yang tidak efisien dibandingkan dengan WebSocket.
| 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Pesan masuk per detik | 2.000 | 4.000 | 20.000 | 100.000 | 200.000 | 400.000 | 1\.000.000 | 2.000.000 |
| Bandwidth masuk | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Bandwidth keluar | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Kirim ke pengguna melalui REST API
Tolok ukur menetapkan nama pengguna untuk semua klien sebelum mereka mulai menyambungkan ke Azure SignalR Service. Setelah klien membuat koneksi WebSocket dengan Azure SignalR Service, mereka mulai mengirim pesan ke klien lain melalui HTTP Post.
| 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 | 200 | 400 | 2.000 | 10,000 | 20.000 | 40.000 | 100.000 | 200.000 |
| Bandwidth masuk/Keluar | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Lingkungan pengujian performa
Untuk semua kasus penggunaan yang tercantum di atas, kami melakukan pengujian performa di lingkungan Azure. Paling banyak, kami menggunakan 200 VM klien dan 100 VM server aplikasi. Berikut beberapa detailnya:
Ukuran komputer virtual klien: StandardDS2V2 (2 vCPU, memori 7G)
Ukuran komputer virtual server aplikasi: StandardF4sV2 (4 vCPU, memori 8G)
Koneksi server Azure SignalR SDK: 15
Alat performa
Anda dapat menemukan alat performa untuk Azure SignalR Service di GitHub.
Langkah berikutnya
Dalam artikel ini, Anda mempelajari ringkasan performa Azure SignalR Service dalam skenario penggunaan umum.
Untuk mengetahui detail tentang internal layanan dan penskalaan pada layanan tersebut, baca panduan berikut:
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk