Hostování a nasazení aplikací na straně Blazor serveru

Tento článek vysvětluje, jak hostovat a nasazovat aplikace na straně Blazor serveru (Blazor Web Apps a Blazor Server aplikace) pomocí ASP.NET Core.

Hodnoty konfigurace hostitele

Aplikace na straně Blazor serveru můžou přijímat hodnoty konfigurace obecného hostitele.

Nasazení

Použití modelu Blazor hostování na straně serveru se provádí na serveru z aplikace ASP.NET Core. Aktualizace uživatelského rozhraní, zpracování událostí a volání JavaScriptu SignalR se zpracovávají přes připojení.

Vyžaduje se webový server, který může hostovat aplikaci ASP.NET Core. Visual Studio obsahuje šablonu projektu aplikace na straně serveru. Další informace o Blazor šablonách projektů najdete v tématu ASP.NET Blazor Základní struktura projektu.

Publikujte aplikaci v konfiguraci vydané verze a nasaďte obsah bin/Release/{TARGET FRAMEWORK}/publish složky, kde {TARGET FRAMEWORK} zástupný symbol představuje cílovou architekturu.

Škálovatelnost

Při zvažování škálovatelnosti jednoho serveru (vertikální navýšení kapacity) je paměť dostupná pro aplikaci pravděpodobně prvním prostředkem, který aplikace vyčerpá, protože se zvýší požadavky uživatelů. Dostupná paměť na serveru má vliv na:

• Počet aktivních okruhů, které může server podporovat.
• Latence uživatelského rozhraní v klientovi

Pokyny k vytváření zabezpečených a škálovatelných aplikací na straně Blazor serveru najdete v následujících zdrojích informací:

• Pokyny ke zmírnění hrozeb pro vykreslování na straně statického serveru ASP.NET Core Blazor
• Pokyny ke zmírnění hrozeb pro interaktivní vykreslování na straně serveru ASP.NET Core Blazor

Každý okruh používá přibližně 250 kB paměti pro minimální aplikaci ve stylu Hello World. Velikost okruhu závisí na kódu aplikace a požadavcích na údržbu stavu spojených s jednotlivými komponentami. Doporučujeme měřit požadavky na prostředky během vývoje vaší aplikace a infrastruktury, ale následující směrný plán může být výchozím bodem při plánování cíle nasazení: Pokud očekáváte, že vaše aplikace bude podporovat 5 000 souběžných uživatelů, zvažte rozpočtování alespoň 1,3 GB paměti serveru do aplikace (nebo přibližně 273 kB na uživatele).

Konfigurace SignalR

SignalRPodmínky hostování a škálování se vztahují na Blazor aplikace, které používají SignalR.

Další informace o SignalRBlazor aplikacích, včetně pokynů ke konfiguraci, najdete v ASP.NET základních BlazorSignalR doprovodných materiálech.

Přenosy

Blazor funguje nejlépe při použití protokolu WebSocket jako SignalR přenosu kvůli nižší latenci, lepší spolehlivosti a lepšímu zabezpečení. Dlouhé dotazování se používá SignalR , když webSockets není k dispozici nebo když je aplikace explicitně nakonfigurovaná tak, aby používala dlouhé dotazování. Při nasazování do služby Aplikace Azure Nakonfigurujte aplikaci tak, aby používala webSockety v nastavení webu Azure Portal pro službu. Podrobnosti o konfiguraci aplikace pro službu Aplikace Azure Najdete v pokynech pro SignalRpublikování.

Pokud se používá dlouhé dotazování, zobrazí se upozornění konzoly:

Připojení přes WebSocket se nezdařilo pomocí náhradního přenosu Long Polling. Příčinou může být blokování připojení vpn nebo proxy serverem.

Globální nasazení a selhání připojení

Doporučení pro globální nasazení do geografických datových center:

• Nasaďte aplikaci do oblastí, ve kterých se nachází většina uživatelů.
• Vezměte v úvahu zvýšenou latenci provozu napříč kontinenty. Pokud chcete řídit vzhled uživatelského rozhraní pro opětovné připojení, přečtěte si pokyny pro ASP.NET CoreBlazorSignalR.
• Pro hostování Azure použijte službu AzureSignalR.

Služba Azure SignalR

Pro Blazor Web Apps, které přijímají interaktivní vykreslování na straně serveru, zvažte použití služby AzureSignalR. Služba funguje ve spojení s centrem aplikace Blazor pro vertikální navýšení kapacity na velký počet souběžných SignalR připojení. Globální dosah služby a vysoce výkonná datová centra navíc výrazně pomáhají snížit latenci kvůli zeměpisné poloze. Pokud už vaše hostitelské prostředí tyto obavy řeší, použití služby Azure SignalR není nutné.

Poznámka:

Stavové opětovné připojení (WithStatefulReconnect) bylo vydáno s .NET 8, ale v současné době se nepodporuje pro službu Azure SignalR . Další informace najdete v tématu Podpora stavových opětovného připojení? (Azure/azure-signalr č. 1878).

Důležité

Pokud jsou protokoly WebSocket zakázané, služba Aplikace Azure simuluje připojení v reálném čase pomocí dlouhého dotazování HTTP. Dlouhé dotazování HTTP je výrazně pomalejší než spouštění s povolenými protokoly WebSocket, které nepoužívá dotazování k simulaci připojení klienta-serveru. V případě, že je potřeba použít dlouhé dotazování, možná budete muset nakonfigurovat maximální interval dotazování (MaxPollIntervalInSeconds), který definuje maximální povolený interval dotazování pro připojení typu Long Polling ve službě AzureSignalR, pokud se služba někdy vrátí z webSocketu do dlouhého dotazování. Pokud v rámci dalšího požadavku na hlasování nepřijde MaxPollIntervalInSeconds, služba Azure SignalR vyčistí připojení klienta. Všimněte si, že služba Azure SignalR také vyčistí připojení při čekání na velikost vyrovnávací paměti pro zápis do mezipaměti větší než 1 MB, aby se zajistil výkon služby. Výchozí hodnota je MaxPollIntervalInSeconds 5 sekund. Nastavení je omezeno na 1 až 300 sekund.

Doporučujeme používat webSockety pro aplikace na straně Blazor serveru nasazené do služby Aplikace Azure Service. Služba Azure SignalR ve výchozím nastavení používá protokoly WebSocket. Pokud aplikace nepoužívá službu AzureSignalR, přečtěte si téma Publikování aplikace ASP.NET Core SignalR do služby Aplikace Azure Service.

Další informace naleznete v tématu:

• Co je služba Azure SignalR ?
• Průvodce výkonem pro službu Azure SignalR
• Publikování aplikace ASP.NET Core SignalR do služby Aplikace Azure Service

Konfigurace

Aby bylo možné nakonfigurovat aplikaci pro službu Azure SignalR , musí aplikace podporovat rychlé relace, kdy se klienti při předkonenderování přesměrují zpět na stejný server. Možnost ServerStickyMode nebo hodnota konfigurace je nastavena na Requiredhodnotu . Aplikace obvykle vytvoří konfiguraci pomocí jednoho z následujících přístupů:

• Program.cs:

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

• Konfigurace (použijte jeden z následujících přístupů):

  • V appsettings.json:

    "Azure:SignalR:ServerStickyMode": "Required"
    

  • Nastavení konfigurační>aplikace služby App Service na webu Azure Portal (název: Azure__SignalR__ServerStickyMode, hodnota: ). Required Tento přístup se pro aplikaci automaticky přijme, pokud zřídíte službu AzureSignalR.

Poznámka:

Následující chyba je vyvolán aplikací, která nepovolila rychlé relace pro službu Azure SignalR :

blazor.server.js:1 Nezachycené (v příslibu) Chyba: Vyvolání se zrušilo kvůli zavření základního připojení.

Zřízení služby Azure SignalR

Zřízení služby Azure SignalR pro aplikaci v sadě Visual Studio:

