Azure SignalR Hizmeti için performans kılavuzu
Azure SignalR Hizmeti kullanmanın temel avantajlarından biri SignalR uygulamalarını ölçeklendirme kolaylığıdır. Büyük ölçekli bir senaryoda performans önemli bir faktördür.
Bu makalede şunlar açıklanmaktadır:
- SignalR uygulama performansını etkileyen faktörler.
- Farklı kullanım örneği senaryolarında tipik performans.
- Performans raporu oluşturmak için kullanabileceğiniz ortam ve araçlar.
Ölçümleri kullanarak hızlı değerlendirme
Hizmetinizi Azure portalından kolayca izleyebilirsiniz. SignalR örneğinizin Ölçümler sayfasından Sunucu Yükü ölçümlerini seçerek hizmetinizin "baskısını" görebilirsiniz.
Grafikte SignalR hizmetinizin işlem baskısı gösterilir. Senaryonuzu test edebilir ve ölçeği artırmaya karar vermek için bu ölçümü de kontrol edebilirsiniz. Sunucu Yükü %70'in altındaysa SignalR hizmetindeki gecikme süresi düşük kalır.
Dekont
50. veya daha büyük bir birim kullanıyorsanız ve senaryonuz çoğunlukla küçük gruplara (grup boyutu <20) veya tek bir bağlantıya gönderiyorsa, başvuru için küçük gruba göndermeyi veya bağlantıya göndermeyi denetlemeniz gerekir. Bu senaryolarda, Sunucu Yükü'ne dahil olmayan büyük yönlendirme maliyeti vardır.
Terim tanımları
Gelen: Azure SignalR Hizmeti gelen ileti.
Giden: Azure SignalR Hizmeti giden ileti.
Bant genişliği: Tüm iletilerin toplam boyutu 1 saniyedir.
Varsayılan mod: bir Azure SignalR Hizmeti örneği oluşturulduğunda varsayılan çalışma modu. Azure SignalR Hizmeti, uygulama sunucusunun herhangi bir istemci bağlantısını kabul etmeden önce onunla bağlantı kurmasını bekler.
Sunucusuz mod: Azure SignalR Hizmeti yalnızca istemci bağlantılarını kabul ettiği mod. Sunucu bağlantısına izin verilmez.
Genel Bakış
Azure SignalR Hizmeti farklı performans kapasiteleri için yedi Standart katman tanımlar. Bu kılavuz aşağıdaki soruları yanıtlar:
Her katman (birim) için tipik Azure SignalR Hizmeti performansı nedir?
Azure SignalR Hizmeti ileti aktarım hızı gereksinimlerimi karşılıyor mu (örneğin, saniyede 100.000 ileti göndermek)?
Özel senaryom için uygun katmanı nasıl seçebilirim?
Ne tür bir uygulama sunucusu (VM boyutu) benim için uygundur? Kaç tane dağıtmalıyım?
Bu soruları yanıtlamak için, bu kılavuz önce performansı etkileyen faktörlerin üst düzey bir açıklamasını sunar. Daha sonra, yankı, yayın, gruba gönderme ve bağlantıya gönderme (eşler arası sohbet) gibi tipik kullanım örnekleri için her katman için en fazla gelen ve giden ileti sayısını gösterir.
Bu kılavuz tüm senaryoları (ve farklı kullanım örneklerini, ileti boyutlarını, ileti gönderme desenlerini vb.) kapsamaz. Ancak size yardımcı olacak bazı yöntemler sağlar:
- Gelen veya giden iletiler için yaklaşık gereksiniminizi değerlendirin.
- Performans tablosunu denetleyerek uygun katmanları bulun.
Performans içgörüleri
Bu bölümde performans değerlendirme yöntemleri açıklanır ve ardından performansı etkileyen tüm faktörler listelenir. Sonunda, performans gereksinimlerini değerlendirmenize yardımcı olacak yöntemler sağlar.
Metodoloji
Aktarım hızı ve gecikme süresi , performans denetiminin iki tipik yönüdür. Azure SignalR Hizmeti için her SKU katmanının kendi aktarım hızı azaltma ilkesi vardır. İlke, iletilerin yüzde 99'unda 1 saniyeden daha az gecikme süresi olduğunda elde edilen maksimum aktarım hızı olarak izin verilen en yüksek aktarım hızını (gelen ve giden bant genişliği) tanımlar.
Gecikme süresi, iletiyi gönderen bağlantıdan yanıt iletisinin Azure SignalR Hizmeti alınmasına kadar geçen süredir. Echo'yu örnek olarak ele alalım. Her istemci bağlantısı iletiye bir zaman damgası ekler. Uygulama sunucusunun hub'ı özgün iletiyi istemciye geri gönderir. Bu nedenle yayma gecikmesi her istemci bağlantısı tarafından kolayca hesaplanır. Yayındaki, gruba gönder ve bağlantıya gönder içindeki her ileti için zaman damgası eklenir.
Binlerce eşzamanlı istemci bağlantısının benzetimini yapmak için Azure'da bir sanal özel ağda birden çok VM oluşturulur. Bu VM'lerin tümü aynı Azure SignalR Hizmeti örneğine bağlanır.
Varsayılan Azure SignalR Hizmeti modunda, uygulama sunucusu VM'leri istemci VM'lerle aynı sanal özel ağa dağıtılır. Bölgeler arası gecikme süresini önlemek için tüm istemci VM'ler ve uygulama sunucusu VM'leri aynı bölgenin aynı ağına dağıtılır.
Performans faktörleri
Aşağıdaki faktörler SignalR performansını etkiler.
- SKU katmanı (CPU/bellek)
- Bağlantı sayısı
- İleti boyutu
- İleti gönderme hızı
- Aktarım türü (WebSocket, Server-Sent-Event veya Long-Polling)
- Kullanım örneği senaryosu (yönlendirme maliyeti)
- Uygulama sunucusu ve hizmet bağlantıları (sunucu modunda)
Bilgisayar kaynakları
Teorik olarak Azure SignalR Hizmeti kapasitesi işlem kaynaklarıyla sınırlıdır: CPU, bellek ve ağ. Örneğin, Azure SignalR Hizmeti için daha fazla bağlantı, hizmetin daha fazla bellek kullanmasına neden olur. Daha büyük ileti trafiği için (örneğin, her ileti 2.048 bayttan büyük), Azure SignalR Hizmeti trafiği işlemek için daha fazla CPU döngüsü harcaması gerekir. Bu arada Azure ağ bant genişliği de maksimum trafik için bir sınır getirir.
Aktarım türü
Aktarım türü, performansı etkileyen bir diğer faktördür. Üç tür şunlardır:
- WebSocket: WebSocket, tek bir TCP bağlantısı üzerinden çift yönlü ve tam çift yönlü bir iletişim protokolüdür.
- Sunucu-Gönderilen-Olay: Sunucu-Gönderilen-Olay, sunucudan istemciye ileti göndermeye ilişkin tek yönlü bir protokoldür.
- Uzun Yoklama: Uzun Yoklama, istemcilerin bir HTTP isteği aracılığıyla sunucudan düzenli aralıklarla bilgileri yoklamasını gerektirir.
Aynı koşullar altında aynı API için WebSocket en iyi performansa sahiptir, Server-Sent-Event daha yavaştır ve Uzun Yoklama en yavaştır. Azure SignalR Hizmeti varsayılan olarak WebSocket'i önerir.
İleti yönlendirme maliyeti
İleti yönlendirme maliyeti performansı da sınırlar. Azure SignalR Hizmeti, iletiyi bir dizi istemciden veya sunucudan diğer istemcilere veya sunuculara yönlendiren bir ileti yönlendiricisi olarak rol oynar. Farklı bir senaryo veya API için farklı bir yönlendirme ilkesi gerekir.
Yankı için istemci kendisine bir ileti gönderir ve yönlendirme hedefi de kendisidir. Bu desen en düşük yönlendirme maliyetine sahiptir. Ancak yayın için gruba gönder ve bağlantıya gönder Azure SignalR Hizmeti iç dağıtılmış veri yapısı aracılığıyla hedef bağlantıları araması gerekir. Bu ek işlem daha fazla CPU, bellek ve ağ bant genişliği kullanır. Sonuç olarak performans daha yavaştır.
Varsayılan modda, uygulama sunucusu da belirli senaryolar için bir performans sorunu haline gelebilir. Azure SignalR SDK'sının hub'ı çağırması gerekirken sinyal sinyalleri aracılığıyla her istemciyle canlı bağlantı sağlar.
Sunucusuz modda, istemci HTTP gönderisi ile bir ileti gönderir ve bu ileti WebSocket kadar verimli değildir.
Protokol
Bir diğer faktör de protokoldür: JSON ve MessagePack. MessagePack'in boyutu daha küçüktür ve JSON'dan daha hızlı teslim edilir. Ancak MessagePack performansı geliştirmeyebilir. İstemcilerden sunuculara ileti iletirken ileti yükünün kodunu çözmediği için Azure SignalR Hizmeti performansı protokollere duyarlı değildir.
Uygun bir SKU bulma
Gelen/giden kapasiteyi nasıl değerlendirebilir veya belirli bir kullanım örneğine uygun katmanı nasıl bulabilirsiniz?
Uygulama sunucusunun yeterince güçlü olduğunu ve performans sorunu olmadığını varsayın. Ardından, her katman için en yüksek gelen ve giden bant genişliğini denetleyin.
Hızlı değerlendirme
Hızlı değerlendirme için aşağıdaki varsayılan ayarları varsayın:
- Aktarım türü WebSocket'tir.
- İleti boyutu 2.048 bayttır.
- Her 1 saniyede bir ileti gönderilir.
- Azure SignalR Hizmeti varsayılan moddadır.
Her katmanın kendi maksimum gelen bant genişliği ve giden bant genişliği vardır. Gelen veya giden bağlantı sınırı aştıktan sonra sorunsuz bir kullanıcı deneyimi garanti değildir.
Echo , en düşük yönlendirme maliyetine sahip olduğundan en yüksek gelen bant genişliğini verir. Yayın , giden ileti bant genişliği üst sınırını tanımlar.
Aşağıdaki iki tabloda vurgulanan değerleri aşmayın.
| Yankı | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Gelen bant genişliği | 2 MB/sn | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Giden bant genişliği | 2 Mb/sn | 4 Mb/sn | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Yayın | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Gelen bant genişliği | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn |
| Giden bant genişliği | 4 MBps | 8 MB/sn | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Gelen bant genişliği ve giden bant genişliği , saniye başına toplam ileti boyutudır. Bunlar için formüller şunlardır:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
gelen Bağlan ions: İletiyi gönderen bağlantı sayısı.
giden Bağlan ions: İletiyi alan bağlantı sayısı.
messageSize: Tek bir iletinin boyutu (ortalama değer). 1.024 bayttan küçük bir iletinin, 1.024 baytlık iletiye benzer bir performans etkisi vardır.
sendInterval: Bir ileti gönderme zamanı. Genellikle ileti başına 1 saniyedir, yani her saniye bir ileti gönderilir. Daha küçük bir aralık, bir zaman aralığında daha fazla ileti gönderme anlamına gelir. Örneğin, ileti başına 0,5 saniye, her saniye iki ileti göndermek anlamına gelir.
Bağlan ions: Her katman için Azure SignalR Hizmeti için işlenen maksimum eşik. Bağlantı numarası daha fazla artırılırsa, bağlantı azaltmadan muzdariptir.
Dekont
Birim boyutunun 100'den büyük olması için SKU Premium_P2 ölçeğini artırmanız gerekir.
Karmaşık kullanım örnekleri için değerlendirme
Daha büyük ileti boyutu veya farklı gönderme hızı
Gerçek kullanım örneği daha karmaşıktır. 2.048 bayttan büyük bir ileti gönderebilir veya gönderilen ileti hızı saniyede bir ileti değildir. Şimdi 100. Ünitenin performansını değerlendirmeye yönelik bir örnek olarak yayınını ele alalım.
Aşağıdaki tabloda gerçek bir yayın kullanım durumu gösterilmektedir. Ancak ileti boyutu, bağlantı sayısı ve ileti gönderme hızı önceki bölümde varsaydığımızdan farklıdır. Soru, yalnızca ikisini tanıyorsak bu öğelerden herhangi birini (ileti boyutu, bağlantı sayısı veya ileti gönderme hızı) nasıl çıkaracağımızdır.
| Yayın | İleti boyutu | Eşzamanlı gelen iletiler | Bağlantılar | Gönderme aralıkları |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100.000 | 5 sn |
| 2 | 256 KB | 1 | 8,000 | 5 sn |
Aşağıdaki formül, önceki formüle göre kolayca çıkarılır:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Birim 100 için, önceki tablodan en fazla giden bant genişliği 400 MB'tır. 20 KB ileti boyutu için, en fazla giden bağlantı sayısı gerçek değerle eşleşen 400 MB * 5 / 20 KB = 100.000 olmalıdır.
Karma kullanım örnekleri
Gerçek kullanım örneği genellikle dört temel kullanım örneğini birlikte karıştırır: yankı, yayın, gruba gönderme ve bağlantıya gönderme. Kapasiteyi değerlendirmek için kullandığınız metodoloji şu şekildedir:
- Karma kullanım örneklerini dört temel kullanım örneğine bölün.
- Önceki formülleri ayrı ayrı kullanarak en fazla gelen ve giden ileti bant genişliğini hesaplayın.
- Toplam gelen/giden bant genişliği üst sınırını almak için bant genişliği hesaplamalarını toplama.
Ardından en yüksek gelen/giden bant genişliği tablolarından uygun katmanı alın.
Dekont
Yüzlerce veya binlerce küçük gruba ileti göndermek veya binlerce istemcinin birbirine ileti göndermesi için yönlendirme maliyeti baskın hale gelir. Bu etkiyi hesaba kat.
İstemcilere ileti göndermenin kullanım örneği için uygulama sunucusunun performans sorunu olmadığından emin olun. Aşağıdaki "Örnek olay incelemesi" bölümünde, kaç uygulama sunucusuna ihtiyacınız olduğu ve kaç sunucu bağlantısı yapılandırmanız gerektiği hakkında yönergeler verilmektedir.
Örnek olay incelemesi
Aşağıdaki bölümler WebSocket aktarımı için dört tipik kullanım örneğinden geçer: yankı, yayın, gruba gönder ve bağlantıya gönder. Her senaryo için bölümünde, Azure SignalR Hizmeti için geçerli gelen ve giden kapasite listelenir. Ayrıca performansı etkileyen ana faktörleri de açıklar.
Varsayılan modda, uygulama sunucusu Azure SignalR Hizmeti ile beş sunucu bağlantısı oluşturur. Uygulama sunucusu varsayılan olarak Azure SignalR Hizmeti SDK'sını kullanır. Aşağıdaki performans testi sonuçlarında sunucu bağlantıları 15'e yükseltilir (veya büyük bir gruba ileti yayınlamak ve göndermek için daha fazla).
Farklı kullanım örneklerinin uygulama sunucuları için farklı gereksinimleri vardır. Yayın için az sayıda uygulama sunucusu gerekir. Yankı veya bağlantıya gönderme için birçok uygulama sunucusu gerekir.
Tüm kullanım örneklerinde varsayılan ileti boyutu 2.048 bayt ve ileti gönderme aralığı 1 saniyedir.
Varsayılan mod
İstemciler, web uygulaması sunucuları ve Azure SignalR Hizmeti varsayılan modda yer alır. Her istemci tek bir bağlantı anlamına gelir.
Yankı
İlk olarak, bir web uygulaması Azure SignalR Hizmeti bağlanır. İkinci olarak, birçok istemci web uygulamasına bağlanır ve bu da istemcileri erişim belirteci ve uç nokta ile Azure SignalR Hizmeti yönlendirir. Ardından istemciler Azure SignalR Hizmeti ile WebSocket bağlantıları kurar.
Tüm istemciler bağlantı kurduktan sonra, her saniye belirli bir hub'a zaman damgası içeren bir ileti göndermeye başlar. Hub, iletiyi özgün istemcisine geri yankılar. Her istemci, yankı iletisini geri aldığında gecikme süresini hesaplar.
Aşağıdaki diyagramda, 5 ile 8 (kırmızı vurgulanmış trafik) bir döngü içindedir. Döngü varsayılan süre (5 dakika) boyunca çalışır ve tüm ileti gecikme süresinin istatistiğini alır.
Yankı davranışı, en fazla gelen bant genişliğinin maksimum giden bant genişliğine eşit olduğunu belirler. Ayrıntılar için aşağıdaki tabloya bakın.
| Yankı | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Saniye başına gelen/giden iletiler | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Gelen/giden bant genişliği | 2 Mb/sn | 4 Mb/sn | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Bu kullanım örneğinde, her istemci uygulama sunucusunda tanımlanan hub'ı çağırır. Hub yalnızca özgün istemci tarafında tanımlanan yöntemi çağırır. Bu hub, yankı için en basit merkezdir.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Bu basit hub için bile, yankı gelen ileti yükü arttıkça uygulama sunucusundaki trafik baskısı belirgindir. Bu trafik baskısı, büyük SKU katmanları için birçok uygulama sunucusu gerektirir. Aşağıdaki tabloda her katman için uygulama sunucusu sayısı listelenmiştir.
| Yankı | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Uygulama sunucusu sayısı | 1 | 1 | 1 | 5 | 10 | 20 | 50 | Kategori 100 |
Dekont
Uygulama sunucusunun istemci bağlantı numarası, ileti boyutu, ileti gönderme hızı, SKU katmanı ve CPU/bellek, yankının genel performansını etkiler.
Yayın
Yayın için, web uygulaması iletiyi aldığında tüm istemcilere yayınlar. Yayımlamak için ne kadar çok istemci varsa, tüm istemcilere ileti trafiği de o kadar fazla olur. Aşağıdaki diyagrama bakın.
Az sayıda istemci yayınlanıyor. Gelen ileti bant genişliği küçük, ancak giden bant genişliği çok büyük. İstemci bağlantısı veya yayın hızı arttıkça giden ileti bant genişliği artar.
Aşağıdaki tabloda en fazla istemci bağlantısı, gelen/giden ileti sayısı ve bant genişliği özetlemektedir.
| Yayın | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Saniye başına gelen iletiler | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Saniye başına giden iletiler | 2.000 | 4.000 | 20,000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Gelen bant genişliği | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn |
| Giden bant genişliği | 4 Mb/sn | 8 Mb/sn | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
İletileri yayınlayan yayın istemcileri en fazla dört istemcidir. Gelen ileti miktarı küçük olduğundan echo ile karşılaştırıldığında daha az uygulama sunucusuna ihtiyaçları vardır. Hem SLA hem de performans açısından dikkat edilmesi gerekenler için iki uygulama sunucusu yeterlidir. Ancak, özellikle 50'den büyük Birim için dengesizliği önlemek için varsayılan sunucu bağlantılarını artırmanız gerekir.
| Yayın | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Uygulama sunucusu sayısı | 1 | 1 | Kategori 1 | 2 | 2 | 4 | 10 | 20 |
Dekont
Azure SignalR Hizmeti olası dengesiz sunucu bağlantılarını önlemek için her uygulama sunucusunda varsayılan sunucu bağlantılarını 5'ten 40'a yükseltin.
İstemci bağlantı numarası, ileti boyutu, ileti gönderme hızı ve SKU katmanı yayının genel performansını etkiler.
Gruba gönder
Gruba gönder kullanım örneği, yayına benzer bir trafik düzenine sahiptir. Aradaki fark, istemciler Azure SignalR Hizmeti ile WebSocket bağlantıları kurduktan sonra belirli bir gruba ileti gönderebilmek için önce gruplara katılmaları gerekir. Aşağıdaki diyagramda trafik akışı gösterilmektedir.
Grup üyesi ve grup sayısı, performansı etkileyen iki faktörden biridir. Analizi basitleştirmek için iki tür grup tanımlarız:
Küçük grup: Her grubun 10 bağlantısı vardır. Grup numarası (maksimum bağlantı sayısı) / 10'a eşittir. Örneğin, Birim 1 için 1.000 bağlantı sayısı varsa, 1000 / 10 = 100 grubumuz vardır.
Büyük grup: Grup numarası her zaman 10'dur. Grup üyesi sayısı (maksimum bağlantı sayısı) / 10'a eşittir. Örneğin, Birim 1 için 1.000 bağlantı sayısı varsa, her grubun 1000 / 10 = 100 üyesi vardır.
Gruba gönder, dağıtılmış veri yapısı aracılığıyla hedef bağlantıları bulması gerektiğinden Azure SignalR Hizmeti yönlendirme maliyeti getirir. Gönderen bağlantılar arttıkça maliyet de artar.
Küçük grup
Yönlendirme maliyeti, iletinin birçok küçük gruba gönderilmesi için önemlidir. Şu anda Azure SignalR Hizmeti uygulaması 50. Ünitede yönlendirme maliyeti sınırına ulaştı. Daha fazla CPU ve bellek eklemek işe yaramaz, bu nedenle Birim 100 tasarım gereği daha fazla geliştiremez. Daha fazla gelen bant genişliğine ihtiyacınız varsa müşteri desteğine başvurun.
| Küçük gruba gönder | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Grup üyesi sayısı | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Grup sayısı | 100 | 200 | 1,000 | 5.000 | 10,000 | 20,000 | 50,000 | 100.000 |
| Saniye başına gelen iletiler | 200 | 400 | 2.000 | Kategori 10,000 | Kategori 10,000 | 20,000 | 50,000 | 100.000 |
| Gelen bant genişliği | 400 KB/sn | 800 KB/sn | 4 Mb/sn | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Saniye başına giden iletiler | 2.000 | 4.000 | 20,000 | 100.000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Giden bant genişliği | 4 Mb/sn | 8 Mb/sn | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Birçok istemci bağlantısı hub'ı çağırdığından, uygulama sunucu numarası performans açısından da kritik önem taşır. Aşağıdaki tabloda önerilen uygulama sunucusu sayıları listelenmiştir.
| Küçük gruba gönder | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Uygulama sunucusu sayısı | 1 | 1 | 1 | 5 | 10 | 20 | 50 | Kategori 100 |
Dekont
Uygulama sunucusunun istemci bağlantı numarası, ileti boyutu, ileti gönderme hızı, yönlendirme maliyeti, SKU katmanı ve CPU/bellek, küçük gruba gönderme işleminin genel performansını etkiler.
Tabloda listelenen grup sayısı, grup üyesi sayısı sabit sınırlar değildir. Bu parametre değerleri, kararlı bir karşılaştırma senaryosu oluşturmak için seçilir. Örneğin, her bir conneciton ayrı bir gruba atanamaz. Bu yapılandırma altında, performans bağlantıya göndermeye yakındır.
Büyük grup
Büyük gruba gönderme için giden bant genişliği, yönlendirme maliyet sınırına erişmeden önce performans sorununa dönüşür. Aşağıdaki tabloda, yayın için neredeyse aynı olan maksimum giden bant genişliği listeleniyor.
| Büyük gruba gönder | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Grup üyesi sayısı | 100 | 200 | 500 | 1.000 | 2.000 | 5.000 | 10,000 | 20,000 |
| Grup sayısı | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Saniye başına gelen iletiler | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Gelen bant genişliği | 40 KB/sn | 40 KB/sn | 40 KB/sn | 40 KB/sn | 40 KB/sn | 40 KB/sn | 40 KB/sn | 40 KB/sn |
| Saniye başına giden iletiler | 2.000 | 4.000 | 20,000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Giden bant genişliği | 4 Mb/sn | 8 Mb/sn | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Gönderen bağlantı sayısı en fazla 40'tır. Uygulama sunucusundaki yük küçük olduğundan önerilen web uygulaması sayısı azdır.
| Büyük gruba gönder | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Uygulama sunucusu sayısı | 1 | Kategori 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Dekont
Azure SignalR Hizmeti olası dengesiz sunucu bağlantılarını önlemek için her uygulama sunucusunda varsayılan sunucu bağlantılarını 5'ten 40'a yükseltin.
İstemci bağlantı numarası, ileti boyutu, ileti gönderme oranı, yönlendirme maliyeti ve SKU katmanı büyük gruba gönderme işleminin genel performansını etkiler.
Bağlantıya gönder
Bağlantıya gönder kullanım örneğinde, istemciler Azure SignalR Hizmeti bağlantıları kurduğunda, her istemci kendi bağlantı kimliğini almak için özel bir hub çağırır. Performans karşılaştırması tüm bağlantı kimliklerini toplar, karıştırılır ve tüm istemcilere gönderme hedefi olarak yeniden atanır. İstemciler, performans testi bitene kadar iletiyi hedef bağlantıya göndermeye devam eder.
Bağlantıya göndermenin yönlendirme maliyeti, küçük gruba gönderme maliyetine benzer.
Bağlantı sayısı arttıkça yönlendirme maliyeti, genel performansı sınırlayan kritik bir faktör haline gelir. Özellikle, Birim 20 hizmetin yönlendirme performans sorununa geldiği eşiği işaretler. Birim sayısındaki daha fazla artış, yönlendirme özelliklerini geliştiren Premium_P2(birim >=100) arasında geçiş yapılmadığı sürece performans iyileştirmeleri sağlamaz.
Aşağıdaki tablo, bağlantı karşılaştırmasına gönderme işleminin çok sayıda çalıştırılmasından sonra istatistiksel bir özettir.
| Bağlantıya gönder | Birim 1 | Birim 2 | Birim 20 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | 20,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Saniye başına gelen/giden iletiler | 1.000 | 2.000 | 20,000 | 20,000 | 20,000 | 40,000 | 100.000 | 200,000 |
| Gelen/giden bant genişliği | 2 Mb/sn | 4 Mb/sn | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Dekont
Birim 20'den sonra saniye başına gelen/giden iletilerdeki durgunluklara rağmen, daha fazla bağlantı kapasitesi artmaya devam eder. Gerçek iş senaryolarında, genellikle performans sorununu oluşturan, eşzamanlı ileti gönderme etkinlikleri değil, bağlantıların sayısıdır. Tüm bağlantıların, kıyaslama testinde olduğu gibi yüksek frekanslarda etkin bir şekilde ileti göndermesi sık karşılaşılan bir durum değildir.
Bu kullanım örneği, uygulama sunucusu tarafında yüksek yük gerektirir. Aşağıdaki tabloda önerilen uygulama sunucusu sayısına bakın.
| Bağlantıya gönder | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Uygulama sunucusu sayısı | 1 | 1 | 1 | 5 | 10 | 20 | 50 | Kategori 100 |
Dekont
Uygulama sunucusu için istemci bağlantı numarası, ileti boyutu, ileti gönderme hızı, yönlendirme maliyeti, SKU katmanı ve CPU/bellek, bağlantıya gönderme işleminin genel performansını etkiler.
ASP.NET SignalR
Azure SignalR Hizmeti, ASP.NET SignalR için aynı performans kapasitesini sağlar.
Sunucusuz mod
İstemciler ve Azure SignalR Hizmeti sunucusuz modda yer alır. Her istemci tek bir bağlantı anlamına gelir. İstemci, REST API aracılığıyla iletileri başka bir istemciye gönderir veya iletileri tümüne yayınlar.
REST API aracılığıyla yüksek yoğunluklu iletiler göndermek, WebSocket kullanmak kadar verimli değildir. Her seferinde yeni bir HTTP bağlantısı oluşturmanız gerekir ve bu da sunucusuz modda ek ücrete tabidir.
REST API aracılığıyla yayın
Tüm istemciler Azure SignalR Hizmeti ile WebSocket bağlantıları kurar. Ardından bazı istemciler REST API aracılığıyla yayın yapmaya başlar. Gönderen (gelen) iletinin tamamı HTTP Post üzerinden yapılır ve Bu, WebSocket ile karşılaştırıldığında verimli değildir.
| REST API aracılığıyla yayın | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Saniye başına gelen iletiler | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Saniye başına giden iletiler | 2.000 | 4.000 | 20,000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Gelen bant genişliği | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn | 4 KB/sn |
| Giden bant genişliği | 4 MBps | 8 MB/sn | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
REST API aracılığıyla kullanıcıya gönderme
Karşılaştırma, Azure SignalR Hizmeti bağlanmaya başlamadan önce tüm istemcilere kullanıcı adları atar. İstemciler Azure SignalR Hizmeti ile WebSocket bağlantıları kurduktan sonra, HTTP Post aracılığıyla başkalarına ileti göndermeye başlarlar.
| REST API aracılığıyla kullanıcıya gönderme | Birim 1 | Birim 2 | Birim 10 | Birim 50 | Birim 100 | Birim 200 | Birim 500 | Birim 1000 |
|---|---|---|---|---|---|---|---|---|
| Bağlantılar | 1.000 | 2.000 | Kategori 10,000 | 50,000 | 100.000 | 200,000 | 500,000 | 1.000.000 |
| Saniye başına gelen/giden iletiler | 200 | 400 | 2.000 | Kategori 10,000 | 20,000 | 40,000 | 100.000 | 200,000 |
| Gelen/Giden bant genişliği | 400 KB/sn | 800 KB/sn | 4 Mb/sn | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Performans testi ortamları
Yukarıda listelenen tüm kullanım örnekleri için performans testlerini bir Azure ortamında gerçekleştirdik. En fazla 200 istemci VM ve 100 uygulama sunucusu VM'sini kullandık. Bazı ayrıntılar şunlardır:
İstemci VM boyutu: StandardDS2V2 (2 vCPU, 7G bellek)
Uygulama sunucusu VM boyutu: StandardF4sV2 (4 vCPU, 8G bellek)
Azure SignalR SDK sunucu bağlantıları: 15
Performans araçları
Azure SignalR Hizmeti için performans araçlarını GitHub'da bulabilirsiniz.
Sonraki adımlar
Bu makalede, tipik kullanım örneği senaryolarında Azure SignalR Hizmeti performansına genel bir bakış edindik.
Hizmetin iç işlevleri ve bunun için ölçeklendirme hakkında ayrıntılı bilgi edinmek için aşağıdaki kılavuzları okuyun: