SignalRASP.NET Core barındırma ve ölçeklendirme

  • Makale
  • Okumak için 2 dakika

Andrew Stanton-Brady, Brady Gasterve Tom Dykstra tarafından

Bu makalede, ASP.NET Core kullanan yüksek trafikli uygulamalar için barındırma ve ölçeklendirme konuları açık SignalR ASP.NET Core.

Yapışkan Oturumlar

SignalR , belirli bir bağlantı için tüm HTTP isteklerinin aynı sunucu işlemi tarafından işlentir. Bir SignalR sunucu grubu (birden çok sunucu) üzerinde çalıştır çalıştırılı olduğunda, "yapışkan oturumlar" kullanılmalıdır. "Yapışkan oturumlar" bazı yük dengeciler tarafından oturum benzeşliği olarak da adlandırılan bir durum. Azure App Service yönlendirme için Uygulama İsteği Yönlendirme (ARR) kullanır. "ARR Benzeşmi" ayarını etkinleştirerek Azure App Service "yapışkan oturumlar" etkinleştirebilirsiniz. Yapışkan oturumların gerekli olduğu tek durumlar:

  1. Tek bir sunucuda, tek bir işlemde barındırarak.
  2. Azure Hizmeti'nin SignalR kullanımı.
  3. Tüm istemciler yalnızca WebSockets'i kullanmak üzere yapılandırıldığında ve istemci yapılandırmasında SkipNegotiation ayarı etkinleştirildiğinde.

Diğer tüm durumlarda (Redis arka plan ne zaman kullanılır? dahil), sunucu ortamının yapışkan oturumlar için yapılandırılması gerekir.

için yapılandırma hakkında Azure App Service için SignalR bkz. SignalRAzure App Service için ASP.NET Core uygulaması yayımlama . Azure Hizmeti'nin kullanımına yönelik uygulamalar Blazor için yapışkan oturumları yapılandırma hakkında rehberlik için SignalR bkz. ASP.NET Core barındırma ve dağıtma Blazor Server .

TCP bağlantı kaynakları

Bir web sunucusunun destekleyene eşzamanlı TCP bağlantılarının sayısı sınırlıdır. Standart HTTP istemcileri kısa ömürlü bağlantılar kullanır. İstemci boşta olduğunda ve daha sonra yeniden açıldıktan sonra bu bağlantılar kapatabilirsiniz. Öte yandan, bir bağlantı SignalR kalıcıdır. SignalR bağlantı, istemci boşta olduğunda bile açık kalır. Birçok istemciye hizmet veren yüksek trafikli bir uygulamada, bu kalıcı bağlantılar sunucuların maksimum bağlantı sayısına isabet ettiğine neden olabilir.

Kalıcı bağlantılar ayrıca her bağlantıyı izlemek için biraz ek bellek kullanır.

ile bağlantıyla ilgili kaynakların yoğun kullanımı, aynı sunucuda SignalR barındırılan diğer web uygulamalarını etkileyebilir. Açılan ve kullanılabilir son TCP bağlantılarını tutan diğer web uygulamalarının aynı sunucuya ek bağlantıları SignalR da olmaz.

Sunucunun bağlantıları biterse rastgele yuva hataları ve bağlantı sıfırlama hatalarıyla karşı karşınız. Örnek:

An attempt was made to access a socket in a way forbidden by its access permissions...

Kaynak SignalR kullanımının diğer web uygulamalarına hataya neden olmak zorunda olmadığını tutmak için, SignalR diğer web uygulamalarınıza göre farklı sunucularda çalıştırın.

Kaynak kullanımının uygulamada hatalara neden olup olmadığını tutmak için, bir sunucunun işlemesi gereken bağlantı SignalR SignalR sayısını sınırlamak için ölçeğin ölçeğini açın.

Ölçeği genişletme

