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

Tento článek vysvětluje, jak hostovat a nasazovat aplikaceBlazor Web AppBlazor Server na straně Blazor serveru 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 SignalR Blazor aplikacích, včetně pokynů ke konfiguraci, najdete v ASP.NET základních BlazorSignalR doprovodných materiálech.

Azure App Service

Hostování ve službě Aplikace Azure Vyžaduje konfiguraci pro webSockets a spřažení relací, označované také jako spřažení směrování požadavků aplikace (ARR).

Pro registraci aplikace ve službě Aplikace Azure Service povolte následující:

• WebSockety umožňující přenos WebSockets do funkce. Výchozí nastavení je Vypnuto.
• Spřažení relace pro směrování požadavků od uživatele zpět do stejné instance služby App Service. Výchozí nastavení je Zapnuto.

1. Na webu Azure Portal přejděte do webové aplikace ve službě App Services.
2. Otevřete konfiguraci nastavení>.
3. Nastavte webové sokety na Zapnuto.
4. Ověřte, že je spřažení relace nastavené na Zapnuto.

Služba Azure SignalR

Volitelná služba Azure SignalR funguje ve spojení s centrem aplikace SignalR pro vertikální navýšení kapacity aplikace na straně serveru na velký počet souběžných 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.

Služba se nevyžaduje pro Blazor aplikace hostované ve službě Aplikace Azure Service nebo Azure Container Apps, ale může být užitečná v jiných hostitelských prostředích:

• Pro usnadnění horizontálního navýšení kapacity připojení.
• Zpracování globální distribuce

V případě, že aplikace používá dlouhé dotazování nebo se vrátí k dlouhému dotazování místo webSocketů, možná budete muset nakonfigurovat maximální interval dotazování (MaxPollIntervalInSecondsvýchozí nastavení: 5 sekund, limit: 1–300 sekund), který definuje maximální povolený interval dotazování pro připojení Long Polling ve službě Azure SignalR . Pokud další požadavek na hlasování nedorazí do maximálního intervalu dotazování, služba zavře připojení klienta.

Pokyny k přidání služby jako závislosti do produkčního nasazení najdete v tématu Publikování aplikace ASP.NET Core SignalR do služby Aplikace Azure Service.

Další informace naleznete v tématu:

• Služba Azure SignalR
• Co je služba Azure SignalR ?
• hostování a škálování v produkčním prostředí ASP.NET Core SignalR
• Publikování aplikace ASP.NET Core SignalR do služby Aplikace Azure Service

IIS

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

• WebSockety ve službě IIS
• Spřažení relací 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 spřažení relací:

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řipojeno.

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

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

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

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

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

@inject IJSRuntime JS

@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í se můžou kdykoliv ztratit 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 blazor používáme, 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.