SignalR’da Ölçek Genişletmeye Giriş

Patrick Fletcher tarafından

Uyarı

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

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.

Genel olarak, bir web uygulamasını ölçeklendirmenin iki yolu vardır: ölçeği artırma ve genişletme.

• Ölçeği artırma, daha fazla RAM, CPU vb. olan daha büyük bir sunucu (veya daha büyük bir VM) kullanmak anlamına gelir.
• Ölçeği genişletme, yükü işlemek için daha fazla sunucu eklemek anlamına gelir.

Ölçeği artırmayla ilgili sorun, makinenin boyutu üzerinde hızla bir sınıra ulaşmanızdır. Bunun ötesinde ölçeği genişletmeniz gerekir. Ancak ölçeği genişlettiğiniz zaman istemciler farklı sunuculara yönlendirilebilir. Bir sunucuya bağlı bir istemci, başka bir sunucudan gönderilen iletileri almaz.

Çözümlerden biri, arka plan olarak adlandırılan bir bileşeni kullanarak iletileri sunucular arasında iletmektir. Bir arka plan etkinleştirildiğinde, her uygulama örneği iletileri arka plana gönderir ve arka plan bunları diğer uygulama örneklerine iletir. (Elektronikte, arka düzlem bir paralel bağlayıcı grubudur. Benzer şekilde SignalR arka düzlemi birden çok sunucuyu bağlar.)

SignalR şu anda üç arka plan sağlar:

• Azure Service Bus. Service Bus, bileşenlerin gevşek bir şekilde ileti göndermesine olanak tanıyan bir mesajlaşma altyapısıdır.
• Redis'i seçin. Redis bellek içi anahtar-değer deposudur. Redis, ileti göndermek için yayımlama/abone olma ("pub/sub") deseni destekler.
• SQL Server. SQL Server arka planı, iletileri SQL tablolarına yazar. Arka plan, verimli mesajlaşma için Hizmet Aracısı'nı kullanır. Ancak, Hizmet Aracısı etkin değilse de çalışır.

Uygulamanızı Azure'da dağıtırsanız Azure Redis Cache kullanarak Redis arka düzlemini kullanmayı göz önünde bulundurun. Kendi sunucu grubunuz için dağıtım kullanıyorsanız SQL Server veya Redis arka planlarını göz önünde bulundurun.

Aşağıdaki konular, her bir arka plan için adım adım öğreticiler içerir:

• Azure Service Bus ile SignalR Ölçeğini Genişletme
• Redis ile SignalR Ölçeğini Genişletme
• SQL Server ile SignalR Ölçeğini Genişletme

Uygulama

SignalR'de her ileti bir ileti veri yolu üzerinden gönderilir. İleti veri yolu, yayımlama/abone olma soyutlaması sağlayan IMessageBus arabirimini uygular. Arka düzlemler, varsayılan IMessageBus yerine bu arka plan için tasarlanmış bir veri yolu ile çalışır. Örneğin, Redis için ileti veri yolu RedisMessageBus'tır ve ileti gönderip almak için Redis pub/sub mekanizmasını kullanır.

Her sunucu örneği, veri yolu aracılığıyla arka plana bağlanır. Bir ileti gönderildiğinde, geri düzleme gider ve arka düzlem bunu her sunucuya gönderir. Bir sunucu arka düzlemden bir ileti aldığında, iletiyi yerel önbelleğine yerleştirir. Sunucu daha sonra iletileri istemcilere yerel önbelleğinden teslim eder.

Her istemci bağlantısı için, istemcinin ileti akışını okumadaki ilerlemesi bir imleç kullanılarak izlenir. (İmleç, ileti akışındaki bir konumu temsil eder.) İstemcinin bağlantısı kesilirse ve yeniden bağlanırsa, istemcinin imleç değerinden sonra gelen iletiler veri yolunu sorar. Bağlantı uzun yoklama kullandığında da aynı şey olur. Uzun bir yoklama isteği tamamlandıktan sonra istemci yeni bir bağlantı açar ve imleç sonrasında gelen iletileri ister.

yeniden bağlantıda istemci farklı bir sunucuya yönlendirilmiş olsa bile imleç mekanizması çalışır. Arka düzlem tüm sunucuların farkındadır ve istemcinin hangi sunucuya bağlandığı önemli değildir.

Sınırlamalar

Bir arka plan kullanıldığında, en yüksek ileti aktarım hızı istemciler doğrudan tek bir sunucu düğümüyle konuştuğunda olduğundan daha düşüktür. Bunun nedeni, arka düzlemin her iletiyi her düğüme iletmesi ve böylece arka düzlemin bir performans sorununa dönüşebilmesidir. Bu sınırlamanın bir sorun olup olmadığı uygulamaya bağlıdır. Örneğin, bazı tipik SignalR senaryoları şunlardır:

• Sunucu yayını (örn. hisse senedi değer çizgisi): Sunucu iletilerin gönderilme hızını denetlediğinden, bu senaryo için geri düzlemler iyi çalışır.
• İstemciden istemciye (ör. sohbet): Bu senaryoda, ileti sayısı istemci sayısıyla ölçeklendiriliyorsa arka plan bir performans sorunu olabilir; diğer bir ifadeyle, daha fazla istemci katıldıkça iletilerin oranı orantılı olarak artar.
• Yüksek frekanslı gerçek zamanlı (ör. gerçek zamanlı oyunlar): Bu senaryo için arka plan önerilmez.

SignalR ÖlçeğiNi Genişletme için İzlemeyi Etkinleştirme

Arka planlarda izlemeyi etkinleştirmek için kök yapılandırma öğesinin altındaki web.config dosyasına aşağıdaki bölümleri ekleyin:

<configuration>
  <system.diagnostics>
    <sources>
      <source name="SignalR.SqlMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ServiceBusMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ScaleoutMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="SignalRSwitch" value="Verbose" />
      <!-- Off, Critical, Error, Warning, Information, Verbose -->
    </switches>
    <sharedListeners>
      <add name="SignalR-Bus" 
          type="System.Diagnostics.TextWriterTraceListener" 
          initializeData="bus.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>
  . . .
</configuration>