Jeśli renderujesz kilkaset PDF dziennie na jednej backendowej Lambda albo małym podzie Kubernetes, architektura nie ma większego znaczenia. Wszystko działa. Wszystko jest wystarczająco szybkie.

W skali sytuacja się zmienia. Gdy emitujesz dziesiątki tysięcy dokumentów dziennie — czyli mniej więcej każda platforma ecommerce, przewoźnik logistyczny, usługa BNPL, dostawca payroll albo platforma fakturowania z choćby umiarkowaną trakcją — trzy liczby zaczynają boleć:

Latencja cold start, bo coś zawsze jest gdzieś zimne.
Latencja regionalna, bo klienci nie siedzą obok Twojego origin.
Compute na pojedyncze renderowanie, bo płacisz za nie dziesiątki tysięcy razy dziennie.

Ten tekst pokazuje, jak każda z tych liczb zmienia się po przekroczeniu około 10 000 renderowań dziennie i dlaczego silniki renderowania wdrożone na edge, takie jak gPdf, są zasadniczo inną kategorią rozwiązania, a nie “tym samym, tylko szybszym”.

1. Podatek cold start narasta wraz ze współbieżnością

Cold start nie jest tylko drobną uciążliwością — jest funkcją krzywej współbieżności. Zwykle wygląda to tak:

Provisionujesz N=10 ciepłych kontenerów według średniego ruchu.
Przychodzi skok 3×: Black Friday, dzień wypłat, koniec kwartału.
20 nowych kontenerów cold-startuje, aby wchłonąć skok. Każdy potrzebuje 1,5-2,5 s na uruchomienie Chromium / Prince / Twojego runtime.
Przez te 30 sekund nowe kontenery obsługują ruch z p99 = 2 s, ciągnąc za sobą globalne p99.
Budżet timeout downstream, prawdopodobnie 5-10 s dla całego procesu zamówienia, zostaje zjedzony przez generowanie PDF.

To jest akceptowalne przy płaskim ruchu. Jest brutalne przy ruchu skokowym, a ruch PDF jest zawsze skokowy — faktury wychodzą na granicach cyklu rozliczeniowego, etykiety przy odbiorach przewoźników, zestawienia na koniec miesiąca.

Alternatywa na edge: izolat Cloudflare Worker cold-startuje w 5-20 ms, nie w 1,5-2,5 s. Nie ma kontenera do uruchomienia, JVM/V8 do inicjalizacji ani przeglądarki do bootstrappingu — moduł WASM ładuje się do procesu, który już żyje. Cold start przestaje być czymś, wokół czego projektujesz architekturę.

Dla gPdf najgorszy cold start zaobserwowany w benchmarkach wynosi około 12 ms — i dotyczy tylko pierwszego żądania do świeżo przydzielonego izolatu. Kolejne żądania na tym samym izolacie pomijają nawet ten koszt.

2. Latencja regionalna jest realna, nawet przy “szybkich” żądaniach

Round trip z Sydney do origin w us-east-1 to 200 ms, zanim Twój kod zrobi cokolwiek. Z São Paulo do eu-west-1: około 190 ms. Z Mumbaju do us-east: około 220 ms.

To jest w każdą stronę. Centralne API PDF wykonujące 300 ms renderowania po stronie serwera wygląda z perspektywy klienta w Sydney tak:

client → us-east  : 200 ms
us-east render    : 300 ms
us-east → client  : 200 ms
total wall-clock  : 700 ms

Dla przepływu interaktywnego, na przykład “pokaż podgląd faktury przed wysłaniem”, to boli. Dla wysokonakładowego zadania backendowego jest mniej zauważalne.

Alternatywa na edge: Cloudflare działa w ponad 300 miastach. Najbliższe colo dla klienta w Sydney jest około 5 ms dalej. Ten sam render wygląda tak:

client → SYD colo : 5 ms
SYD render        : 4 ms
SYD → client      : 5 ms
total wall-clock  : 14 ms

To 50× poprawy dla przepływów interaktywnych. Dla zadań backendowych efekt może się znosić, ale interaktywne podglądy PDF (“pokaż, jak to wygląda przed wysłaniem”) stają się bezbolesne zamiast szarpane.

Ukryta korzyść drugiego rzędu: jeśli API PDF działa na edge, możesz przenieść tam również logikę sąsiadującą — podgląd PDF w checkout, rate limit, sprawdzenie auth. Każdy element przesunięty na edge usuwa jeden round trip z gorącej ścieżki.

3. Compute za renderowanie to rachunek, który narasta po cichu

Matematyka Lambda przy 100 000 renderowań dziennie:

Puppeteer przy około 600 ms wall i 1024 MB pamięci: około 240 USD/mies. za sam compute, przed egress.
DocRaptor w progu 89 USD/100 000 stron: około 2 670 USD/mies. przy 100 000/dzień, czyli 3 mln/mies.
gPdf w progu 5 USD/100 000 stron: około 150 USD/mies. przy 100 000/dzień. Albo około 5 USD/mies., jeśli trafiasz dokładnie w 100 000/mies.

Różnica kosztu nie znika ze skalą — rośnie. Przy 1 mln renderowań dziennie:

Puppeteer infra: około 2 400 USD/mies. + ops + dyżury
DocRaptor: około 26 700 USD/mies.
gPdf: 1 500 USD/mies. flat (5× progu 100 000/dzień, zakładając negocjowany wolumen na publicznej siatce cenowej)

Częsta reakcja: “Na pewno oszczędności są w praktyce mniejsze — musi być coś ukrytego”. Z naszego doświadczenia: nie. Głównym nośnikiem kosztu generowania PDF jest ślad compute silnika renderowania. Gdy zamieniasz proces Chromium ważący 600 MB na moduł WASM 4 MB, koszt pojedynczego renderowania spada około 100×, a rachunek podąża za nim.

To działa bez doprowadzania nas do strat, ponieważ bazowa cena Cloudflare Workers Bundled to około 0,50 USD za milion żądań. Przy naszym silniku zużywającym około 1,5 ms CPU na wywołanie koszt własny jednego renderowania jest realnie podcentowy. Dodajemy umiarkowaną marżę, żeby biznes był trwały, a Ty nadal widzisz różnicę 18×.

Co naprawdę kupuje “wdrożenie na edge”

Trzy rzeczy, żadna z nich nie jest slajdem marketingowym:

Przewidywalna latencja pod dowolnym obciążeniem

Ponieważ nie ma kosztu bootowania na żądanie, p50 i p99 pozostają blisko siebie. Zwykle widzimy p99 w granicach 3× p50 nawet w szczycie skoku ruchu — w Puppeteer p99 potrafi dojść do 10× p50 podczas burz cold start.

Jeden artefakt wdrażalny wszędzie

Moduł .wasm wdraża się identycznie do każdego colo Cloudflare. Nie ma pytania “czy pula w Sydney jest ciepła?” — każdy izolat bootuje moduł w milisekundach i obsługuje tak samo. Operacyjnie to naprawdę prostsze niż utrzymywanie regionalnych rezerw współbieżności Lambda.

Ścieżka do osadzania

Jeśli kiedykolwiek chcesz uruchomić gPdf wewnątrz granicy klienta: w jego VPC, izolowanym klastrze albo air-gapped intranecie, ten sam moduł WASM działa. To różnica między “hostujemy SaaS” a “dostarczamy technologię, która działa wszędzie”.

Gdzie to się załamuje

Edge nie jest darmową magią — są obciążenia, przy których centralizacja wygrywa:

Wielosekundowe renderowania. Jeśli pojedynczy PDF zajmuje 30 s: ogromne zestawienia finansowe, raporty naukowe, lepszy będzie long-running container z trwałym stanem niż walka z limitami CPU na edge.
Renderowania potrzebujące innych baz danych. Jeśli render wymaga JOIN trzech tabel OLAP, chcesz mieć silnik renderowania obok bazy, nie na edge. Rozwiązanie: wykonaj JOIN, a potem wyślij JSON na edge do właściwego renderowania.
Wyniki wymagające postprocessingu. Znak wodny, podpisywanie, archiwizacja — jeśli pipeline po renderowaniu jest wieloetapowy i stanowy, bezstanowość edge staje się kosztem, nie zaletą.

Dla wszystkiego innego — a to zdecydowana większość ruchu B2B dla faktur, etykiet i potwierdzeń — edge wygrywa na każdej osi, która ma znaczenie.

Kiedy przestać tolerować obecny setup

Prosta lista kontrolna. Jeśli możesz zaznaczyć trzy punkty, matematyka migracji już się przechyliła:

Miesięczny koszt infrastruktury PDF przekracza 300 USD.
Latencja p99 PDF przekracza 800 ms przy normalnym ruchu.
Masz za sobą incydent cold start, który dotknął klientów.
Spędziłeś ponad 4 godziny na debugowaniu brakujących glifów CJK / RTL / emoji.
Generujesz PDF w przepływie interaktywnym: preview albo pobranie na ekranie.
Działasz w więcej niż jednym regionie geograficznym.

Pierwsze trzy elementy razem oznaczają, że jednocześnie płacisz i cierpisz. Kolejne trzy oznaczają, że scentralizowany silnik renderowania aktywnie ogranicza decyzje produktowe, które inaczej mógłbyś podjąć.

Jeśli coś z tego brzmi znajomo, Playground renderuje przykładową fakturę w przeglądarce w mniej niż 5 ms — niech wynik mówi sam za siebie.