Sunucu tarafı Blazor uygulamaları barındırma ve dağıtma

Bu makalede, ASP.NET Core kullanarak sunucu tarafı Blazor uygulamaları (Blazor Web Uygulamaları ve uygulamalar) barındırma ve Blazor Server dağıtma işlemleri açıklanmaktadır.

Konak yapılandırma değerleri

Sunucu tarafı Blazor uygulamalar Genel Ana Bilgisayar yapılandırma değerlerini kabul edebilir.

Dağıtım

Sunucu tarafı barındırma modeli kullanılarak, Blazor ASP.NET Core uygulamasının içinden sunucuda yürütülür. Kullanıcı arabirimi güncelleştirmeleri, olay işleme ve JavaScript çağrıları bir SignalR bağlantı üzerinden işlenir.

ASP.NET Core uygulaması barındırabilen bir web sunucusu gereklidir. Visual Studio sunucu tarafı uygulama proje şablonu içerir. Proje şablonları hakkında Blazor daha fazla bilgi için bkz . ASP.NET Core Blazor proje yapısı.

Bir uygulamayı Yayın yapılandırması'nda yayımlayın ve yer tutucunun bin/Release/{TARGET FRAMEWORK}/publish hedef çerçeve olduğu {TARGET FRAMEWORK} klasörün içeriğini dağıtın.

Ölçeklenebilirlik

Tek bir sunucunun ölçeklenebilirliğini göz önünde bulundurarak (ölçeği artırdığınızda), bir uygulamanın kullanabileceği bellek büyük olasılıkla kullanıcı talebi arttıkça uygulamanın tükettiği ilk kaynaktır. Sunucudaki kullanılabilir bellek aşağıdakileri etkiler:

• Bir sunucunun destekleyebilecek etkin devre sayısı.
• İstemcide kullanıcı arabirimi gecikme süresi.

Güvenli ve ölçeklenebilir sunucu tarafı Blazor uygulamaları oluşturma yönergeleri için aşağıdaki kaynaklara bakın:

• ASP.NET Core Blazor statik sunucu tarafı işleme için tehdit azaltma kılavuzu
• ASP.NET Core Blazor etkileşimli sunucu tarafı işleme için tehdit azaltma kılavuzu

Her bağlantı hattı, en az Merhaba Dünya stilindeki bir uygulama için yaklaşık 250 KB bellek kullanır. Bir bağlantı hattının boyutu, uygulamanın koduna ve her bileşenle ilişkili durum bakım gereksinimlerine bağlıdır. Uygulamanız ve altyapınız için geliştirme sırasında kaynak taleplerini ölçmenizi öneririz, ancak aşağıdaki temel dağıtım hedefinizi planlamada bir başlangıç noktası olabilir: Uygulamanızın 5.000 eşzamanlı kullanıcıyı desteklemesini bekliyorsanız, uygulamaya en az 1,3 GB sunucu belleği (veya kullanıcı başına yaklaşık 273 KB) bütçelendirmeyi göz önünde bulundurun.

SignalR yapılandırması

SignalR'nin barındırma ve ölçeklendirme koşulları kullanan SignalRuygulamalar için Blazor geçerlidir.

Yapılandırma yönergeleri de dahil olmak üzere uygulamalar hakkında SignalR daha fazla bilgi için bkz. ASP.NET Çekirdek BlazorSignalR kılavuzu.Blazor

Taşımalar

Blazordaha düşük gecikme süresi, daha iyi güvenilirlik ve gelişmiş güvenlik nedeniyle aktarım olarak SignalR WebSockets kullanırken en iyi sonucu verir. Uzun Yoklama , WebSockets kullanılamadığında veya uygulama Uzun Yoklama kullanacak şekilde açıkça yapılandırıldığında tarafından SignalR kullanılır. Azure Uygulaması Hizmeti'ne dağıtım yaparken, uygulamayı hizmetin Azure portalı ayarlarında WebSockets kullanacak şekilde yapılandırın. uygulamayı Azure Uygulaması Hizmeti için yapılandırma hakkında ayrıntılı bilgi için yayımlama yönergelerine SignalRbakın.

