SignalR Performansı

tarafından Patrick Fletcher

Uyarı

Bu belgeler SignalR'nin en son sürümüne yönelik değildir. ASP.NET Core SignalR'a göz atın.

Bu konu başlığında SignalR uygulamasında performansın nasıl tasarlandığı, ölçüldiği ve artırıldığı açıklanmaktadır.

Bu konuda kullanılan yazılım sürümleri

• Visual Studio 2013
• .NET 4.5
• SignalR sürüm 2

Bu konunun önceki sürümleri

SignalR'nin önceki sürümleri hakkında bilgi için bkz. SignalR Eski Sürümleri.

Sorular ve yorumlar

Lütfen bu öğreticiyi nasıl beğendiğiniz ve sayfanın altındaki yorumlarda neleri geliştirebileceğimiz hakkında geri bildirim bırakın. Öğreticiyle doğrudan ilgili olmayan sorularınız varsa bunları ASP.NET SignalR forumunu veya StackOverflow.com gönderebilirsiniz.

SignalR performansı ve ölçeklendirme hakkında yeni bir sunu için bkz. ASP.NET SignalR ile Gerçek Zamanlı Web'i ölçeklendirme.

Bu konu, aşağıdaki bölümleri içerir:

• Tasarımda dikkat edilmesi gerekenler
• SignalR sunucunuzu performans için ayarlama
• Performans sorunlarını giderme
• SignalR performans sayaçlarını kullanma
• Diğer performans sayaçlarını kullanma
• Diğer kaynaklar

Tasarımla ilgili dikkat edilecek noktalar

Bu bölümde, gereksiz ağ trafiği oluşturarak performansın engellenmediğinden emin olmak için SignalR uygulamasının tasarımı sırasında uygulanabilecek desenler açıklanmaktadır.

İleti sıklığını sınırlama

İletileri yüksek sıklıkta (gerçek zamanlı oyun uygulaması gibi) gönderen bir uygulamada bile çoğu uygulamanın saniyede birkaç iletiden fazla göndermesi gerekmez. Her istemcinin oluşturduğu trafik miktarını azaltmak için, iletileri sabit bir hızdan daha sık olmamak üzere kuyruğa alan ve gönderen bir ileti döngüsü uygulanabilir (yani, bu zaman aralığında iletiler varsa, her saniye belirli sayıda ileti gönderilir). İletileri belirli bir hıza (hem istemciden hem de sunucudan) kısıtlayan örnek bir uygulama için, bkz. SignalR ile Yüksek Frekanslı Gerçek Zamanlı.

İleti boyutunu küçültme

Serileştirilmiş nesnelerinizin boyutunu küçülterek SignalR iletisinin boyutunu küçültebilirsiniz. Sunucu kodunda, iletilmesi gerekmeyen özellikler içeren bir nesne gönderiyorsanız, özniteliğini kullanarak bu özelliklerin JsonIgnore seri hale gelmesini önleyin. Özelliklerin adları da iletide depolanır; özelliklerin adları özniteliği kullanılarak JsonProperty kısaltılabilir. Aşağıdaki kod örneğinde, bir özelliğin istemciye gönderilmesini dışlama ve özellik adlarını kısaltma işlemleri gösterilmektedir:

verileri istemciye gönderilmekten dışlamak için JsonIgnore özniteliğini ve ileti boyutunu küçültmek için JsonProperty özniteliğini gösteren .NET sunucu kodu

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; }
}

İstemci kodunda okunabilirliği/sürdürülebilirliği korumak için, kısaltılmış özellik adları ileti alındıktan sonra insan dostu adlara yeniden eşlenebilir. Aşağıdaki kod örneği, bir ileti sözleşmesi tanımlayarak (eşleme) ve iyileştirilmiş ileti sınıfına sözleşmeyi uygulamak için işlevini kullanarak reMap kısaltılmış adları daha uzun adlara yeniden eşlemenin olası bir yolunu gösterir:

Kısaltılmış özellik adlarını okunabilir adlarla yeniden eşleyen istemci tarafı JavaScript kodu

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
};

Adlar, istemciden sunucuya iletilerde de aynı yöntem kullanılarak kısaltılabilir.

İleti nesnesinin bellek ayak izini (yani ileti için kullanılan bellek miktarını) azaltmak da performansı iyileştirebilir. Örneğin, bir int aralığının tamamı gerekli değilse, bunun yerine bir short veya byte kullanılabilir.

İletiler ileti veri yolu içinde sunucu belleğinde depolandığından, iletilerin boyutunu azaltmak sunucu belleği sorunlarını da giderebilir.