kullanan bir SignalR uygulamanın tüm bağlantılarını izlemesi gerekir ve bu da sunucu grubu için sorunlar oluşturur. Bir sunucu ekleyin ve diğer sunucuların bilgisi olmadığını yeni bağlantılar alır. Örneğin, SignalR aşağıdaki diyagramda yer alan her sunucuda diğer sunucularda bağlantıların farkında değildir. Sunuculardan SignalR biri tüm istemcilere ileti göndermek istiyorsa, ileti yalnızca o sunucuya bağlı istemcilere gider.

Ölçeklendirme SignalR bir arka plan olmadan

Bu sorunu çözme seçenekleri Azure SignalR Service ve Redis arka planıdır.

Azure SignalR Hizmeti

Azure Hizmeti, gerçek zamanlı trafik için bir ara sunucu olarak işlev gösterir ve uygulamanın ölçeği birden çok sunucu arasında ölçeklendirildik zaman bir arka plan SignalR olarak iki katına çıkar. Bir istemci sunucuyla her bağlantı başlattığında, istemci hizmete bağlanmak için yeniden yönlendirildi. İşlem aşağıdaki diyagramda gösterildiği gibi:

Azure SignalR Hizmetine bağlantı kurma

Sonuç olarak aşağıdaki diyagramda gösterildiği gibi hizmet tüm istemci bağlantılarını yönetirken her sunucuya yalnızca az sayıda sabit hizmet bağlantısı gerekir:

Hizmete bağlı istemciler, hizmete bağlı sunucular

Bu ölçeğin ölçeğini ölçeklendirme yaklaşımı, Redis arka plan alternatifi üzerinde çeşitli avantajlara sahiptir:

  • İstemci benzeşliği olarak da bilinenyapışkan oturumlar gerekli değildir çünkü istemciler bağlanıldıklarında hemen Azure SignalR Hizmeti'ne yeniden yönlendirilmelidir.
  • Uygulamanın SignalR ölçeği gönderilen ileti sayısına göre uzarken, Azure Hizmeti herhangi bir sayıda bağlantı SignalR işlemek için ölçeklendirebilir. Örneğin, binlerce istemci olabilir, ancak saniye başına yalnızca birkaç ileti gönderilirse, yalnızca bağlantıları işlemek için uygulamanın ölçeğini birden çok sunucuya SignalR ölçeklendirmesi gerek değildir.
  • Bir SignalR uygulama, olmadan bir web uygulamasından çok daha fazla bağlantı kaynağı kullanmaz. SignalR

