Zimny ​​start WebAssembly: co pokazują testy porównawcze

Zimny ​​start po raz kolejny stał się osią komercyjnego zróżnicowania środowisk wykonawczych WebAssembly, a nie tylko przedmiotem badań akademickich. Wasmer wyraźnie podkreśla tę zaletę, oferując funkcję o nazwie Instaboot, przedstawioną jako bezpośrednia odpowiedź na problem zimnego rozruchu.

Odruch ten dokładnie przypomina dynamikę udokumentowaną już w naszym artykule na temat metodologii testów porównawczych backendu: kilku konkurujących dostawców wyświetla dane dotyczące wydajności na swoich stronach produktów, nie zawsze określając protokół, który je wygenerował. Wartość zimnego startu bez metody nie dowodzi niczego więcej niż wartość opóźnienia bez metody.

Zimny ​​start nie jest pojedynczą operacją: jest to suma odrębnych faz, a dwóch dostawców niekoniecznie mierzy te same fazy pod tą samą nazwą.

Liczba, która liczy tylko instancję modułu już załadowanego i już wkompilowanego w pamięć, będzie mechanicznie wyglądać lepiej niż figura obejmująca ładowanie i kompilację sieci. Żadne z nich nie jest samo w sobie fałszywe: problem pojawia się, gdy je porównamy, nie określając, który z nich został zmierzony.

W pracach akademickich opublikowanych w ostatnich latach jako wydruk wstępny w arXiv zmierzono czas tworzenia instancji modułów WebAssembly w różnych środowiskach wykonawczych. Punktem wspólnym tych prac nie jest liczba zbieżna: jest to znacząca różnica w zależności od testowanego czasu działania, wielkości modułu i użytego sprzętu.

Dobrowolnie nie zamieszczamy w tym artykule żadnych dokładnych danych liczbowych zaczerpniętych z tych publikacji. Bez dokładnego sprawdzenia metodologii każdego artykułu w momencie jego pisania, ponowne opublikowanie pojedynczej liczby dokładnie odtworzyłoby problem dokumentowany w tym artykule: liczbę bez kontekstu, który pozwoliłby nam dowiedzieć się, co tak naprawdę mierzy.

Z drugiej strony to, czego uczy się ta wariancja, jest bezpośrednio przydatne: zimny start silnie zależy od kontekstu pomiaru, dokładnie tak, jak przypomina dyscyplina parzystości środowiska opisana w naszym artykule dotyczącym ogólnej metodologii (identyczny sprzęt, ten sam region, ten sam stan pamięci podręcznej dla wszystkich porównywanych systemów).

Trzy niezależne środowiska wykonawcze WebAssembly, najczęściej cytowane w tej debacie, nie równoważą w ten sam sposób szybkości kompilacji i wydajności wykonania, co częściowo wyjaśnia, dlaczego ich dane dotyczące zimnego startu nie są porównywalne w poszczególnych terminach.

Aby zapoznać się ze wszystkimi szczegółami architektonicznymi pomiędzy dwoma środowiskami wykonawczymi, które są najczęściej przeciwstawiane w dyskusjach bezserwerowych, zobacz nasze dedykowane porównanie Wasmtime vs Wasmer.

Zgodnie z pozycją produktu, którą Wasmer komunikuje publicznie, Instaboot przywraca instancję już zainicjowaną przez mechanizm migawki, zamiast ponownie uruchamiać pełne uruchomienie przy każdym żądaniu. To prawdziwy wybór architektoniczny, zgodny z problemem, którego dotyczy.

Artykuł ten nie zawiera jednak powtórzenia parametrów wydajności wyświetlanych na stronie produktu Wasmer. Nie wiedząc, jaki sprzęt, przy jakim obciążeniu pracą i jaki protokół pomiarowy wygenerował tę liczbę, ponowna jej publikacja popełniłaby dokładnie błąd opisany powyżej: traktowanie liczby marketingowej jako niezależnego wyniku testu porównawczego.

Aurabase uruchamia funkcje Edge na platformie Wasmtime w fazie produkcyjnej, a nie w ramach projektu pilotażowego. Oto dokładnie, na co pozwala złożenie wniosku i gdzie kończy się to roszczenie.

Zależność jest deklarowana jako twarda, z aktywowanymi funkcjami async i cranelift w zależnościach produkcyjnych usługi, a nie w dev-dependency ani komentarzu:

# Rzeczywisty ekstrakt z repozytorium
[dependencies]

# Środowisko wykonawcze WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Czego ten plik nie mówi: w repozytorium dla tego środowiska wykonawczego nie istnieją obecnie żadne dane dotyczące zimnego startu zmierzone zgodnie z protokołem opisanym w naszej metodologii testów porównawczych . Do czasu opublikowania datowanego pomiaru ze zdezagregowanymi percentylami, sprzętem i obciążeniem pracą nie należy podawać żadnych wartości Aurabase jako zmierzonej cechy produktu. Ogólną architekturę platformy można znaleźć w naszym artykule filarowym Architektura Aurabase Rust. Konkretne porównanie pomiędzy WASM uruchamianym na zimno a kontenerem uruchamianym na zimno, niezależnie od poruszanej tutaj kwestii metodologicznej, można znaleźć w naszym dedykowanym artykule WASM vskontenery.

Siedem pytań, które należy zadać każdemu, kto zaczyna grę na zimno, łącznie z naszymi w dniu premiery.

1. Jakie fazy są uwzględnione? Ładowanie sieci, sprawdzanie poprawności, kompilacja, tworzenie instancji, pierwsze wywołanie: liczba, która liczy tylko część, nie jest porównywalna z liczbą, która liczy je wszystkie.
2. Czy moduł był naprawdę „zimny”? Moduł znajdujący się już w pamięci lub pamięci podręcznej dysku nie testuje tego samego, co moduł ładowany po raz pierwszy.
3. Kompilacja JIT czy prekompilowany artefakt (AOT)? Obie strategie mają strukturalnie różne koszty początkowe.
4. Jednocyfrowa czy dystrybucja? Najlepszy wynik w dziesięciu nie ma takiej samej wartości jak p95 w tysiącu przebiegów.
5. Określono sprzęt i region? Rysunek bez specyfikacji sprzętowej nie może być reprodukowany przez osoby trzecie.
6. Porównanie przy równym obciążeniu i topologii? Porównanie własnego środowiska wykonawczego z usługą zarządzaną bez raportowania tego zniekształca odczyt.
7. Data i wersja przetestowanego środowiska wykonawczego? Niedatowana liczba w projekcie, który szybko się rozwija, po kilku miesiącach nic nie znaczy.