Optimalizace využití paměti v aplikacích pro prohlížení dokumentů ve velkém měřítku
← Back to Blog7 min read

Optimalizace využití paměti v aplikacích pro prohlížení dokumentů ve velkém měřítku

Optimalizace využití paměti v .NET prohlížečích dokumentů ve velkém měřítku s Doconut
Optimalizace využití paměti v .NET prohlížečích dokumentů ve velkém měřítku s Doconut

Máte tisíce PDF, Office souborů nebo CAD výkresů, které chcete zobrazit v portálu založeném na .NET? A nechcete, aby vám server došel RAM? Trik je zkombinovat lazy streaming, cílené pluginy a optimalizovanou renderovací pipeline od Doconut. V následujících sekcích projdeme problémy s pamětí, které se objevují v podnikovém měřítku, aplikacích s velkým množstvím dokumentů, a ukážeme, jak Doconut — univerzální prohlížeč dokumentů pro .NET backendy — proráží úzká místa, která brání tradičním prohlížečům ve škálování. A mimochodem, čeká na vás zdarma zkušební verze, pokud chcete vidět přínosy ve svém vlastním nastavení.


Porozumění tlaku na paměť v .NET prohlížečích dokumentů

Velké portály s dokumenty často načtou celý soubor do paměti ještě před tím, než se zobrazí první stránka. CAD výkres o velikosti 200 MB nebo PDF s 500 stránkami může rychle zaplavit .NET garbage collector, vyvolat pauzy plného GC a donutit vás přepřidělit servery.

Proč výchozí .NET renderovací model škodí škálovatelnosti

PříznakTypická příčina v naivních implementacích
Výjimky nedostatku pamětiCelé soubory jako pole bajtů uchovávané ve statické cache
Pomale načtení první stránkyDekódování celého dokumentu před renderováním
Nedostatek vláken v thread‑pooluDlouho běžící CPU‑vázané renderování blokuje asynchronní pipeline
Nepravidelné špičky latenceGC sběr velkých přichycovaných objektů

Přidejte pluginy pro anotaci nebo OCR, které hromadí bitmapy obrázků, a tlak se znásobí. Ideální je zpracovávat jen to, co uživatel právě potřebuje, a udržovat všechny mezibufery krátkodobé.

Odpověď Doconut: štíhlé, závislostmi optimalizované jádro

Architektura Doconut založená na .NET 6 byla přestavěna tak, aby snížila alokace na haldě:

  • Optimalizace závislostí – knihovna načítá pouze renderovací moduly potřebné pro aktuální typ souboru (PDF, Office, CAD, obrázek). Nepoužívané pluginy zůstávají mimo paměť, čímž je stopa procesu malá.
  • Design založený na streamu – soubory jsou otevírány jako streamy, nikoli jako celé pole bajtů, takže runtime může načítat data z disku podle potřeby.
  • Podpora background úloh – náročné konverzní úkoly lze přesunout do pracovních procesů nebo Azure Functions, čímž se webová vrstva uvolní pro interaktivní prohlížení.

Když prohlížeč sladíte s asynchronními vzory .NET, Doconut vám umožní obsloužit tisíce souběžných relací na skromném VM clusteru.

Jak povolit lazy načítání

  1. Zaregistrujte middleware Doconut ve vaší ASP.NET Core pipeline. Middleware zachytává požadavky prohlížeče a vkládá potřebné služby.
  2. Otevírejte dokumenty jako streamy místo načítání celého souboru. Metoda OpenDocument od Doconut přijímá cestu k souboru nebo stream a vrací token představující otevřený dokument.
  3. Požadujte stránky na vyžádání z klientské strany. Když front‑end požaduje konkrétní stránku, Doconut načte jen potřebné objekty, vykreslí rastrový obrázek a vrátí lehký náhled.

Protože prohlížeč pracuje s streamy, můžete uchovávat soubory v Azure Blob Storage, Amazon S3 nebo lokálním NAS bez jejich kopírování na lokální disk webového serveru. OS provádí stránkování a .NET runtime drží jen malé buffery potřebné pro aktivní stránku.

Výhody pro nasazení ve velkém měřítku

VýhodaJak Doconut toho dosahuje
Předvídatelné využití RAMCache stránek pevné velikosti + přístup pouze přes stream
Rychlé vykreslení první stránkyNačte jen hlavičku dokumentu a objekty první stránky
Škálovatelnost napříč prohlížečiStejná logika založená na streamu funguje pro front‑endy HTML5/React, Angular nebo Vue
Snížený tlak na GCŽádná velká přichycovaná pole bajtů; všechny buffery jsou krátkodobé

Spojte lazy načítání s background konverzními úlohami a webová vrstva se nikdy nezastaví při CPU‑intenzivních transformacích.

.NET pluginy pro anotaci a OCR bez nadměrné zátěže

Podniky milují anotaci a vyhledávatelný OCR, ale naivní přístup uchovává bitmapu plného rozlišení každé stránky v paměti jen pro kreslení zvýraznění nebo provádění rozpoznávání textu. Model pluginů Doconut izoluje tyto funkce do nezávislých služeb na vyžádání.

Anotace – lehká správa po stránkách

Když je stránka načtena, můžete získat správce anotací, který drží jen vektorová data (souřadnice, styl, poznámky). Přidání razítka nebo zvýraznění aktualizuje tento vektorový úložiště; podkladová bitmapa se nikdy nekopíruje. Doconut znovu vykreslí stránku s překryvem pouze na požádání klienta, takže i PDF s 500 stránkami a tisíci anotacemi spotřebuje jen zlomek paměti, kterou by vyžadovalo bitmapové řešení.

OCR – extrakce textu za běhu

Search Plugin provádí OCR pouze na stránkách, ke kterým uživatel scrolluje. V nastavení dokumentu nastavíte požadované rozlišení obrázku (např. 200 dpi) a Doconut extrahuje text pro aktuální stránku, výsledek uloží do komprimovaného indexu spojeného s tokenem dokumentu. OCR proces je oddělený od renderování, což vám umožní horizontálně škálovat (např. pomocí Azure Functions) bez zvětšování paměťové stopy webového serveru, který poskytuje prohlížeč.

Proč je to důležité pro velké podniky

  • Předvídatelné náklady – anotace a OCR běží po stránkách, ne po dokumentu, udržují spotřebu paměti lineární k viditelnému obsahu.
  • Připravenost na shodu – anotace jsou uloženy jako XML, což usnadňuje audity nebo redakce.
  • Bezpečnost pro multi‑tenanty – token každého tenanta izoluje jeho OCR index, zabraňuje úniku dat mezi tenanty.

Server‑side konverze a řízený tisk: udržení efektivity zátěží

Mnoho portálů potřebuje konvertovat Office soubory, CAD výkresy nebo e‑mailové zprávy do PDF nebo obrazových formátů pro jednotné renderování. Častá past je provádět konverzi v‑processu, což způsobuje špičky RAM a CPU, zatímco uživatel čeká. Converter Plugin od Doconut přesouvá těžkou práci na server‑side službu, kterou můžete horizontálně škálovat.

Konverze bez načtení celého zdrojového souboru

API pro konverzi přijímá cesty ke zdroji a cíli (nebo streamy) a funguje ve streamovacím režimu, takže zdrojový soubor není nikdy plně materializován v paměti. Jakmile je PDF (nebo jiný cílový formát) připraven, prohlížeč jej otevře pomocí stejné techniky lazy‑loadingu popsané dříve.

Řízený tisk – vyhněte se rasterizaci celého dokumentu

Při tisku velkých PDF Doconut streamuje tiskové úlohy stránku po stránce do tiskového driveru. Tento přístup vám umožní vynutit kvóty nebo vodoznaky, aniž byste kdy načetli celý dokument do RAM.

Škálování na úrovni podniku

ScénářTechnika úspory paměti Doconut
Dávková konverze 10 000 Office souborůPoužijte background pracovníky s konverzí založenou na streamu; každý pracovník zpracuje jeden soubor najednou, udržuje RAM nízkou.
Tisk na vyžádání 5‑ciferných CAD výkresůTisk pomocí streamu stránek; není vyžadována rasterizace celého výkresu.
Multi‑tenant SaaS portálOddělte konverzní fronty pro každého tenanta; izolace paměti je automatická, protože každá úloha pracuje na vlastním streamu.

Nejlepší postupy pro škálování Doconut v podnikovém prostředí

I když máte paměťově efektivní engine, reálná nasazení potřebují několik ochranných opatření. Níže jsou osvědčené postupy, které zesilují vestavěné silné stránky Doconut.

1. Omezte velikost cache stránek na relaci

Nastavte prohlížeč tak, aby v paměti uchovával jen nejnovější stránky. Snížení velikosti cache přímo snižuje spotřebu RAM na relaci.

2. Spouštějte OCR a konverzi v izolovaných mikro‑službách

Nasazujte Search Plugin a Converter Plugin jako samostatné kontejnery za zprávovou frontou (RabbitMQ, Azure Service Bus, atd.). To izoluje špičky paměti a umožní vám automaticky škálovat každou komponentu nezávisle.

3. Povolit .NET 6 Trim a ReadyToRun

Při publikování vašeho API poháněného Doconut zapněte trimování, aby se odstranil nepoužívaný IL a zmenšila se velikost binárky:

dotnet publish -c Release -r win-x64 --self-contained true /p:PublishTrimmed=true

Menší binárka znamená menší pracovní sadu, což se překládá na méně RAM na kontejner.

Závěr

Optimalizace využití paměti je nezbytná pro jakékoli řešení prohlížení dokumentů ve velkém měřítku. Využitím stream‑first architektury Doconut, závislostmi optimalizovaného jádra a pluginů pro anotaci/OCR na vyžádání můžete udržet spotřebu RAM předvídatelnou a zároveň poskytovat rychlé a responzivní prohlížení. Nasazením doporučených postupů—distribuovaná tokenová cache, omezené cache stránek, izolace mikro‑služb a trimované buildy—odhalíte plný škálovací potenciál Doconut.

Chcete vidět rozdíl na vlastní oči? Začněte ještě dnes s bezplatnou zkušební verzí Doconut a zažijte nízkopaměťové, výkonné prohlížení dokumentů ve vašich .NET aplikacích.

#document viewer#performance#.NET#enterprise#Doconut#prohlížeč dokumentů#výkon#podniková