Performa SignalR

Artikel
07/13/2023

Peringatan

Dokumentasi ini bukan untuk versi terbaru SignalR. Lihat ASP.NET Core SignalR.

Topik ini menjelaskan cara merancang, mengukur, dan meningkatkan performa dalam aplikasi SignalR.

Versi perangkat lunak yang digunakan dalam topik ini

Visual Studio 2013

.NET 4.5

SignalR versi 2

Versi sebelumnya dari topik ini

Untuk informasi tentang versi SignalR yang lebih lama, lihat SignalR Versi Lama.

Pertanyaan dan komentar

Silakan tinggalkan umpan balik tentang bagaimana Anda menyukai tutorial ini dan apa yang dapat kami tingkatkan di komentar di bagian bawah halaman. Jika Anda memiliki pertanyaan yang tidak terkait langsung dengan tutorial, Anda dapat mempostingnya ke forum ASP.NET SignalR atau StackOverflow.com.

Untuk presentasi terbaru tentang performa dan penskalaan SignalR, lihat Menskalakan Web Real-time dengan ASP.NET SignalR.

Topik ini berisi bagian berikut:

Mempertimbangkan rancangan
Menyetel server SignalR Anda untuk performa
Memecahkan masalah performa
Menggunakan penghitung kinerja SignalR
Menggunakan penghitung kinerja lainnya
Sumber daya lainnya

Mempertimbangkan rancangan

Bagian ini menjelaskan pola yang dapat diimplementasikan selama desain aplikasi SignalR, untuk memastikan bahwa performa tidak dihalangi dengan menghasilkan lalu lintas jaringan yang tidak perlu.

Frekuensi pesan pembatasan

Bahkan dalam aplikasi yang mengirimkan pesan pada frekuensi tinggi (seperti aplikasi game realtime), sebagian besar aplikasi tidak perlu mengirim lebih dari beberapa pesan sedetik. Untuk mengurangi jumlah lalu lintas yang dihasilkan setiap klien, perulangan pesan dapat diimplementasikan bahwa antrean dan mengirim pesan tidak lebih sering daripada tarif tetap (yaitu, hingga sejumlah pesan tertentu akan dikirim setiap detik, jika ada pesan dalam interval waktu tersebut yang akan dikirim). Untuk aplikasi sampel yang membatasi pesan ke tingkat tertentu (dari klien dan server), lihat Realtime Frekuensi Tinggi dengan SignalR.

Mengurangi ukuran pesan

Anda dapat mengurangi ukuran pesan SignalR dengan mengurangi ukuran objek serial Anda. Dalam kode server, jika Anda mengirim objek yang berisi properti yang tidak perlu ditransmisikan, cegah properti tersebut JsonIgnore diserialisasikan dengan menggunakan atribut . Nama properti juga disimpan dalam pesan; nama properti dapat disingkat menggunakan JsonProperty atribut . Sampel kode berikut menunjukkan cara mengecualikan properti agar tidak dikirim ke klien, dan cara mempersingkat nama properti:

Kode server .NET yang menunjukkan atribut JsonIgnore untuk mengecualikan data agar tidak dikirim ke klien, dan atribut JsonProperty untuk mengurangi ukuran pesan

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
    [JsonProperty("l")]
    public double Left { get; set; }
    [JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
    [JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

Untuk mempertahankan keterbacaan/pemeliharaan dalam kode klien, nama properti yang disingkat dapat dipetakan ulang ke nama yang ramah manusia setelah pesan diterima. Sampel kode berikut menunjukkan salah satu cara yang mungkin untuk memetakan ulang nama yang dipersingkat ke nama yang lebih panjang, dengan mendefinisikan kontrak pesan (pemetaan), dan menggunakan reMap fungsi untuk menerapkan kontrak ke kelas pesan yang dioptimalkan:

Kode JavaScript sisi klien yang memetakan ulang nama properti yang dipersingkat menjadi nama yang dapat dibaca manusia

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

Nama juga dapat dipersingkat dalam pesan dari klien ke server, menggunakan metode yang sama.

Mengurangi jejak memori (yaitu, jumlah memori yang digunakan untuk pesan) objek pesan juga dapat meningkatkan performa. Misalnya, jika rentang int penuh tidak diperlukan, short atau byte dapat digunakan sebagai gantinya.

Karena pesan disimpan di bus pesan dalam memori server, mengurangi ukuran pesan juga dapat mengatasi masalah memori server.

Menyetel server SignalR Anda untuk performa

Pengaturan konfigurasi berikut dapat digunakan untuk menyetel server Anda untuk performa yang lebih baik dalam aplikasi SignalR. Untuk informasi umum tentang cara meningkatkan performa dalam aplikasi ASP.NET, lihat Meningkatkan Performa ASP.NET.

Pengaturan konfigurasi SignalR

DefaultMessageBufferSize: Secara default, SignalR mempertahankan 1000 pesan dalam memori per hub per koneksi. Jika pesan besar sedang digunakan, ini dapat membuat masalah memori yang dapat dikurangi dengan mengurangi nilai ini. Pengaturan ini dapat diatur dalam Application_Start penanganan aktivitas dalam aplikasi ASP.NET, atau dalam Configuration metode kelas startup OWIN dalam aplikasi yang dihost sendiri. Sampel berikut menunjukkan cara mengurangi nilai ini untuk mengurangi jejak memori aplikasi Anda untuk mengurangi jumlah memori server yang digunakan:

Kode server .NET di Startup.cs untuk mengurangi ukuran buffer pesan default
```
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Any connection or hub wire up and configuration should go here
        GlobalHost.Configuration.DefaultMessageBufferSize = 500;
        app.MapSignalR();
    }
}
```

Pengaturan konfigurasi IIS

Permintaan bersamaan maksimum per aplikasi: Meningkatkan jumlah permintaan IIS bersamaan akan meningkatkan sumber daya server yang tersedia untuk melayani permintaan. Nilai defaultnya adalah 5000; untuk meningkatkan pengaturan ini, jalankan perintah berikut dalam prompt perintah yang ditingkatkan:
```
cd %windir%\System32\inetsrv\
appcmd.exe set config /section:system.webserver/serverRuntime 
        /appConcurrentRequestLimit:10000
```
ApplicationPool QueueLength: Ini adalah jumlah maksimum permintaan yang Http.sys antrean untuk kumpulan aplikasi. Ketika antrean penuh, permintaan baru menerima respons 503 "Layanan Tidak Tersedia". Nilai defaultnya adalah 1000.

Mempersingkat panjang antrean untuk proses pekerja di kumpulan aplikasi yang menghosting aplikasi Anda akan menghemat sumber daya memori. Untuk informasi selengkapnya, lihat Mengelola, Menyetel, dan Mengonfigurasi Kumpulan Aplikasi.

ASP.NET pengaturan konfigurasi

Bagian ini mencakup pengaturan konfigurasi yang dapat diatur dalam aspnet.config file. File ini ditemukan di salah satu dari dua lokasi, tergantung pada platform:

%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET pengaturan yang dapat meningkatkan performa SignalR meliputi hal-hal berikut:

Permintaan bersamaan maksimum per CPU: Meningkatkan pengaturan ini dapat meringankan penyempitan performa. Untuk meningkatkan pengaturan ini, tambahkan pengaturan konfigurasi berikut ke aspnet.config file:
```
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.web>
        <applicationPool maxConcurrentRequestsPerCPU="20000" />
    </system.web>
</configuration>
```
Batas Antrean Permintaan: Ketika jumlah total koneksi melebihi maxConcurrentRequestsPerCPU pengaturan, ASP.NET akan mulai membatasi permintaan menggunakan antrean. Untuk meningkatkan ukuran antrean, Anda dapat meningkatkan requestQueueLimit pengaturan. Untuk melakukan ini, tambahkan pengaturan konfigurasi berikut ke simpul processModel di config/machine.config (bukan aspnet.config):
```
<processModel autoConfig="false" requestQueueLimit="250000" />
```

Memecahkan masalah performa

Bagian ini menjelaskan cara untuk menemukan hambatan performa di aplikasi Anda.

Memverifikasi bahwa WebSocket sedang digunakan

Meskipun SignalR dapat menggunakan berbagai transportasi untuk komunikasi antara klien dan server, WebSocket menawarkan keunggulan performa yang signifikan, dan harus digunakan jika klien dan server mendukungnya. Untuk menentukan apakah klien dan server Anda memenuhi persyaratan untuk WebSocket, lihat Transportasi dan Fallback. Untuk menentukan transportasi apa yang digunakan dalam aplikasi Anda, Anda dapat menggunakan alat pengembang browser, dan memeriksa log untuk melihat transportasi apa yang digunakan untuk koneksi. Untuk informasi tentang menggunakan alat pengembangan browser di Internet Explorer dan Chrome, lihat Transportasi dan Fallback.

Menggunakan penghitung kinerja SignalR

Bagian ini menjelaskan cara mengaktifkan dan menggunakan penghitung kinerja SignalR, yang ditemukan dalam Microsoft.AspNet.SignalR.Utils paket.

Menginstal signalr.exe

Penghitung kinerja dapat ditambahkan ke server menggunakan utilitas yang disebut SignalR.exe. Untuk menginstal utilitas ini, ikuti langkah-langkah berikut:

Di Visual Studio, pilih Alat>NuGet Package Manager>Kelola Paket NuGet untuk Solusi
Cari signalr.utils, dan pilih Instal.
Terima perjanjian lisensi untuk menginstal paket.
SignalR.exe akan diinstal ke <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Menginstal penghitung kinerja dengan SignalR.exe

Untuk menginstal penghitung kinerja SignalR, jalankan SignalR.exe di prompt perintah yang ditingkatkan dengan parameter berikut:

SignalR.exe ipc

Untuk menghapus penghitung kinerja SignalR, jalankan SignalR.exe di prompt perintah yang ditingkatkan dengan parameter berikut:

SignalR.exe upc

Penghitung Performa SignalR

Paket utilitas menginstal penghitung kinerja berikut. Penghitung "Total" mengukur jumlah peristiwa sejak kumpulan aplikasi terakhir atau menghidupkan ulang server.

Metrik koneksi

Metrik berikut mengukur peristiwa seumur hidup koneksi yang terjadi. Untuk informasi selengkapnya, lihat Memahami dan Menangani Peristiwa Seumur Hidup Koneksi.

Koneksi Tersambung
Koneksi Tersambung Kembali
Koneksi Terputus
Koneksi Saat Ini

Metrik pesan

Metrik berikut mengukur lalu lintas pesan yang dihasilkan oleh SignalR.

Total Pesan Koneksi yang Diterima
Total Pesan Koneksi Terkirim
Pesan Koneksi Diterima/Detik
Pesan Koneksi Terkirim/Detik

Metrik bus pesan

Metrik berikut mengukur lalu lintas melalui bus pesan SignalR internal, antrean tempat semua pesan SignalR masuk dan keluar ditempatkan. Pesan Diterbitkan saat dikirim atau disiarkan. Pelanggan dalam konteks ini adalah langganan di bus pesan; ini harus sama dengan jumlah klien ditambah server itu sendiri. Pekerja yang Dialokasikan adalah komponen yang mengirim data ke koneksi aktif; Pekerja Sibuk adalah pekerja yang secara aktif mengirim pesan.

Total Pesan Bus Pesan diterima
Pesan Bus Pesan Diterima/Detik
Total Pesan Bus Pesan yang Diterbitkan
Pesan Bus Pesan Diterbitkan/Detik
Pelanggan Bus Pesan Saat Ini
Total Pelanggan Bus Pesan
Pelanggan Bus Pesan/Detik
Pekerja Yang Dialokasikan Bus Pesan
Pekerja Sibuk Pesan
Topik Bus Pesan Saat Ini

Metrik kesalahan

Metrik berikut mengukur kesalahan yang dihasilkan oleh lalu lintas pesan SignalR. Kesalahan Resolusi Hub terjadi ketika metode hub atau hub tidak dapat diselesaikan. Kesalahan Pemanggilan Hub adalah pengecualian yang dilemparkan saat memanggil metode hub. Kesalahan transportasi adalah kesalahan koneksi yang dilemparkan selama permintaan atau respons HTTP.

Kesalahan: Semua Total
Kesalahan: Semua/Detik
Kesalahan: Total Resolusi Hub
Kesalahan: Resolusi Hub/Detik
Kesalahan: Total Pemanggilan Hub
Kesalahan: Pemanggilan Hub/Detik
Kesalahan: Total Transportasi
Kesalahan: Transport/Sec

Metrik scaleout

Metrik berikut mengukur lalu lintas dan kesalahan yang dihasilkan oleh penyedia scaleout. Stream dalam konteks ini adalah unit skala yang digunakan oleh penyedia scaleout; ini adalah tabel jika SQL Server digunakan, Topik jika Bus Layanan digunakan, dan Langganan jika Redis digunakan. Setiap aliran memastikan operasi baca dan tulis yang diurutkan; aliran tunggal adalah penyempitan skala potensial, sehingga jumlah aliran dapat ditingkatkan untuk membantu mengurangi penyempitan tersebut. Jika beberapa aliran digunakan, SignalR akan secara otomatis mendistribusikan (shard) pesan di seluruh aliran ini dengan cara yang memastikan pesan yang dikirim dari koneksi tertentu berurutan.

Pengaturan MaxQueueLength mengontrol panjang antrean pengiriman scaleout yang dikelola oleh SignalR. Mengaturnya ke nilai yang lebih besar dari 0 akan menempatkan semua pesan dalam antrean kirim untuk dikirim satu per satu ke backplane olahpesan yang dikonfigurasi. Jika ukuran antrean melampaui panjang yang dikonfigurasi, panggilan berikutnya untuk mengirim akan segera gagal dengan InvalidOperationException hingga jumlah pesan dalam antrean kurang dari pengaturan lagi. Antrean dinonaktifkan secara default karena backplanes yang diterapkan umumnya memiliki antrean atau kontrol aliran mereka sendiri. Dalam kasus SQL Server, pengumpulan koneksi secara efektif membatasi jumlah pengiriman yang terjadi kapan saja.

Secara default, hanya satu aliran yang digunakan untuk SQL Server dan Redis, lima aliran digunakan untuk Azure Service Bus, dan antrean dinonaktifkan, tetapi pengaturan ini dapat diubah melalui konfigurasi pada SQL Server dan Azure Service Bus:

Kode Server .NET untuk mengonfigurasi jumlah tabel dan panjang antrean untuk backplane SQL Server

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
TableCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

Kode Server .NET untuk mengonfigurasi jumlah topik dan panjang antrean untuk backplane Azure Service Bus

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
TopicCount = 3,
MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

Aliran Buffering adalah aliran yang telah memasuki status rusak; ketika aliran dalam status rusak, semua pesan yang dikirim ke backplane akan segera gagal sampai aliran tidak lagi rusak. Panjang Kirim Antrean adalah jumlah pesan yang telah diposting tetapi belum dikirim.

Pesan Bus Pesan Scaleout Diterima/Detik
Total Aliran Scaleout
Scaleout Streams Open
Penyanggaan Stream Scaleout
Total Kesalahan Scaleout
Kesalahan Scaleout/Detik
Perluasan Skala Kirim Panjang Antrean

Untuk informasi selengkapnya tentang pengukur penghitung ini, lihat SignalR Scaleout dengan Azure Service Bus.

Menggunakan penghitung kinerja lainnya

Penghitung kinerja berikut mungkin juga berguna dalam memantau performa aplikasi Anda.

Memori

.NET CLR Memory\# byte di semua Heaps (untuk w3wp)

ASP.NET

ASP.NET\Requests Current
ASP.NET\Antrean
ASP.NET\Ditolak

CPU

Informasi Prosesor\Waktu Prosesor

TCP/IP

TCPv6/Koneksi Dibuat
TCPv4/Koneksi Dibuat

Layanan Web

Layanan Web\Koneksi Saat Ini
Layanan Web\Koneksi Maksimum

Pengaluran

.NET CLR Locks And Threads\# dari Thread logis saat ini
.NET CLR Locks And Threads\# dari Thread fisik saat ini

Sumber Daya Lain

Untuk informasi selengkapnya tentang pemantauan dan penyetelan performa ASP.NET, lihat topik berikut:

Bagikan melalui