SignalR sunucunuzu performans için ayarlama

SignalR uygulamasında daha iyi performans için sunucunuzu ayarlamak için aşağıdaki yapılandırma ayarları kullanılabilir. ASP.NET bir uygulamada performansı iyileştirme hakkında genel bilgi için bkz. ASP.NET Performansını Geliştirme.

SignalR yapılandırma ayarları

• DefaultMessageBufferSize: SignalR varsayılan olarak bağlantı başına hub başına bellekte 1000 ileti tutar. Büyük iletiler kullanılıyorsa, bu değer azaltılarak hafifletilebilen bellek sorunları oluşturabilir. Bu ayar, bir ASP.NET uygulamasındaki Application_Start olay işleyicisinde veya kendinden barındırmalı bir uygulamada OWIN başlangıç sınıfının Configuration yönteminde ayarlanabilir. Aşağıdaki örnek, kullanılan sunucu belleği miktarını azaltmak için uygulamanızın bellek ayak izini azaltmak için bu değerin nasıl azaltılabileceğini gösterir:

  Varsayılan ileti arabelleği boyutunu azaltmak için Startup.cs'de .NET sunucu kodu

  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();
      }
  }
  

IIS yapılandırma ayarları

• Uygulama başına en fazla eşzamanlı istek: Eşzamanlı IIS isteklerinin sayısının artırılması, isteklerin sunulması için kullanılabilir sunucu kaynaklarını artırır. Varsayılan değer 5000'dir; bu ayarı artırmak için yükseltilmiş bir komut isteminde aşağıdaki komutları yürütebilirsiniz:

  cd %windir%\System32\inetsrv\
  appcmd.exe set config /section:system.webserver/serverRuntime 
          /appConcurrentRequestLimit:10000
  

• ApplicationPool QueueLength: Bu, Http.sys tarafından uygulama havuzu için kuyrukta bekletilen isteklerin maksimum sayısıdır. Kuyruk dolduğunda, yeni istekler 503 "Hizmet Kullanılamıyor" yanıtı alır. Varsayılan değer 1000'dir.

  Uygulamanızı barındıran uygulama havuzunda çalışan işlemi için kuyruk uzunluğunu kısaltmak bellek kaynaklarını korur. Daha fazla bilgi için bkz. Uygulama Havuzlarını Yönetme, Ayarlama ve Yapılandırma.

ASP.NET yapılandırma ayarları

Bu bölüm, aspnet.config dosyasına ayarlanabilen yapılandırma ayarlarını içerir. Bu dosya platforma bağlı olarak iki konumdan birinde bulunur:

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

SignalR performansını geliştirebilecek ASP.NET ayarları şunlardır:

• CPU başına en fazla eşzamanlı istek sayısı: Bu ayarın artırılması performans sorunlarını hafifletebilir. Bu ayarı artırmak için dosyaya aşağıdaki yapılandırma ayarını aspnet.config ekleyin:

  <?xml version="1.0" encoding="UTF-8" ?>
  <configuration>
      <system.web>
          <applicationPool maxConcurrentRequestsPerCPU="20000" />
      </system.web>
  </configuration>
  

• İstek Sırası Sınırı: Toplam bağlantı sayısı ayarı aştığında maxConcurrentRequestsPerCPU ASP.NET kuyruk kullanarak istekleri azaltmaya başlar. Kuyruğun boyutunu artırmak için ayarı artırabilirsiniz requestQueueLimit . Bunu yapmak için aspnet.config yerine processModel düğümündeki config/machine.config, aşağıdaki yapılandırma ayarını ekleyin:

  <processModel autoConfig="false" requestQueueLimit="250000" />
  

Performans sorunlarını giderme

Bu bölümde, uygulamanızda performans sorunlarını bulmanın yolları açıklanmaktadır.

WebSocket'in kullanıldığını doğrulama

SignalR, istemci ve sunucu arasındaki iletişim için çeşitli aktarımları kullanabilir ancak WebSocket önemli bir performans avantajı sunar ve istemci ve sunucu destekliyorsa kullanılmalıdır. İstemcinizin ve sunucunuzun WebSocket gereksinimlerini karşılayıp karşılamadığını belirlemek için bkz . Aktarımlar ve Geri Dönüşler. Uygulamanızda hangi taşımanın kullanıldığını belirlemek için tarayıcı geliştirici araçlarını kullanabilir ve bağlantı için hangi taşımanın kullanıldığını görmek için günlükleri inceleyebilirsiniz. Internet Explorer ve Chrome'da tarayıcı geliştirme araçlarını kullanma hakkında bilgi için bkz . Aktarımlar ve Geri Dönüşler.

SignalR performans sayaçlarını kullanma

Bu bölümde, pakette Microsoft.AspNet.SignalR.Utils bulunan SignalR performans sayaçlarının nasıl etkinleştirileceği ve kullanılacağı açıklanmaktadır.

signalr.exe yükleme

Performans sayaçları, SignalR.exeadlı bir yardımcı program kullanılarak sunucuya eklenebilir. Bu yardımcı programı yüklemek için şu adımları izleyin:

1. Visual Studio'da Araçlar>NuGet Paket Yöneticisi>Çözüm için NuGet Paketlerini Yönet'i seçin

2. signalr.utils araması yapın ve Yükle'yi seçin.

   

3. Paketi yüklemek için lisans sözleşmesini kabul edin.

4. SignalR.exe <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools konumuna yüklenecek.

SignalR.exe ile performans sayaçlarını yükleme

SignalR performans sayaçlarını yüklemek için yükseltilmiş bir komut isteminde aşağıdaki parametreyle SignalR.exe çalıştırın:

SignalR.exe ipc

SignalR performans sayaçlarını kaldırmak için yükseltilmiş bir komut isteminde aşağıdaki parametreyle SignalR.exe çalıştırın:

SignalR.exe upc

SignalR Performans sayaçları

Yardımcı programlar paketi aşağıdaki performans sayaçlarını yükler. "Toplam" sayaçları, son uygulama havuzu veya sunucu yeniden başlatmadan bu yana gerçekleşen olayların sayısını ölçer.

Bağlantı ölçümleri

Aşağıdaki ölçümler, gerçekleşen bağlantı ömrü olaylarını ölçer. Daha fazla bilgi için bkz. Bağlantı Ömrü Olaylarını Anlama ve İşleme.

• Bağlı Bağlantılar
• Yeniden Bağlanan Bağlantılar
• Bağlantı Kesildi
• Geçerli Bağlantılar

İleti ölçümleri

Aşağıdaki ölçümler SignalR tarafından oluşturulan ileti trafiğini ölçer.

• Alınan Bağlantı İletileri Toplamı
• Toplam Gönderilen Bağlantı İletileri
• Alınan Bağlantı Mesajları/Saniye
• Gönderilen Bağlantı Mesajları/Saniye

İleti veri yolu ölçümleri

Aşağıdaki ölçümler, tüm gelen ve giden SignalR iletilerinin yerleştirildiği kuyruk olan dahili SignalR ileti veri yolu üzerinden trafiği ölçer. İleti gönderildiğinde veya yayınlandığında Yayımlanır . Abone bu bağlamda, mesaj veri yolu üzerindeki bir aboneliktir; bu, istemciler ve sunucunun kendisi dahil olmak üzere toplam sayıya eşit olmalıdır. Ayrılmış Çalışan, etkin bağlantılara veri gönderen bir bileşendir; Meşgul Çalışanı, etkin bir şekilde ileti gönderen çalışandır.

• Alınan İleti Veri Yolu İletileri Toplam
• Alınan İleti Veri Yolu İletileri/Sn
• Message Bus Üzerinde Yayımlanan İletilerin Toplamı
• Saniyede Yayımlanan Mesaj Veri Yolu İletileri
• İleti Veri Yolu Aboneleri Geçerli
• Mesaj Veri Yolu Aboneleri Toplamı
• İleti Veri Yolu Aboneleri/Sn
• Mesajlaşma Veri Yolu Atanan Çalışanlar
• Mesaj Yolu Yoğun Çalışanlar
• İleti Veri Yolu Konuları Geçerli

Hata ölçümleri

Aşağıdaki ölçümler SignalR ileti trafiği tarafından oluşturulan hataları ölçer. Hub Çözümleme hataları, bir hub veya hub yöntemi çözümlenemediğinde oluşur. Hub Çağırma hataları, bir hub yöntemi çağrılırken oluşan özel durumlardır. Taşıma hataları, bir HTTP isteği veya yanıtı sırasında meydana gelen bağlantı hatalarıdır.

• Hatalar: Tüm Toplam
• Hatalar: Tümü/Saniye
• Hatalar: Merkez Çözümleme Toplamı
• Hatalar: Hub Çözümlemesi/Sn
• Hatalar: Hub Çağırma Toplamı
• Hatalar: Hub Çağırma/Sn
• Hatalar: Taşıma Toplamı
• Hatalar: Aktarım/Sn

Ölçek genişletme ölçümleri

