Optymalizacja zużycia pamięci w aplikacjach do przeglądania dokumentów na dużą skalę

Optymalizacja zużycia pamięci w przeglądarkach dokumentów .NET na dużą skalę z Doconut

Masz tysiące plików PDF, dokumentów Office lub rysunków CAD do wyświetlenia w portalu opartym na .NET? I nie chcesz, aby Twój serwer wyczerpał pamięć RAM? Sztuczka polega na połączeniu leniwego strumieniowania, ukierunkowanych wtyczek i zoptymalizowanego potoku renderowania Doconut. W kolejnych sekcjach przeanalizujemy problemy związane z pamięcią, które pojawiają się w aplikacjach na skalę korporacyjną, obciążonych dokumentami, a następnie pokażemy, jak Doconut — uniwersalna przeglądarka dokumentów dla backendów .NET — przełamuje wąskie gardła, które uniemożliwiają tradycyjnym przeglądarkom skalowanie. A przy okazji czeka darmowy okres próbny, jeśli chcesz zobaczyć korzyści w własnym środowisku.

Zrozumienie presji pamięci w przeglądarkach dokumentów .NET

Duże portale dokumentacyjne często wczytują cały plik do pamięci, zanim pojawi się pierwsza strona. Rysunek CAD o wielkości 200 MB lub PDF o 500 stronach może szybko przytłoczyć zbieracz śmieci .NET, wywołać pełne przerwy GC i zmusić Cię do nadmiernego przydzielania zasobów serwerów.

Dlaczego domyślny model renderowania .NET utrudnia skalowalność

Objaw	Typowa przyczyna w nieprzemyślanych implementacjach
Wyjątki braku pamięci	Tablice bajtów całego pliku przechowywane w statycznej pamięci podręcznej
Wolne ładowanie pierwszej strony	Dekodowanie całego dokumentu przed renderowaniem
Niedobór wątków w puli	Długotrwałe renderowanie obciążone CPU blokuje asynchroniczne potoki
Nieprzewidywalne skoki opóźnień	Zbieranie dużych przypiętych obiektów przez GC

Dodaj wtyczki anotacji lub OCR, które gromadzą bitmapy obrazów, a presja się zwiększa. Optymalnym rozwiązaniem jest przetwarzanie tylko tego, czego użytkownik potrzebuje w danej chwili i utrzymywanie każdego pośredniego bufora krótkotrwałego.

Odpowiedź Doconut: lekki, zoptymalizowany pod względem zależności rdzeń

Architektura oparta na .NET 6 firmy Doconut została przebudowana, aby zredukować przydziały na stercie:

Optymalizacja zależności – biblioteka ładuje tylko moduły renderujące wymagane dla bieżącego typu pliku (PDF, Office, CAD, obraz). Nieużywane wtyczki pozostają poza pamięcią, co utrzymuje mały rozmiar procesu.
Projekt oparty na strumieniach – pliki są otwierane jako strumienie, a nie jako całe tablice bajtów, dzięki czemu środowisko wykonawcze może pobierać dane z dysku na żądanie.
Wsparcie zadań w tle – ciężkie zadania konwersji mogą być przekazywane do procesów roboczych lub Azure Functions, pozostawiając warstwę webową wolną dla interaktywnego przeglądania.

Gdy dopasujesz przeglądarkę do asynchronicznych wzorców .NET, Doconut umożliwia obsługę tysięcy jednoczesnych sesji na skromnym klastrze maszyn wirtualnych.

Jak włączyć leniwe ładowanie

Zarejestruj middleware Doconut w swoim potoku ASP.NET Core. Middleware przechwytuje żądania przeglądarki i wstrzykuje niezbędne usługi.
Otwieraj dokumenty jako strumienie zamiast ładować cały plik. Metoda OpenDocument Doconut przyjmuje ścieżkę do pliku lub strumień i zwraca token reprezentujący otwarty dokument.
Żądaj stron na żądanie po stronie klienta. Gdy front‑end poprosi o konkretną stronę, Doconut odczytuje tylko niezbędne obiekty, renderuje obraz rastrowy i zwraca lekki miniaturę.

Ponieważ przeglądarka działa z strumieniami, możesz przechowywać pliki w Azure Blob Storage, Amazon S3 lub lokalnym NAS bez kopiowania ich na lokalny dysk serwera webowego. System operacyjny zajmuje się stronicowaniem, a środowisko .NET utrzymuje jedynie małe bufory potrzebne dla aktywnej strony.

Korzyści dla wdrożeń na dużą skalę

Korzyść	Jak Doconut to osiąga
Przewidywalne zużycie RAM	Cache stron o stałym rozmiarze + dostęp wyłącznie strumieniowy
Szybkie renderowanie pierwszej strony	Odczytuje tylko nagłówek dokumentu i obiekty pierwszej strony
Skalowalne w różnych przeglądarkach	Ta sama logika oparta na strumieniach działa dla front‑endów HTML5/React, Angular lub Vue
Zmniejszona presja GC	Brak dużych przypiętych tablic bajtów; wszystkie bufory są krótkotrwałe

Połącz leniwe ładowanie z zadaniami konwersji w tle, a warstwa webowa nigdy nie zaciąga się przy transformacjach obciążonych CPU.

Wtyczki .NET do anotacji i OCR bez nadmiernego obciążenia

Przedsiębiorstwa uwielbiają anotacje i wyszukiwalny OCR, ale nieprzemyślane podejście utrzymuje bitmapę pełnej rozdzielczości każdej strony w pamięci, aby rysować podświetlenia lub wykonywać rozpoznawanie tekstu. Model wtyczek Doconut izoluje te funkcje w niezależnych usługach na żądanie.

Anotacje – lekkie zarządzanie na poziomie strony

Gdy strona zostanie załadowana, możesz pobrać menedżer anotacji, który przechowuje jedynie dane wektorowe (współrzędne, styl, notatki). Dodanie pieczątki lub podświetlenia aktualizuje ten wektorowy magazyn; podstawowa bitmapa nigdy nie jest duplikowana. Doconut ponownie renderuje stronę z nakładką tylko wtedy, gdy klient o to poprosi, więc nawet PDF o 500 stronach z tysiącami anotacji zużywa tylko ułamek pamięci, jaką wymagałoby rozwiązanie oparte na bitmapach.

OCR – wyodrębnianie tekstu w locie

Wtyczka wyszukiwania uruchamia OCR tylko na stronach, do których przewija się użytkownik. Konfigurujesz żądaną rozdzielczość obrazu (np. 200 dpi) w opcjach dokumentu, a Doconut wyodrębnia tekst dla bieżącej strony, przechowując wynik w skompresowanym indeksie powiązanym z tokenem dokumentu. Proces OCR jest odseparowany od renderowania, co pozwala skalować go poziomo (np. za pomocą Azure Functions) bez zwiększania zużycia pamięci serwera webowego obsługującego przeglądarkę.

Dlaczego ma to znaczenie dla dużych przedsiębiorstw

Przewidywalny koszt – anotacje i OCR działają na poziomie strony, a nie dokumentu, utrzymując zużycie pamięci liniowo względem widocznej treści.
Gotowy pod kątem zgodności – anotacje są przechowywane jako XML, co ułatwia audyty lub redakcję.
Bezpieczeństwo wielodzierżawcze – token każdego najemcy izoluje jego indeks OCR, zapobiegając wyciekowi danych między najemcami.

Konwersja po stronie serwera i kontrolowane drukowanie: utrzymanie wydajności obciążeń

Wiele portali musi konwertować pliki Office, rysunki CAD lub wiadomości e‑mail na format PDF lub obrazu w celu jednolitego renderowania. Częstym pułapką jest wykonywanie konwersji w procesie, co powoduje skoki zużycia RAM i CPU, gdy użytkownik czeka. Wtyczka konwertera Doconut przenosi ciężkie operacje do usługi po stronie serwera, którą możesz skalować poziomo.

Konwersja bez wczytywania całego pliku źródłowego

API konwersji przyjmuje ścieżki źródłowe i docelowe (lub strumienie) i działa w trybie strumieniowym, więc plik źródłowy nigdy nie jest w pełni materializowany w pamięci. Gdy PDF (lub inny format docelowy) jest gotowy, przeglądarka otwiera go przy użyciu tej samej techniki leniwego ładowania opisanej wcześniej.

Kontrolowane drukowanie – unikanie rasteryzacji całego dokumentu

Podczas drukowania dużych plików PDF, Doconut strumieniuje zadania drukowania strona po stronie do sterownika drukarki. Takie podejście pozwala egzekwować limity lub znaki wodne bez konieczności ładowania całego dokumentu do RAM.

Skalowanie na poziomie przedsiębiorstwa

Scenariusz	Technika oszczędzania pamięci Doconut
Wsadowa konwersja 10 000 plików Office	Użyj pracowników w tle z konwersją opartą na strumieniach; każdy pracownik obsługuje jeden plik naraz, utrzymując niskie zużycie RAM.
Drukowanie na żądanie rysunków CAD pięciocyfrowych	Drukuj za pomocą strumienia stron; nie wymaga pełnej rasteryzacji rysunku.
Portal SaaS wielodzierżawczy	Oddzielne kolejki konwersji dla każdego najemcy; izolacja pamięci jest automatyczna, ponieważ każde zadanie działa na własnym strumieniu.

Najlepsze praktyki skalowania Doconut w środowiskach przedsiębiorstw

Nawet przy silniku oszczędzającym pamięć, wdrożenia w rzeczywistym świecie wymagają kilku zabezpieczeń. Poniżej przedstawiono sprawdzone praktyki, które wzmacniają wbudowane mocne strony Doconut.

1. Ogranicz rozmiar pamięci podręcznej stron na sesję

Skonfiguruj przeglądarkę, aby przechowywała w pamięci tylko najnowsze strony. Zmniejszenie rozmiaru pamięci podręcznej bezpośrednio obniża zużycie RAM na sesję.

2. Uruchamiaj OCR i konwersję w odizolowanych mikro‑usługach

Wdroż Wtyczkę wyszukiwania i Wtyczkę konwertera jako oddzielne kontenery za kolejką komunikatów (RabbitMQ, Azure Service Bus itp.). To izoluje skoki pamięci i pozwala automatycznie skalować każdy komponent niezależnie.

3. Włącz Trim i ReadyToRun w .NET 6

Podczas publikowania API napędzanego przez Doconut włącz przycinanie, aby usunąć nieużywany IL i zmniejszyć rozmiar binarki:

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

Mniejsza binarka oznacza mniejszy zestaw roboczy, co przekłada się na mniejsze zużycie RAM na kontener.

Podsumowanie

Optymalizacja zużycia pamięci jest niezbędna dla każdej rozwiązania do przeglądania dokumentów na dużą skalę. Korzystając z architektury opartej na strumieniach Doconut, rdzenia zoptymalizowanego pod względem zależności oraz wtyczek anotacji/OCR na żądanie, możesz utrzymać przewidywalne zużycie RAM, jednocześnie zapewniając szybkie i responsywne doświadczenia przeglądania. Wdroż zalecane wzorce najlepszych praktyk — rozproszoną pamięć podręczną tokenów, ograniczone buforowanie stron, izolację mikro‑usług i przycięte kompilacje — a odblokujesz pełny potencjał skalowalności Doconut.

Gotowy zobaczyć różnicę na własne oczy? Rozpocznij darmowy okres próbny Doconut już dziś i doświadcz niskiego zużycia pamięci oraz wysokiej wydajności przeglądania dokumentów w swoich aplikacjach .NET.