Kompromisy obrazu natywnego

Obraz natywny jest potężny, ale nie jest darmowy. W zamian za szybkie uruchamianie i niewielkie zużycie pamięci rezygnuje się z elastyczności JVM w czasie działania. Zrozumienie tych kompromisów pomaga zdecydować, kiedy wybór rozwiązania natywnego jest właściwy.

To najważniejsza korzyść. Natywny plik binarny pomija ładowanie klas, weryfikację kodu bajtowego i rozgrzewanie JIT. Może uruchomić się w kilka milisekund zamiast setek milisekund w przypadku JVM — to przełomowa różnica dla narzędzi CLI i funkcji serverless.

Brak kompilatora JIT, struktur profilowania oraz wstępnie obliczonej sterty obrazu oznacza, że proces natywny zużywa znacznie mniej pamięci RAM. Dzięki temu można umieścić więcej instancji w jednym kontenerze i agresywnie zmniejszać skalę.

To kluczowy kompromis. Kompilator JIT optymalizuje kod na podstawie aktywnych profili czasu działania, dlatego długo działająca maszyna JVM może osiągnąć wyższą szczytową przepustowość niż plik binarny AOT zoptymalizowany bez informacji o działaniu programu podczas kompilacji. W przypadku długotrwałych, intensywnie obciążonych zadań JVM może nadal wygrywać.

GraalVM zmniejsza różnicę w przepustowości dzięki mechanizmowi PGO: należy zbudować obraz z instrumentacją, uruchomić reprezentatywne obciążenie, aby zebrać profile, a następnie ponownie zbudować obraz z użyciem tych profili. Plik binarny AOT będzie wtedy przypominał rozgrzany kompilator JIT dla tego obciążenia.

Budowanie obrazu natywnego jest powolne i wymaga dużo pamięci — w przypadku dużych aplikacji może zająć minuty czasu procesora i wymagać gigabajtów pamięci RAM. Wydłuża to potoki CI w porównaniu z szybkim budowaniem pliku jar.

Refleksja, proxy i zasoby wymagają metadanych, co omówiono wcześniej. Kod, który w dużym stopniu polega na ładowaniu klas w czasie działania lub generowaniu kodu bajtowego, może być trudny albo niemożliwy do przekształcenia w pełni natywną postać bez wprowadzania zmian.

Niektóre narzędzia JVM działają inaczej w trybie natywnym. Standardowe agenty JVMTI i niektóre profilery nie podłączają się w ten sam sposób; zamiast nich używa się monitorowania lub próbkowania właściwego dla native-image. Należy odpowiednio zaplanować strategię obserwowalności.

Obraz natywny udostępnia własne mechanizmy GC (prosty Serial GC oraz G1 w niektórych edycjach). W przypadku bardzo dużych stert pełny zestaw mechanizmów GC JVM może zapewniać mniejsze opóźnienia. Należy dopasować mechanizm GC do rozmiaru sterty i wymagań dotyczących przerw dla danego obciążenia.

• Funkcje bezserwerowe skalowane do zera.
• Narzędzia CLI, w których dominuje czas uruchamiania.
• Mikrousługi w gęsto upakowanych kontenerach.
• Krótkotrwałe zadania wsadowe.

• Długo działające usługi, w których przepustowość ma kluczowe znaczenie, a istotna jest szczytowa wydajność JIT.
• Aplikacje intensywnie korzystające z dynamicznego ładowania klas lub generowania kodu bajtowego.
• Obciążenia zależne od narzędzi opartych na JVMTI.

Sprawdźcie Państwo, czy rozumieją Państwo kompromisy związane z obrazem natywnym.

Rozważyli Państwo kompromisy związane z obrazem natywnym:

• Zalety: uruchamianie w milisekundach i małe zużycie pamięci.
• Koszty: potencjalnie niższa szczytowa przepustowość, powolne kompilacje, metadane wymagane przez funkcje dynamiczne oraz różnice w narzędziach.
• PGO zmniejsza różnicę w przepustowości dzięki ponownym kompilacjom sterowanym profilami.
• Obraz natywny dobrze sprawdza się w narzędziach CLI, funkcjach bezserwerowych i gęsto upakowanych mikrousługach.
• JVM lepiej pasuje do długo działających aplikacji o krytycznej przepustowości i dużym wykorzystaniu funkcji dynamicznych.