Aşağıdaki ölçümler, ölçek genişletme sağlayıcısı tarafından oluşturulan trafiği ve hataları izler. Bu Akış, bu bağlamda ölçek genişletme sağlayıcısı tarafından kullanılan bir ölçek birimidir; SQL Server kullanıldığında bir tablo, Service Bus kullanıldığında bir konu ve Redis kullanıldığında bir aboneliktir. Her akış, sıralı okuma ve yazma işlemleri sağlar; tek bir akış olası bir ölçek performans sorunu olduğundan, bu performans sorununu azaltmaya yardımcı olmak için akış sayısı artırılabilir. Birden çok akış kullanılırsa SignalR, herhangi bir bağlantıdan gönderilen iletilerin sıralı olmasını sağlayacak şekilde, iletileri otomatik olarak bu akışlar arasında (parçalayarak) dağıtır.

MaxQueueLength ayarı SignalR tarafından tutulan ölçek genişletme gönderme kuyruğunun uzunluğunu denetler. Bunu 0'dan büyük bir değere ayarlamak, tüm iletileri yapılandırılan mesajlaşma arka planına birer birer gönderilecek bir gönderme kuyruğuna yerleştirir. Kuyruğun boyutu yapılandırılan uzunluğun üzerine çıkarsa, kuyruktaki ileti sayısı yeniden ayardan az olana kadar gönderilecek sonraki çağrılar InvalidOperationException ile hemen başarısız olur. Uygulanan backplane'ler genellikle kendi kuyruklama veya akış denetimine sahip olduklarından, kuyruk oluşturma varsayılan olarak devre dışıdır. SQL Server söz konusu olduğunda, bağlantı havuzu herhangi bir anda devam eden gönderme sayısını etkili bir şekilde sınırlar.

Varsayılan olarak, SQL Server ve Redis için yalnızca bir akış kullanılır, Service Bus için beş akış kullanılır ve kuyruğa alma devre dışı bırakılır, ancak bu ayarlar SQL Server ve Service Bus'ta yapılandırma yoluyla değiştirilebilir:

SQL Server arka planı için tablo sayısını ve kuyruk uzunluğunu yapılandırmak için .NET Server Kodu

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

Service Bus arka düzlemi için konu sayısını ve kuyruk uzunluğunu yapılandırmak için .NET Sunucu Kodu

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

Arabelleğe alma akışı, arıza durumuna giren bir akıştır. Akış arıza durumunda olduğunda, arka düzleme gönderilen tüm iletiler, akış arıza durumundan çıkana kadar hemen başarısız olacaktır. Gönderim Kuyruğu Uzunluğu, gönderilmiş ancak henüz iletilmemiş mesajların sayısıdır.

• Scaleout Mesaj Veri Yolu Alınan Mesajlar/Sn
• Yayılma Akışları Toplamı
• Scaleout Streams Açık
• Ölçek Genişletme Akışları Arabelleğe Alma
• Ölçekleme Hataları Toplamı
• Ölçek Genişletme Hataları/Sn
• Dağıtık Gönderi Kuyruğu Uzunluğu

Bu sayaçların neleri ölçtüğü hakkında daha fazla bilgi için bkz. Azure Service Bus ile SignalR Ölçeklendirme.

Diğer performans sayaçlarını kullanma

Aşağıdaki performans sayaçları, uygulamanızın performansını izlemede de yararlı olabilir.

Memory

• .NET CLR Belleği\ Tüm Yığınlardaki Bayt Sayısı (w3wp için)

ASP.NET

• ASP.NET\Mevcut İstekler
• ASP.NET\Kuyruğa Alındı
• ASP.NET\Reddedildi

CPU

• İşlemci Bilgileri\İşlemci Zamanı

TCP/IP

• TCPv6/Kurulan Bağlantılar
• TCPv4/Kurulan Bağlantılar

Web Hizmeti

• Web Hizmeti\Geçerli Bağlantılar
• Web Hizmeti\En Fazla Bağlantı Sayısı

İş Parçacığı Oluşturma

• Geçerli mantıksal İş Parçacıklarının .NET CLR Kilitleri Ve İş Parçacıkları\#
• .NET CLR Kilitleri ve İş Parçacıkları \# Geçerli Fiziksel İş Parçacıkları Sayısı

Diğer Kaynaklar

ASP.NET performans izleme ve ayarlama hakkında daha fazla bilgi için aşağıdaki konulara bakın:

• ASP.NET Performansına Genel Bakış
• IIS 7.5, IIS 7.0 ve IIS 6.0'da ASP.NET İş Parçacığı Kullanımı
• <applicationPool> Öğesi (Web Ayarları)