Uzun Yoklama kullanılıyorsa bir konsol uyarısı görüntülenir:

Uzun Yoklama geri dönüş aktarımı kullanılarak WebSockets aracılığıyla bağlanılamadı. Bunun nedeni, bağlantıyı engelleyen bir VPN veya ara sunucu olabilir.

Genel dağıtım ve bağlantı hataları

Coğrafi veri merkezlerine genel dağıtımlar için Öneriler:

• Uygulamayı kullanıcıların çoğunun bulunduğu bölgelere dağıtın.
• Kıtalar arasındaki trafik için artan gecikme süresini dikkate alın. Yeniden bağlantı kullanıcı arabiriminin görünümünü denetlemek için bkz . ASP.NET Çekirdek BlazorSignalR kılavuzu.
• Azure barındırma için Azure SignalR Hizmeti'ni kullanın.

Azure SignalR Hizmeti

Etkileşimli Blazor sunucu tarafı işlemeyi benimseyen Web Uygulamaları için Azure SignalR Hizmeti'ni kullanmayı göz önünde bulundurun. Hizmet, uygulamanın Hub'ı Blazor ile birlikte çalışarak çok sayıda eşzamanlı SignalR bağlantıya kadar ölçeklendirilebilir. Buna ek olarak, hizmetin küresel erişim ve yüksek performanslı veri merkezleri coğrafya nedeniyle gecikme süresini azaltmaya önemli ölçüde yardımcı olur. Barındırma ortamınız bu endişeleri zaten ele aldıysa Azure SignalR Hizmeti'ni kullanmak gerekli değildir.

Not

Durum bilgisi olan yeniden bağlantı (WithStatefulReconnect), .NET 8 ile yayımlandı ancak şu anda Azure SignalR Hizmeti için desteklenmiyor. Daha fazla bilgi için bkz . Durum Bilgisi Olan Yeniden Bağlanma Desteği? (Azure/azure-signalr #1878).

Önemli

WebSockets devre dışı bırakıldığında, Azure Uygulaması Hizmeti HTTP Uzun Yoklama kullanarak gerçek zamanlı bir bağlantının simülasyonunu oluşturur. HTTP Uzun Yoklama, WebSockets etkinken çalışmaktan çok daha yavaştır ve istemci-sunucu bağlantısının benzetimini yapmak için yoklama kullanmaz. Uzun Yoklama'nın kullanılması gerektiğinde, hizmetin WebSockets'ten Uzun Yoklama'ya geri dönmesi durumunda Azure SignalR Hizmeti'ndeUzun Yoklama bağlantıları için izin verilen en yüksek yoklama aralığını tanımlayan en yüksek yoklama aralığını ()MaxPollIntervalInSeconds yapılandırmanız gerekebilir. Sonraki yoklama isteği içinde MaxPollIntervalInSecondsgelmezse Azure SignalR Hizmeti istemci bağlantısını temizler. Azure SignalR Hizmeti'nin, hizmet performansını sağlamak için önbellekte arabellek boyutunun 1 MB'tan büyük olması beklenirken bağlantıları da temizlediğini unutmayın. için MaxPollIntervalInSeconds varsayılan değer 5 saniyedir. Ayar 1-300 saniye ile sınırlıdır.

Azure Uygulaması Hizmetine dağıtılan sunucu tarafı Blazor uygulamalar için WebSockets kullanmanızı öneririz. Azure SignalR Hizmeti varsayılan olarak WebSockets kullanır. Uygulama Azure SignalR Hizmetini kullanmıyorsa bkz. ASP.NET Core SignalR uygulamasını Azure Uygulaması Hizmeti'ne yayımlama.

Daha fazla bilgi için bkz.

• Azure SignalR Hizmeti nedir?
• Azure SignalR Hizmeti için performans kılavuzu
• ASP.NET Core SignalR uygulamasını Azure Uygulaması Hizmeti'ne yayımlama

Yapılandırma

Azure SignalR Hizmeti için bir uygulama yapılandırmak için uygulamanın, istemcilerin ön kullanım sırasında aynı sunucuya yeniden yönlendirildiği yapışkan oturumları desteklemesi gerekir. Seçenek ServerStickyMode veya yapılandırma değeri olarak Requiredayarlanır. Genellikle bir uygulama aşağıdaki yaklaşımlardan birini kullanarak yapılandırmayı oluşturur:

• Program.cs:

  builder.Services.AddSignalR().AddAzureSignalR(options =>
  {
      options.ServerStickyMode = 
          Microsoft.Azure.SignalR.ServerStickyMode.Required;
  });
  

• Yapılandırma (aşağıdaki yaklaşımlardan birini kullanın):

  • appsettings.json içinde:

    "Azure:SignalR:ServerStickyMode": "Required"
    

  • Uygulama hizmetinin Azure portalındaki Yapılandırma>Uygulaması ayarları (Ad: Azure__SignalR__ServerStickyMode, Değer: Required). Bu yaklaşım, Azure SignalR Hizmeti'ni sağladığınızda uygulama için otomatik olarak benimsenmiştir.

Not

Aşağıdaki hata, Azure SignalR Hizmeti için yapışkan oturumları etkinleştirmemiş bir uygulama tarafından oluşturulur:

blazor.server.js:1 Yakalanmadı (söz verilen) Hata: Temel alınan bağlantı kapatıldığı için çağrı iptal edildi.

Azure SignalR Hizmetini sağlama

Visual Studio'da bir uygulama için Azure SignalR Hizmeti sağlamak için:

1. Uygulama için Visual Studio'da bir Azure Uygulaması yayımlama profili oluşturun.
2. Azure SignalR Hizmeti bağımlılığını profile ekleyin. Azure aboneliğinde uygulamaya atanacak önceden var olan bir Azure SignalR Hizmeti örneği yoksa, yeni bir hizmet örneği sağlamak için Yeni bir Azure SignalR Hizmeti örneği oluştur'u seçin.
3. Uygulamayı Azure’da yayımlama.

Visual Studio'da Azure SignalR Hizmeti'nin sağlanması, yapışkan oturumları otomatik olarak etkinleştirir ve bağlantı dizesi uygulama hizmetinin yapılandırmasına ekler SignalR .

Azure Container Apps'te ölçeklenebilirlik

Azure Container Apps'te sunucu tarafı Blazor uygulamaları ölçeklendirmek, Azure SignalR Hizmeti'ni kullanmaya ek olarak belirli konuları da gerektirir. İstek yönlendirmenin işlenme şekli nedeniyle, ASP.NET Core veri koruma hizmeti anahtarları tüm kapsayıcı örneklerinin erişebileceği merkezi bir konumda kalıcı hale getirmek için yapılandırılmalıdır. Anahtarlar Azure Blob Depolama depolanabilir ve Azure Key Vault ile korunabilir. Veri koruma hizmeti, bileşenleri seri durumdan Razor çıkarmak için anahtarları kullanır.

Not

Bu senaryo hakkında daha ayrıntılı bilgi edinmek ve kapsayıcı uygulamalarını ölçeklendirmek için bkz . Azure'da ASP.NET Core Uygulamalarını Ölçeklendirme. Öğreticide, Azure Container Apps'te uygulamaları barındırmak için gereken hizmetleri oluşturma ve tümleştirme açıklanmaktadır. Bu bölümde temel adımlar da sağlanmıştır.

1. Veri koruma hizmetini Azure Blob Depolama ve Azure Key Vault kullanacak şekilde yapılandırmak için aşağıdaki NuGet paketlerine başvurun:

   • Azure.Identity: Azure kimlik ve erişim yönetimi hizmetleriyle çalışmak için sınıflar sağlar.
   • Microsoft.Extensions.Azure: Temel Azure yapılandırmalarını gerçekleştirmek için yararlı uzantı yöntemleri sağlar.
   • Azure.Extensions.AspNetCore.DataProtection.Blobs: ASP.NET Core Data Protection anahtarlarının Azure Blob Depolama'de depolanmasına izin verir, böylece anahtarlar bir web uygulamasının çeşitli örnekleri arasında paylaşılabilir.
   • Azure.Extensions.AspNetCore.DataProtection.Keys: Azure Key Vault Anahtar Şifreleme/Sarmalama özelliğini kullanarak bekleyen anahtarların korunmasını sağlar.

   Not

   .NET uygulamalarına paket ekleme hakkında yönergeler için, Paket tüketimi iş akışında (NuGet belgeleri)paketleri yüklemek ve yönetmek altındaki makalelere bakın. NuGet.org'da doğru paket sürümlerini onaylayın.

2. Aşağıdaki vurgulanmış kodla güncelleştirin Program.cs :

   using Azure.Identity;
   using Microsoft.AspNetCore.DataProtection;
   using Microsoft.Extensions.Azure;
   
   var builder = WebApplication.CreateBuilder(args);
   var BlobStorageUri = builder.Configuration["AzureURIs:BlobStorage"];
   var KeyVaultURI = builder.Configuration["AzureURIs:KeyVault"];
   
   builder.Services.AddRazorPages();
   builder.Services.AddHttpClient();
   builder.Services.AddServerSideBlazor();
   
   builder.Services.AddAzureClientsCore();
   
   builder.Services.AddDataProtection()
                   .PersistKeysToAzureBlobStorage(new Uri(BlobStorageUri),
                                                   new DefaultAzureCredential())
                   .ProtectKeysWithAzureKeyVault(new Uri(KeyVaultURI),
                                                   new DefaultAzureCredential());
   var app = builder.Build();
   
   if (!app.Environment.IsDevelopment())
   {
       app.UseExceptionHandler("/Error");
       app.UseHsts();
   }
   
   app.UseHttpsRedirection();
   app.UseStaticFiles();
   
   app.UseRouting();
   
   app.UseAuthorization();
   
   app.MapRazorPages();
   
   app.Run();
   

   Önceki değişiklikler, uygulamanın merkezi, ölçeklenebilir bir mimari kullanarak veri korumasını yönetmesine olanak sağlar. DefaultAzureCredential kod Azure'a dağıtıldıktan sonra kapsayıcı uygulaması yönetilen kimliğini bulur ve blob depolamaya ve uygulamanın anahtar kasasına bağlanmak için bunu kullanır.

3. Kapsayıcı uygulaması yönetilen kimliğini oluşturmak ve blob depolamaya ve anahtar kasasına erişim vermek için aşağıdaki adımları tamamlayın:

   1. Azure Portal'da kapsayıcı uygulamasının genel bakış sayfasına gidin.
   2. Sol gezinti bölmesinden Hizmet Bağlan veya seçeneğini belirleyin.
   3. Üst gezinti bölmesinden + Oluştur'u seçin.
   4. Bağlantı oluştur açılır menüsünde aşağıdaki değerleri girin:
      • Kapsayıcı: Uygulamanızı barındırmak için oluşturduğunuz kapsayıcı uygulamasını seçin.
      • Hizmet türü: Blob Depolama'ı seçin.
      • Abonelik: Kapsayıcı uygulamasının sahibi olan aboneliği seçin.
      • Bağlan ion adı: adını scalablerazorstoragegirin.
      • İstemci türü: .NET'i ve ardından İleri'yi seçin.
   5. Sistem tarafından atanan yönetilen kimlik'i ve ardından İleri'yi seçin.
   6. Varsayılan ağ ayarlarını kullanın ve İleri'yi seçin.
   7. Azure ayarları doğruladıktan sonra Oluştur'u seçin.

   Anahtar kasası için önceki ayarları yineleyin. Temel Bilgiler sekmesinde uygun anahtar kasası hizmetini ve anahtarını seçin.

Azure SignalR olmadan Azure Uygulaması Hizmeti Hizmet

Azure Uygulaması Hizmetinde etkileşimli sunucu tarafı işleme kullanan bir Blazor Web Uygulaması barındırmak, Uygulama İsteği Yönlendirme (ARR) benzimi ve WebSockets için yapılandırma gerektirir. Kullanıcı arabirimi gecikme süresini azaltmak için App Service de uygun şekilde genel olarak dağıtılmalıdır. Azure Uygulaması Hizmeti'ni barındırırken Azure SignalR Hizmeti'ni kullanmak gerekli değildir.

Uygulamayı yapılandırmak için aşağıdaki kılavuzu kullanın:

• uygulamayı Azure Uygulaması Hizmeti'nde yapılandırın.
• App Service Planı Sınırları.

IIS

IIS kullanırken şunları etkinleştirin:

• IIS üzerinde WebSockets.
• Uygulama İsteği Yönlendirme ile yapışkan oturumlar.

Daha fazla bilgi için bkz. Iis'de ASP.NET Core uygulaması yayımlama konusunda yönergeler ve dış IIS kaynak çapraz bağlantıları.

Kubernetes

Yapışkan oturumlar için aşağıdaki Kubernetes ek açıklamalarıyla giriş tanımı oluşturun:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: <ingress-name>
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "affinity"
    nginx.ingress.kubernetes.io/session-cookie-expires: "14400"
    nginx.ingress.kubernetes.io/session-cookie-max-age: "14400"

Nginx ile Linux

Aşağıdaki değişikliklerle ASP.NET Core SignalR uygulamasının yönergelerini izleyin:

• location Yolu /hubroute (location /hubroute { ... }) olan kök yoluna / (location / { ... }) değiştirin.
• Ayar yalnızca uygulama istemci-sunucu etkileşimleriyle ilgili Blazor olmayan Sunucu Tarafından Gönderilen Olaylar (SSE) için geçerli olduğundan ara sunucu arabelleğe almaproxy_buffering off; () yapılandırmasını kaldırın.

Daha fazla bilgi ve yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• ASP.NET Core SignalR üretim barındırma ve ölçeklendirme
• Nginx ile Linux üzerinde ASP.NET Core Barındırma
• ASP.NET Core'u ara sunucular ve yük dengeleyicilerle çalışacak şekilde yapılandırma
• WebSocket Proxy'si olarak NGINX
• WebSocket proxy'si oluşturma
• Microsoft dışı destek forumlarında geliştiricilere danışın:
  • Stack Overflow (etiket: blazor)
  • ASP.NET Core Slack Ekibi
  • Blazor Gitter

Apache ile Linux

Linux üzerinde Apache'nin arkasında bir Blazor uygulama barındırmak için HTTP ve WebSockets trafiği için yapılandırın ProxyPass .

Aşağıdaki örnekte:

• Kestrel sunucusu konak makinede çalışıyor.
• Uygulama, 5000 numaralı bağlantı noktasındaki trafiği dinler.

ProxyPreserveHost   On
ProxyPassMatch      ^/_blazor/(.*) http://localhost:5000/_blazor/$1
ProxyPass           /_blazor ws://localhost:5000/_blazor
ProxyPass           / http://localhost:5000/
ProxyPassReverse    / http://localhost:5000/

Aşağıdaki modülleri etkinleştirin:

a2enmod   proxy
a2enmod   proxy_wstunnel

WebSockets hataları için tarayıcı konsolunu denetleyin. Örnek hatalar:

• Firefox şu konumdan sunucuyla bağlantı kuramıyor: ws://the-domain-name.tld/_blazor?id=XXX
• Hata: 'WebSockets' aktarımı başlatılamadı: Hata: Aktarımda bir hata oluştu.
• Hata: 'LongPolling' aktarımı başlatılamadı: TypeError: this.transport undefined
• Hata: Kullanılabilir aktarımlardan herhangi biriyle sunucuya bağlanılamıyor. WebSockets başarısız oldu
• Hata: Bağlantı 'Bağlan Ed' Durumunda değilse veri gönderilemez.

Daha fazla bilgi ve yapılandırma kılavuzu için aşağıdaki kaynaklara bakın:

• Apache ile Linux üzerinde ASP.NET Core Barındırma
• ASP.NET Core'u ara sunucular ve yük dengeleyicilerle çalışacak şekilde yapılandırma
• Apache belgeleri
• Microsoft dışı destek forumlarında geliştiricilere danışın:
  • Stack Overflow (etiket: blazor)
  • ASP.NET Core Slack Ekibi
  • Blazor Gitter

Ağ gecikme süresini ölçme

JS birlikte çalışma , aşağıdaki örnekte gösterildiği gibi ağ gecikme süresini ölçmek için kullanılabilir.

MeasureLatency.razor:

@inject IJSRuntime JS

<h2>Measure Latency</h2>

@if (latency is null)
{
    <span>Calculating...</span>
}
else
{
    <span>@(latency.Value.TotalMilliseconds)ms</span>
}

@code {
    private DateTime startTime;
    private TimeSpan? latency;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            startTime = DateTime.UtcNow;
            var _ = await JS.InvokeAsync<string>("toString");
            latency = DateTime.UtcNow - startTime;
            StateHasChanged();
        }
    }
}