1. Vytvořte profil publikování Aplikace Azure v sadě Visual Studio pro aplikaci.
2. Přidejte do profilu závislost služby AzureSignalR. Pokud předplatné Azure nemá existující instanci služby Azure SignalR , která se má přiřadit k aplikaci, vyberte Vytvořit novou instanci služby Azure SignalR , abyste zřídili novou instanci služby.
3. Publikovat aplikaci do Azure

Zřizování služby Azure SignalR v sadě Visual Studio automaticky povolí rychlé relace a přidá SignalR připojovací řetězec do konfigurace služby App Service.

Škálovatelnost v Azure Container Apps

Škálování aplikací na straně Blazor serveru v Azure Container Apps vyžaduje kromě používání služby Azure SignalR také specifické aspekty. Vzhledem ke způsobu zpracování směrování požadavků musí být služba ochrany dat ASP.NET Core nakonfigurovaná tak, aby uchovávala klíče v centralizovaném umístění, ke kterému mají přístup všechny instance kontejneru. Klíče je možné ukládat ve službě Azure Blob Storage a chránit je pomocí služby Azure Key Vault. Služba ochrany dat používá klíče k deserializaci Razor komponent.

Poznámka:

Podrobnější zkoumání tohoto scénáře a škálování kontejnerových aplikací najdete v tématu Škálování ASP.NET Core Apps v Azure. Tento kurz vysvětluje, jak vytvořit a integrovat služby potřebné k hostování aplikací v Azure Container Apps. V této části jsou uvedeny také základní kroky.

1. Pokud chcete nakonfigurovat službu ochrany dat tak, aby používala službu Azure Blob Storage a Azure Key Vault, projděte si následující balíčky NuGet:

   • Azure.Identity: Poskytuje třídy pro práci se službami správy identit Azure a přístupu.
   • Microsoft.Extensions.Azure: Poskytuje užitečné rozšiřující metody pro provádění základních konfigurací Azure.
   • Azure.Extensions.AspNetCore.DataProtection.Blobs: Umožňuje ukládání ASP.NET základních klíčů ochrany dat ve službě Azure Blob Storage, aby se klíče mohly sdílet napříč několika instancemi webové aplikace.
   • Azure.Extensions.AspNetCore.DataProtection.Keys: Umožňuje ochranu neaktivních uložených klíčů pomocí funkce Šifrování a zabalení klíčů služby Azure Key Vault.

   Poznámka:

   Pokyny k přidávání balíčků do aplikací .NET najdete v článcích v části Instalace a správa balíčků na webu Pracovní postup používání balíčků (dokumentace k NuGetu). Ověřte správné verze balíčků na NuGet.org.

2. Aktualizujte Program.cs následujícím zvýrazněným kódem:

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

   Předchozí změny umožňují aplikaci spravovat ochranu dat pomocí centralizované škálovatelné architektury. DefaultAzureCredential zjistí spravovanou identitu aplikace kontejneru po nasazení kódu do Azure a použije ji k připojení k úložišti objektů blob a trezoru klíčů aplikace.

3. Pokud chcete vytvořit spravovanou identitu aplikace kontejneru a udělit jí přístup k úložišti objektů blob a trezoru klíčů, proveďte následující kroky:

   1. Na webu Azure Portal přejděte na stránku přehledu aplikace kontejneru.
   2. V levém navigačním panelu vyberte service Připojení or.
   3. V horním navigačním panelu vyberte + Vytvořit .
   4. V rozevírací nabídce Vytvořit připojení zadejte následující hodnoty:
      • Kontejner: Vyberte aplikaci kontejneru, kterou jste vytvořili pro hostování aplikace.
      • Typ služby: Vyberte úložiště objektů blob.
      • Předplatné: Vyberte předplatné, které vlastní aplikaci kontejneru.
      • Připojení ion name: Zadejte název .scalablerazorstorage
      • Typ klienta: Vyberte .NET a pak vyberte Další.
   5. Vyberte spravovanou identitu přiřazenou systémem a vyberte Další.
   6. Použijte výchozí nastavení sítě a vyberte Další.
   7. Jakmile Azure ověří nastavení, vyberte Vytvořit.

   Opakujte předchozí nastavení trezoru klíčů. Na kartě Základy vyberte příslušnou službu trezoru klíčů a klíč.