Bu nedenlerle Azure Hizmeti'nin Azure'da barındırılan ASP.NET Core uygulamalar (App Service, VM'ler ve SignalR SignalR kapsayıcılar dahil) için kullanılması önerilir.

Daha fazla bilgi için Azure Hizmeti SignalR belgelerine bakın.

Redis kartı

Redis, yayımlama/abone olma modeline sahip bir mesajlaşma sistemini destekleyen bir bellek içinde anahtar-değer deposu. SignalRRedis arka plan, iletileri diğer sunuculara göndermek için pub/sub özelliğini kullanır. bir istemci bağlantı larsa, bağlantı bilgileri arka plana geçiri. Bir sunucu tüm istemcilere bir ileti göndermek istiyorsa, arka plana gönderir. Arka plan tüm bağlı istemcileri ve bunların hangi sunucularda olduğunu bilir. İletiyi tüm istemcilere ilgili sunucuları aracılığıyla gönderir. Bu işlem aşağıdaki diyagramda gösterildiği gibi:

Redis backplane, bir sunucudan tüm istemcilere gönderilen ileti

Redis geri planı, kendi altyapınız üzerinde barındırılan uygulamalar için önerilen ölçek ölçeğini dışarı ölçeklendirme yaklaşımıdır. Veri merkeziniz ile Azure veri merkezi arasında önemli bir bağlantı gecikmesi varsa, Azure Hizmeti düşük gecikme süresi veya yüksek aktarım hızı gereksinimleri olan şirket içi uygulamalar için pratik SignalR bir seçenek olabilir.

Daha önce not alan Azure SignalR Hizmeti avantajları, Redis arka planlarının dezavantajlarıdır:

  • aşağıdakilerin her ikisinin de doğru olması dışında,istemci benzeşliği olarak da bilinen yapışkan oturumlar gereklidir:
    • Tüm istemciler yalnızca WebSockets'i kullanmak üzere yapılandırılır.
    • SkipNegotiation ayarı istemci yapılandırmasında etkindir. Sunucuda bağlantı başlatıldıktan sonra bağlantının bu sunucuda kalması gerekir.
  • Bir SignalR uygulamanın ölçeği, çok az ileti gönderse bile istemci sayısına göre uztar.
  • Bir SignalR uygulama, olmadan bir web uygulamasından çok daha fazla bağlantı kaynağı SignalR kullanır.

İstemci işletim sistemi Windows IIS sınırlamaları

Windows 10 ve Windows 8.x, istemci işletim sistemleridir. İstemci işletim sistemlerinde IIS'nin 10 eş zamanlı bağlantı sınırı vardır. SignalR'nin bağlantıları:

  • Geçici ve sık sık yeniden kurulur.
  • Artık kullanılmadan hemen atlanmaz.

Önceki koşullar, istemci işletim sistemi üzerinde 10 bağlantı sınırına ulaşma olasılığına neden olur. Geliştirme için bir istemci işletim sistemi kullanılırsa şunları öneririz:

  • IIS'den kaçının.
  • Dağıtım Kestrel IIS Express veya kullanın.

Nginx ile Linux

Aşağıdakiler için WebSockets, ServerSentEvents ve LongPolling'i etkinleştirmek için gereken en düşük ayarları SignalR içerir:

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
}

  server {
    listen 80;
    server_name example.com *.example.com;

    # Configure the SignalR Endpoint
    location /hubroute {
      # App server url
      proxy_pass http://localhost:5000;

      # Configuration for WebSockets
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_cache off;
      # WebSockets were implemented after http/1.0
      proxy_http_version 1.1;

      # Configuration for ServerSentEvents
      proxy_buffering off;

      # Configuration for LongPolling or if your KeepAliveInterval is longer than 60 seconds
      proxy_read_timeout 100s;

      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
  }
}

Birden çok arka uç sunucusu kullanılırken, bağlantıların bağlanırken sunucuları değiştirmesini önlemek SignalR için yapışkan oturumlar eklenmiştir. Nginx'te yapışkan oturumlar eklemenin birden çok yolu vardır. Kullanılabilirlik durumuna bağlı olarak aşağıda iki yaklaşım gösterilmektedir.

Aşağıdakiler, önceki yapılandırmaya ek olarak eklenir. Aşağıdaki backend örneklerde, sunucu grubunun adıdır.

Nginx Açık Kaynak ile,bağlantıları ip_hash istemcinin IP adresine göre bir sunucuya yönlendirmek için kullanın:

http {
  upstream backend {
    # App server 1
    server localhost:5000;
    # App server 2
    server localhost:5002;

    ip_hash;
  }
}

Nginx Plus ile,isteklere bir eklemek ve kullanıcının isteklerini sticky bir cookie sunucuya sabitlemek için kullanın:

http {
  upstream backend {
    # App server 1
    server localhost:5000;
    # App server 2
    server localhost:5002;

    sticky cookie srv_id expires=max domain=.example.com path=/ httponly;
  }
}

Son olarak, proxy_pass http://localhost:5000 bölümündeki server 'i olarak proxy_pass http://backend değiştirebilirsiniz.

Nginx üzerinden WebSockets hakkında daha fazla bilgi için bkz. WebSocket Proxy'si olarak NGINX.

Yük dengeleme ve yapışkan oturumlar hakkında daha fazla bilgi için bkz. NGINX yük dengeleme.

Nginx ile ASP.NET Core daha fazla bilgi için aşağıdaki makaleye bakın:

Üçüncü taraf SignalR arka plan sağlayıcıları

Sonraki adımlar

Daha fazla bilgi için aşağıdaki kaynaklara bakın: