Dostarczanie danych front-end w epoce publikacji o wysokiej częstotliwości wymaga przeprojektowania współpracy w zakresie buforowania i kompresji

Gdy zasoby front-endowe wejdą w rytm wydawania wysokiej częstotliwości, problemy z wydajnością wkrótce nie będą już tak proste, jak „włączenie Brotli”. Pierwszy ekran zwalnia, ruch z powrotem do źródła wzrasta, a procesor węzła brzegowego ulega wahaniom. Na pozór wydaje się, że kompresja nie jest wystarczająco agresywna. Patrząc głębiej, często buforowanie i kompresja są optymalizowane oddzielnie i ostatecznie podważają się nawzajem w łączu publikowania.

Tego rodzaju problem zazwyczaj nie jest ujawniany w pierwszej wersji. Na początku zespół widział tylko rozproszone sygnały: niewielka zmiana spowodowała załamanie współczynnika trafień zasobów statycznych, nienormalny wzrost kompresji brzegowej procesora w przededniu dużej promocji, a wolumen pakietów zwrotnych w fazie skali szarości nie odpowiadał oficjalnemu ruchowi. Jeśli będziesz kontynuować sprawdzanie, wskazówki zwykle zbiegają się do tego samego: chociaż zawartość zasobów zmieniła się tylko nieznacznie, klucz pamięci podręcznej, dzielenie porcji i skompresowane dane wejściowe stały się innym zestawem rzeczy, a warstwa transportowa jest zmuszona ponownie przełknąć cały koszt.

Dopóki skrót zasobu nie będzie stabilny, korzyści z kompresji są po prostu nie do utrzymania.

Po równoległym wydaniu projektów front-endowych z wieloma stronami, wieloma trasami i wieloma zespołami, aspektem, który najłatwiej przeoczyć, jest stabilność nazw plików. Dopóki segmentacja fragmentów nieznacznie się zmienia, nawet jeśli kod biznesowy zmienia tylko kopię przycisku, produkt końcowy może również przepisać hash serii pakietów publicznych. System buforujący widzi partię zupełnie nowych obiektów, a system kompresji widzi partię danych wejściowych, które pojawiają się po raz pierwszy.

W tej chwili, niezależnie od tego, jak wysoki jest stopień kompresji, nie jest on w stanie uchronić współczynnika trafień przed załamaniem. Stare pliki nadal znajdują się w węzłach brzegowych, a nowe pliki zostały ponownie utworzone; Lokalna pamięć podręczna przeglądarki jest całkowicie nieprawidłowa, a CDN musi ponownie pobrać źródło, ponownie skompresować i ponownie rozpowszechnić. Drobna zmiana biznesowa jest powiększana w powtarzalną pracę dla całego łącza przesyłowego.

Naprawdę użyteczną czynnością zwykle nie jest dalsze dostosowywanie poziomu kompresji, ale najpierw sprawdzenie stabilności uwolnionego produktu:

• Zależności publiczne są podzielone na osobne warstwy, aby ograniczyć zmiany biznesowe i połączyć podstawowe pakiety w celu zmiany skrótu.
• Unikaj mieszania zmian o dużej częstotliwości, takich jak znaczniki czasu i numery wbudowane, bezpośrednio w treść produktu
• Pozwól, aby kod znajdujący się w pobliżu tej samej trasy rozpadł się na stabilne fragmenty w miarę możliwości, zamiast być przetasowywany za każdym razem, gdy jest kompilowany.

Dopiero po ustabilizowaniu się tożsamości zasobu pamięć podręczna może być stale ponownie wykorzystywana, a wyniki kompresji mają wartość skumulowaną.

Konferencja prasowa o dużej częstotliwości przepisuje problem kompresji na problem wersji słownikowej

Ponieważ zasoby stają się coraz bardziej pofragmentowane, jednoplikowy Brotli lub gzip jest nadal ważny, ale to już nie wszystko. Rzeczywisty koszt zaczyna przesuwać się w stronę zduplikowanych elementów: kod środowiska wykonawczego frameworka, szablony stylów, deklaracje typów interfejsów, warstwy opakowań generowane przez programy pakujące często są bardzo podobne w poszczególnych partiach wersji. Dzięki szybkiemu tempu wydawniczemu te riffy będą przenoszone w kółko.