služba Aplikace Azure bez Azure SignalR Služby

Blazor Hostování webové aplikace, která používá interaktivní vykreslování na straně serveru ve službě Aplikace Azure Service, vyžaduje konfiguraci pro spřažení směrování požadavků aplikací (ARR) a webSocket. Služba App Service by měla být také správně globálně distribuovaná, aby se snížila latence uživatelského rozhraní. Použití služby Azure SignalR při hostování ve službě Aplikace Azure Není vyžadováno.

Ke konfiguraci aplikace použijte následující doprovodné materiály:

• Nakonfigurujte aplikaci ve službě Aplikace Azure Service.
• Limity plánu služby App Service

IIS

Při použití služby IIS povolte:

• WebSockety ve službě IIS
• Rychlé relace se směrováním žádostí o aplikaci

Další informace najdete v doprovodných materiálech a externích odkazech prostředků IIS v tématu Publikování aplikace ASP.NET Core do služby IIS.

Kubernetes

Vytvořte definici příchozího přenosu dat s následujícími poznámkami Kubernetes pro rychlé relace:

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"

Linux na serveru Nginx

Postupujte podle pokynů pro aplikaci ASP.NET Core SignalR s následujícími změnami:

• location Změňte cestu z /hubroute (location /hubroute { ... }) na kořenovou cestu / (location / { ... }).
• Odeberte konfiguraci pro ukládání do vyrovnávací paměti proxy serveru (proxy_buffering off;), protože nastavení platí jenom pro události odeslané serverem (SSE), které nejsou relevantní pro Blazor interakce klienta aplikace.

Další informace a pokyny ke konfiguraci najdete v následujících zdrojích informací:

• hostování a škálování v produkčním prostředí ASP.NET Core SignalR
• Hostování ASP.NET Core v Linuxu s Nginx
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• NGINX jako proxy serveru WebSocket
• Proxy serveru WebSocket
• Obraťte se na vývojáře na fórech podpory jiných společností než Microsoft:
  • Stack Overflow (značka: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

Linux na serveru Apache

Pokud chcete hostovat aplikaci za Apache v Linuxu Blazor , nakonfigurujte ProxyPass provoz HTTP a WebSockets.

V následujícím příkladu:

• Kestrel server běží na hostitelském počítači.
• Aplikace naslouchá provozu na portu 5000.

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

Povolte následující moduly:

a2enmod   proxy
a2enmod   proxy_wstunnel

Zkontrolujte chyby webSocket v konzole prohlížeče. Ukázkové chyby:

• Firefox nemůže navázat připojení k serveru na adrese ws://the-domain-name.tld/_blazor?id=XXX
• Chyba: Přenos WebSockets se nepovedlo spustit: Chyba: Při přenosu došlo k chybě.
• Chyba: Spuštění přenosu LongPolling: TypeError: this.transport není definován
• Chyba: Nelze se připojit k serveru s žádným z dostupných přenosů. WebSockety selhaly
• Chyba: Nelze odeslat data, pokud připojení není ve stavu Připojení.

Další informace a pokyny ke konfiguraci najdete v následujících zdrojích informací:

• Hostování ASP.NET Core v Linuxu s Apache
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
• Dokumentace k Apache
• Obraťte se na vývojáře na fórech podpory jiných společností než Microsoft:
  • Stack Overflow (značka: blazor)
  • ASP.NET Core Slack Team
  • Blazor Gitter

Měření latence sítě

JS K měření latence sítě je možné použít interoperabilitu, jak ukazuje následující příklad.

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

Pro přiměřené uživatelské rozhraní doporučujeme trvalou latenci uživatelského rozhraní 250 ms nebo méně.

Správa paměti

Na serveru se vytvoří nový okruh pro každou uživatelskou relaci. Každá uživatelská relace odpovídá vykreslení jednoho dokumentu v prohlížeči. Například více karet vytváří více relací.

Blazor udržuje konstantní připojení k prohlížeči, kterému se říká okruh, který relaci inicioval. Připojení iony mohou být ztraceny kdykoli z některého z několika důvodů, například když uživatel ztratí síťové připojení nebo náhle zavře prohlížeč. Když dojde ke ztrátě připojení, má mechanismus obnovení, Blazor který umístí omezený počet okruhů do "odpojeného" fondu, což klientům poskytuje omezenou dobu pro opětovné připojení a opětovné navázání relace (výchozí hodnota: 3 minuty).

Blazor Potom okruh uvolní a relaci zahodí. Od tohoto okamžiku je okruh způsobilý pro uvolňování paměti (GC) a je nárokován při aktivaci kolekce pro generování uvolňování paměti okruhu. Jedním z důležitých aspektů, které je potřeba pochopit, je, že okruhy mají dlouhou životnost, což znamená, že většina objektů kořenových okruhem nakonec dosáhne Gen 2. V důsledku toho se tyto objekty nemusí zobrazit, dokud nedojde k kolekci Gen2.

Obecné měření využití paměti

Požadavky:

• Aplikace musí být publikovaná v konfiguraci vydané verze . Měření konfigurace ladění nejsou relevantní, protože vygenerovaný kód neodpovídá kódu použitému pro produkční nasazení.
• Aplikace musí běžet bez připojeného ladicího programu, protože to může také ovlivnit chování aplikace a zkazit výsledky. V sadě Visual Studio spusťte aplikaci bez ladění tak>, že v řádku nabídek vyberete možnost Spustit ladění bez ladění nebo pomocí klávesnice Ctrl+F5.
• Zvažte různé typy paměti, abyste pochopili, kolik paměti skutečně používá .NET. Obecně platí, že vývojáři kontrolují využití paměti aplikace ve Správci úloh v operačním systému Windows, což obvykle nabízí horní mez skutečné paměti, která se používá. Další informace najdete v následujících článcích:
  • Analýza výkonu paměti .NET: Konkrétně se podívejte na část Základy paměti.
  • Pracovní postup diagnostiky problémů s výkonem paměti (třídílná série): Odkazy na tři články série jsou v horní části každého článku v řadě.

Využití paměti použité na Blazor

Paměť, kterou používá blazor, vypočítáme následujícím způsobem:

(Aktivní okruhy × paměti pro jednotlivé okruhy) + (odpojené okruhy × paměti na okruh)

Množství paměti, které okruh používá, a maximální potenciální aktivní okruhy, které může aplikace udržovat, je do značné míry závislé na způsobu zápisu aplikace. Maximální počet možných aktivních okruhů je přibližně popsán takto:

Maximální dostupná paměť / pro paměť = na okruh Maximální potenciální aktivní okruhy

Aby došlo Blazork nevrácené paměti, musí být splněny následující podmínky:

• Paměť musí být přidělena architekturou, nikoli aplikací. Pokud v aplikaci přidělíte pole o velikosti 1 GB, musí aplikace spravovat vyřazení pole.
• Paměť nesmí být aktivně používána, což znamená, že okruh není aktivní a byl vyřazen z mezipaměti odpojených okruhů. Pokud máte spuštěné maximální aktivní okruhy, dochází nedostatek paměti, jedná se o problém se škálováním, nevracení paměti.
• Spustila se uvolňování paměti (GC) pro generování uvolňování paměti okruhu, ale systém uvolňování paměti nemůže tento okruh deklarovat, protože jiný objekt v architektuře má silný odkaz na okruh.

V jiných případech nedochází k nevrácení paměti. Pokud je okruh aktivní (připojený nebo odpojený), okruh se stále používá.

Pokud se kolekce pro generování uvolňování paměti okruhu nespustí, paměť se nevyvolá, protože uvolňování paměti v daném okamžiku nemusí uvolnit paměť.

Pokud se kolekce pro generování uvolňování paměti spustí a uvolní okruh, musíte ověřit paměť na statistikách uvolňování paměti, nikoli v procesu, protože .NET se může rozhodnout zachovat virtuální paměť aktivní.

Pokud paměť není uvolněná, musíte najít okruh, který není aktivní nebo odpojený a který je rootovaný jiným objektem v rozhraní. V každém jiném případě je nemožnost uvolnit paměť problémem aplikace v kódu vývojáře.

Snížení využití paměti

Pokud chcete snížit využití paměti aplikace, použijte některou z následujících strategií:

• Omezte celkové množství paměti používané procesem .NET. Další informace naleznete v tématu Možnosti konfigurace modulu runtime pro uvolňování paměti.
• Snižte počet odpojených okruhů.
• Zkraťte dobu, po které může být okruh v odpojeném stavu.
• Ruční spuštění uvolňování paměti pro provedení kolekce během období výpadků.
• Nakonfigurujte uvolňování paměti v režimu pracovní stanice, který agresivně aktivuje uvolňování paměti místo režimu serveru.

Velikost haldy pro některé prohlížeče mobilních zařízení

Při vytváření Blazor aplikace, která běží na klientovi a cílí na prohlížeče mobilních zařízení, zejména Safari v iOSu, může být vyžadováno snížení maximální paměti aplikace s vlastností EmccMaximumHeapSize MSBuild. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor WebAssembly.

Další akce a důležité informace

• Zachyťte výpis paměti procesu, když jsou požadavky na paměť vysoké, a identifikujte objekty, které využívají nejvíce paměti a kde jsou tyto objekty rootovány (co obsahuje odkaz na ně).
• Můžete prozkoumat statistiky o tom, jak se paměť ve vaší aplikaci chová pomocí dotnet-counters. Další informace naleznete v tématu Zkoumání čítačů výkonu (dotnet-counters).
• I když se aktivuje GC, technologie .NET se místo okamžitého vrácení do operačního systému zachytá do paměti, protože je pravděpodobné, že znovu použije paměť v blízké budoucnosti. Tím se zabrání neustálému potvrzení a rušení paměti, což je nákladné. To se projeví, pokud použijete dotnet-counters , protože uvidíte, že k GCS dochází a množství využité paměti klesne na 0 (nula), ale neuvidíte snížení čítače pracovní sady, což je znaménko, že .NET drží paměť, aby ji znovu použila. Další informace o nastavení souboru projektu (.csproj) pro řízení tohoto chování naleznete v tématu Možnosti konfigurace modulu runtime pro uvolňování paměti.
• Uvolňování paměti serveru neaktivuje, dokud nezodpovědí, že je naprosto nezbytné, aby se zabránilo zmrazení vaší aplikace a domnívá se, že aplikace je jediná věc spuštěná na počítači, takže může používat veškerou paměť v systému. Pokud má systém 50 GB, systém se před aktivací kolekce Gen2 pokusí použít plnou 50 GB dostupné paměti.
• Informace o konfiguraci uchovávání odpojených okruhů najdete v pokynech k ASP.NET CoreBlazorSignalR.

Měření paměti

• Publikujte aplikaci v konfiguraci vydané verze.
• Spusťte publikovanou verzi aplikace.
• Nepřipojujte ladicí program ke spuštěné aplikaci.
• Aktivuje se vynucená komprimace kolekce Gen2 (GC.Collect(2, GCCollectionMode.Aggressive | GCCollectionMode.Forced, blocking: true, compacting: true)) uvolní paměť?
• Zvažte, jestli vaše aplikace přiděluje objekty na haldě velkého objektu.
• Testujete růst paměti poté, co se aplikace zahřeje požadavky a zpracování? Obvykle existují mezipaměti, které se naplní při prvním spuštění kódu, které přidají konstantní množství paměti do stopy aplikace.