Makul bir kullanıcı arabirimi deneyimi için 250 ms veya daha kısa süreli bir kullanıcı arabirimi gecikme süresi öneririz.

Bellek yönetimi

Sunucuda, her kullanıcı oturumu için yeni bir bağlantı hattı oluşturulur. Her kullanıcı oturumu, tarayıcıda tek bir belgenin işlenmesine karşılık gelir. Örneğin, birden çok sekme birden çok oturum oluşturur.

Blazor, oturumu başlatan bağlantı hattı olarak adlandırılan tarayıcıya sabit bir bağlantı tutar. Bağlan, kullanıcının ağ bağlantısını kaybetmesi veya aniden tarayıcıyı kapatması gibi çeşitli nedenlerden herhangi biri nedeniyle herhangi bir zamanda kaybolabilir. Bağlantı kesildiğinde, Blazor "bağlantısı kesilmiş" bir havuza sınırlı sayıda bağlantı hattı yerleştiren ve istemcilere oturumu yeniden bağlamak ve yeniden kurmak için sınırlı süre veren bir kurtarma mekanizması vardır (varsayılan: 3 dakika).

Bu süreden sonra devreyi Blazor serbest bırakır ve oturumu atar. Bu noktadan sonra bağlantı hattı çöp toplama (GC) için uygundur ve devrenin GC nesli için bir toplama tetiklendiğinde talep edilir. Anlaşılması gereken önemli bir yön, devrelerin uzun bir ömrü olmasıdır, yani bağlantı hattı tarafından köklenen nesnelerin çoğu sonunda 2. Nesil'e ulaşır. Sonuç olarak, 2. Nesil koleksiyonu gerçekleşene kadar bu nesnelerin yayınlanmasını göremeyebilirsiniz.

Genel olarak bellek kullanımını ölçme

Ön koşullar:

• Uygulamanın Yayın yapılandırmasında yayımlanması gerekir. Oluşturulan kod üretim dağıtımı için kullanılan kodu temsil etmediğinden hata ayıklama yapılandırma ölçümleri ilgili değildir.
• Uygulamanın davranışını da etkileyebileceği ve sonuçları bozabileceği için uygulamanın bir hata ayıklayıcısı eklenmeden çalışması gerekir. Visual Studio'da, menü çubuğundan Hata Ayıklama>Olmadan Başlat'ı veya klavyeyi kullanarak Ctrl+F5'i seçerek uygulamayı hata ayıklamadan başlatın.
• .NET tarafından gerçekte ne kadar bellek kullanıldığını anlamak için farklı bellek türlerini göz önünde bulundurun. Geliştiriciler genellikle kullanımdaki gerçek belleğin üst sınırı olan Windows işletim sistemindeki Görev Yöneticisi'nde uygulama belleği kullanımını inceler. Daha fazla bilgi için aşağıdaki makalelere bakın:
  • .NET Bellek Performansı Analizi: Özellikle, BellekLe İlgili Temel Bilgiler bölümüne bakın.
  • Bellek performansı sorunlarını tanılama (üç bölümlü seri) iş akışı: Serinin üç makalesinin bağlantıları, serideki her makalenin en üstünde yer alır.

Uygulanan bellek kullanımı Blazor

Blazor tarafından kullanılan belleği aşağıdaki gibi hesaplıyoruz:

(Etkin Devreler × Bağlantı Hattı Başına Bellek) + (Bağlantı Kesilen Devreler × Devre Başına Bellek)

Bir bağlantı hattının kullandığı bellek miktarı ve bir uygulamanın koruyabileceği maksimum etkin bağlantı hattı büyük ölçüde uygulamanın nasıl yazıldığını bağlıdır. Olası aktif devrelerin maksimum sayısı kabaca şu şekilde açıklanmıştır:

Maksimum Kullanılabilir Bağlantı / Hattı Başına Bellek Maksimum = Olası Etkin Devre sayısı

içinde bellek sızıntısı olması Blazoriçin aşağıdakilerin doğru olması gerekir:

• Bellek uygulama tarafından değil çerçeve tarafından ayrılmalıdır. Uygulamada 1 GB'lık bir dizi ayırırsanız, uygulamanın dizinin atılması işlemini yönetmesi gerekir.
• Bellek etkin olarak kullanılmamalıdır; başka bir deyişle devre etkin değildir ve bağlantısı kesilmiş devreler önbelleğinden çıkarılmıştır. En fazla etkin devre çalışıyorsa, belleğin bitmesi bellek sızıntısı değil ölçek sorunudur.
• Bağlantı hattının GC oluşturma işlemi için bir çöp toplama (GC) çalıştırıldı, ancak çerçevedeki başka bir nesne bağlantı hattına güçlü bir başvuru içerdiğinden çöp toplayıcı devreyi talep etmedi.

Diğer durumlarda bellek sızıntısı olmaz. Devre etkinse (bağlı veya bağlantısı kesilmişse), devre hala kullanımdadır.

Bağlantı hattının GC oluşturması için bir koleksiyon çalışmazsa, atık toplayıcının o anda belleği boşaltması gerekmeyen bellek serbest bırakılmaz.

GC oluşturma için bir koleksiyon çalıştırılırsa ve bağlantı hattını serbest bırakırsa, .NET sanal belleği etkin tutmaya karar verebileceği için belleği işleme değil GC istatistiklerine göre doğrulamanız gerekir.

Bellek serbest değilse, etkin olmayan veya bağlantısı kesilmeyen ve kökünü çerçevedeki başka bir nesnenin oluşturduğu bir bağlantı hattı bulmanız gerekir. Başka bir durumda, bellek yetersizliği geliştirici kodunda bir uygulama sorunudur.

Bellek kullanımını azaltma

Bir uygulamanın bellek kullanımını azaltmak için aşağıdaki stratejilerden herhangi birini benimseyin:

• .NET işlemi tarafından kullanılan toplam bellek miktarını sınırlayın. Daha fazla bilgi için bkz . Atık toplama için çalışma zamanı yapılandırma seçenekleri.
• Bağlantısı kesilmiş devre sayısını azaltın.
• Bağlantı hattının bağlantısı kesilmiş durumda olmasına izin verilen süreyi azaltın.
• Kapalı kalma sürelerinde toplama gerçekleştirmek için çöp toplamayı el ile tetikleyin.
• Çöp toplamayı Sunucu modu yerine çöp toplamayı agresif bir şekilde tetikleyen İş İstasyonu modunda yapılandırın.

Bazı mobil cihaz tarayıcıları için yığın boyutu

İstemcide çalışan ve mobil cihaz tarayıcılarını, özellikle iOS'ta Safari'yi hedefleyen bir Blazor uygulama oluştururken, MSBuild özelliğine EmccMaximumHeapSize sahip uygulama için en yüksek belleği azaltmak gerekebilir. Daha fazla bilgi için bkz . ASP.NET Core'u Blazor WebAssemblybarındırma ve dağıtma.

Ek eylemler ve dikkat edilmesi gerekenler

• Bellek talepleri yüksek olduğunda işlemin bellek dökümünü yakalayın ve nesnelerin en çok belleği aldığını ve bu nesnelerin nerede köke sahip olduğunu (bunlara başvuruyu barındıran nesneler) belirleyin.
• kullanarak uygulamanızdaki belleğin nasıl davrandığını dotnet-countersgösteren istatistikleri inceleyebilirsiniz. Daha fazla bilgi için bkz. Performans sayaçlarını araştırma (dotnet-counters).
• Gc tetiklendiğinde bile yakın gelecekte belleği yeniden kullanacağı için .NET belleği işletim sistemine hemen döndürmek yerine bellekte tutar. Bu, belleğin sürekli olarak işlenmesini ve ayrıştırılmasını önler ve bu da pahalıdır. GC'lerin gerçekleştiğini ve kullanılan bellek miktarının 0'a (sıfır) indiğini ancak .NET'in yeniden kullanmak için bellekte tuttuğunun işareti olan çalışma kümesi sayacının azaldığını görmediğiniz için bunu kullanırsanız dotnet-counters bu yansıtılır. Bu davranışı denetlemeye yönelik proje dosyası (.csproj) ayarları hakkında daha fazla bilgi için bkz . Atık toplama için çalışma zamanı yapılandırma seçenekleri.
• Sunucu GC, uygulamanızı dondurmaktan kaçınmak için bunun kesinlikle gerekli olduğunu belirleyene kadar çöp toplamaları tetiklemez ve uygulamanızın makinede çalışan tek şey olduğunu göz önünde bulundurarak sistemdeki tüm belleği kullanabilmesini sağlar. Sistemde 50 GB varsa, atık toplayıcı 2. Nesil koleksiyonunu tetiklemeden önce 50 GB kullanılabilir belleğin tamamını kullanmayı arar.
• Bağlantısı kesilmiş devre saklama yapılandırması hakkında bilgi için bkz . ASP.NET Çekirdek BlazorSignalR kılavuzu.

Belleği ölçme

• Uygulamayı Yayın yapılandırması'nda yayımlayın.
• Uygulamanın yayımlanmış bir sürümünü çalıştırın.
• Çalışan uygulamaya hata ayıklayıcı eklemeyin.
• 2. Nesil zorlamalı, sıkıştırmalı koleksiyonu tetikleme (GC.Collect(2, GCCollectionMode.Aggressive | GCCollectionMode.Forced, blocking: true, compacting: true)) bellek boşaltılıyor mu?
• Uygulamanızın nesneleri büyük nesne yığınına ayırdığını düşünün.
• Uygulama istekler ve işleme ile ısındıktan sonra bellek artışını test ediyor musunuz? Genellikle, kod ilk kez yürütülürken uygulamanın ayak izine sabit miktarda bellek ekleyen önbellekler vardır.