Problem polega na tym, że słownik kompresji może łatwo zmienić się z optymalizacji w zakłócenie, jeśli nie będzie zarządzany wraz z rytmem wydawania. Jeśli słownik zostanie wcześniej zmieniony, nowy słownik, do którego odwołuje się stara strona, będzie niezgodny; słownik jest pocięty na zbyt wiele części, a liczba wersji utrzymywanych przez węzły brzegowe gwałtownie wzrasta; aktualizacja słownika nie jest synchronizowana z zasobem online, a obiekty, które powinny zostać trafione, wracają do pełnej transmisji.

Jest to również bardzo praktyczna zmiana w niedawnym dostarczaniu front-endu: strategie buforowania i protokoły kompresji nie mogą już być obsługiwane przez różne zespoły. Wersje zasobów, wersje słownikowe i spacje kluczy pamięci podręcznej to zasadniczo ten sam problem związany z publikowaniem.

Podejście hierarchiczne, takie jak poniższe, jest zwykle bardziej stabilne niż „ujednolicona silna kompresja dla całej witryny”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

Kluczem nie jest sama konfiguracja tych trzech linii, ale ograniczenia, które wyraża: zasoby o długim cyklu życia, lista krótkich cyklów życia i skompresowana wersja słownika muszą ewoluować razem zgodnie z tym samym rytmem wydawania.

Presja związana z powrotem do źródła często nie wynika z tego, że plik jest za duży, ale z tego, że metoda niepowodzenia jest zbyt szorstka.

Innym bardzo częstym błędem jest przypisywanie wzrostu przepustowości bezpośrednio wadze strony. Strony z pewnością stają się coraz cięższe, ale zazwyczaj najlepszym wyborem są bardziej niebezpieczne wzmacniacze online.

Jeśli przy każdej publikacji czyścisz katalog, prefiks lub nawet całą witrynę, warstwa pamięci podręcznej natychmiast utraci pamięć. W tym momencie, nawet jeśli rozmiar pliku nie będzie się zwiększał, szczytowa wartość powrotu do źródła zostanie automatycznie zwiększona. Po zwróceniu źródła krawędzie są ponownie kompresowane, obiekty ponownie podgrzewane, a przeglądarka pobierana ponownie. Okno publikowania zmieni się z drobnej zmiany na pełną relokację witryny.

W tego typu scenariuszu najcenniejszą rzeczą jest kontrolowany promień awarii:

• Unieważnij tylko manifest, HTML i zasoby zmienne, które faktycznie uległy zmianie
• Staraj się nie czyścić plików statycznych za pomocą skrótu i przekaż je nowym referencjom w celu naturalnego przełączania.
• Podziel wydanie w kolejności „najpierw prześlij nowe zasoby, następnie wytnij odniesienia, a następnie poddaj recyklingowi stare zasoby” zamiast usuwać je wszystkie na raz

To, co jest naprawdę wrażliwe na koszt transferu, to nie tylko rozmiar pliku, ale także sposób, w jaki system decyduje, które treści należy ponownie pobrać.

Obowiązująca granica jest określana wraz ze skalą zasobów i częstotliwością wydawania.

Ten zestaw wspólnego projektowania nie jest wymagany w przypadku wszystkich lokalizacji. W przypadku projektów z małą liczbą stron statycznych, małym pakietem zasobów i częstotliwością wydawania co tydzień lub nawet co miesiąc, użycie tradycyjnych nazw plików skrótu i ​​wstępnej kompresji Brotli jest zwykle wystarczająco stabilne.

Buforowanie i kompresja razem szybko stają się infrastrukturą dostarczania, gdy te cechy zostaną spełnione:

• Wydawane kilka razy dziennie, ze skalą szarości, wycofywaniem lub premierami regionalnymi
• Produkt front-end ma duży rozmiar, ma wiele zależności publicznych i złożone relacje między fragmentami.
• CDN, pamięć obiektowa, kompresja brzegowa i buforowanie przeglądarki jednocześnie uczestniczą w łączu transmisyjnym — Ruch jest tak duży, że współczynnik trafień w pamięci podręcznej i szczytowa wartość powrotu do źródła będą bezpośrednio odzwierciedlać koszt i stabilność.

Gdy dostarczanie front-endu wejdzie w ten etap, kompresja nie polega już tylko na „zmniejszaniu plików”, a buforowanie nie polega już tylko na „przechowywaniu większej liczby kopii treści”. Wspólnie decydują, czy w przypadku małej zmiany biznesowej będzie to tylko wysłanie jeszcze jednej porcji, czy też konieczne będzie ponowne uruchomienie całego łącza transmisyjnego. Im częściej publikujesz, tym droższa staje się ta różnica.