Esta es la continuación lógica de nuestra metodología de referencia , esta vez aplicada a una métrica específica. Para obtener detalles sobre la arquitectura de nuestras funciones Edge, consulte nuestro artículo principal sobre la arquitecturaRust de Aurabase, o nuestra comparación Wasmtime vs Wasmer para conocer las diferencias arquitectónicas entre los dos tiempos de ejecución.
Lo esencial
Un arranque en frío de WebAssembly agrega varias fases (cargar, confirmar, compilar o vincular, crear una instancia, primera llamada) y dos figuras que no incluyen las mismas fases no son comparables, incluso si muestran la misma unidad. Wasmer comercializa Instaboot como una respuesta de marketing directo al tema, pero sus cifras públicas no se incluyen aquí sin una metodología desagregada. Aurabase ejecuta wasmtime versión 43 como una dependencia de producción para sus funciones Edge (verificada en aura-functions/Cargo.toml), pero hasta la fecha no ha publicado ningún punto de referencia de arranque en frío reproducible. En este artículo no se dan cifras de Aurabase: el tema es el método.
Por qué el arranque en frío de WebAssembly se ha convertido una vez más en un argumento de marketing controvertido
El arranque en frío ha vuelto a convertirse en un eje de diferenciación comercial entre los tiempos de ejecución de WebAssembly, no sólo en un tema de investigación académica. Wasmer hace de esto un punto de venta explícito con una característica llamada Instaboot, presentada como una respuesta directa al problema del arranque en frío.
Este reflejo recuerda exactamente la dinámica ya documentada en nuestro artículo sobre la metodología de evaluación del backend : varios proveedores competidores muestran cifras de rendimiento en la página de su propio producto, sin especificar siempre el protocolo que las produjo. Una cifra de arranque en frío sin método no demuestra más que una cifra de latencia sin método.
Una cifra de arranque en frío publicada en una página de marketing, sin material, sin carga de trabajo y sin una definición clara del punto de partida y del final de la medición, es indistinguible de un eslogan. Esto se aplica a todos los tiempos de ejecución citados en este artículo, incluido Aurabase el día en que se publica una cifra.
Qué mide realmente un arranque en frío y por qué la definición lo cambia todo
Un arranque en frío no es una operación única: es una suma de fases distintas, y dos proveedores no miden necesariamente las mismas fases con el mismo nombre.
| Cargando | Recuperación del módulo .wasm: red, disco o ya presente en memoria |
|---|---|
| Validación | Comprobación de la estructura del código de bytes de WebAssembly antes de la ejecución |
| Compilando o vinculando | JIT sobre la marcha (Cranelift, LLVM) o vinculando un artefacto ya precompilado (AOT) |
| Creación de instancias | Asignación de memoria lineal, tablas y globales, ejecución de una posible función de inicio. |
| Primera llamada | Tramitación de la solicitud en sí, a veces incluida en la cifra anunciada, a veces excluida |
Una cifra que solo cuenta la creación de instancias de un módulo ya cargado y compilado en la memoria se verá mecánicamente mejor que una cifra que incluye la carga y compilación de la red. Ninguno de los dos es falso en sí mismo: el problema aparece cuando los comparamos sin especificar cuál de los dos se midió.
Qué muestra la literatura académica y por qué sus cifras no se comparan entre sí
El trabajo académico publicado como preimpresión en arXiv en los últimos años ha medido el tiempo de creación de instancias de los módulos WebAssembly en diferentes tiempos de ejecución. El punto común entre estos trabajos no es una cifra convergente: es una diferencia significativa según el tiempo de ejecución probado, el tamaño del módulo y el hardware utilizado.
En este artículo no incluimos voluntariamente ninguna cifra precisa extraída de estas publicaciones. Sin haber verificado minuciosamente la metodología de cada artículo al momento de escribir este artículo, volver a publicar un número aislado reproduciría exactamente el problema que documenta este artículo: un número sin el contexto que nos permitiría saber qué mide realmente.
Lo que aprende esta variación, por otro lado, es directamente útil: un arranque en frío depende en gran medida del contexto de medición, exactamente como lo recuerda la disciplina de paridad de entorno descrita en nuestro artículo de metodología general (hardware idéntico, misma región, mismo estado de caché para todos los sistemas comparados).
Wasmtime, Wasmer, WasmEdge: diferentes prioridades de compilación
Los tres tiempos de ejecución independientes de WebAssembly más citados en este debate no equilibran la velocidad de compilación y el rendimiento de ejecución de la misma manera, lo que explica en parte por qué sus cifras de arranque en frío no se comparan término con término.
| Era hora | Backend de compilación de Cranelift, históricamente con una posible ruta de precompilación antes de la implementación | Utilizado en producción por Aurabase para funciones Edge |
|---|---|---|
| wasmer | Ha documentado durante mucho tiempo varios backends intercambiables, incluido un backend diseñado para la velocidad de compilación en lugar del rendimiento en tiempo de ejecución. | Markets Instaboot, un reinicio por instantánea de una instancia ya inicializada |
| WasmEdge | Posicionamiento público centrado en el inicio rápido, con argumento competitivo propio | El runtime alternativo también está activo en esta área de marketing. |
Estas arquitecturas están documentadas públicamente por los propios proyectos. No los hemos vuelto a verificar versión por versión para este artículo y no constituyen una clasificación de desempeño. Sólo explican por qué tres cifras de arranque en frío mostradas en tres tiempos de ejecución diferentes pueden ser exactas y, sin embargo, no comparables entre sí.
Para conocer los detalles arquitectónicos completos entre los dos tiempos de ejecución que más a menudo se oponen en las discusiones sin servidor, consulte nuestra comparación dedicada Wasmtime vs Wasmer.
Lo que muestra Instaboot y lo que su página de producto por sí sola no prueba
Según el posicionamiento del producto que Wasmer comunica públicamente, Instaboot restaura una instancia ya inicializada mediante un mecanismo de instantánea, en lugar de reiniciar un inicio completo con cada solicitud. Se trata de una verdadera elección arquitectónica coherente con el problema al que se dirige.
Sin embargo, lo que este artículo no hace es repetir una cifra de rendimiento que se muestra en la página del producto Wasmer. Sin saber qué hardware, qué carga de trabajo y qué protocolo de medición produjo esta cifra, volver a publicarla cometería exactamente el error documentado anteriormente: tratar una cifra de marketing como un resultado de referencia independiente.
Una cifra como “arranque en frío en menos de 1 ms” ya ha circulado públicamente, incluso en contenidos anteriores de Aurabase, sin estar respaldada por un punto de referencia reproducible. Ahora se trata internamente como si no tuviera soporte. La misma regla se aplica a cualquier cifra mostrada por un tiempo de ejecución de la competencia, incluido Instaboot, siempre que no la acompañe una metodología desagregada.
Lo que Aurabase puede decir hoy sobre su propio arranque en frío y lo que no puede decir
Aurabase ejecuta sus funciones Edge en Wasmtime en producción, no en un proyecto piloto. Esto es exactamente lo que permite la presentación y dónde termina ese reclamo.
La dependencia se declara hard, con las funcionalidades async y cranelift activadas, en las dependencias de producción del servicio, no en un dev-dependency ni en un comentario:
Lo que no dice este archivo: hoy en día no existen cifras de arranque en frío medidas según el protocolo descrito en nuestra metodología de referencia en el repositorio para este tiempo de ejecución. Hasta que se publique una medición fechada, con percentiles desglosados, hardware y carga de trabajo, no se debe citar ninguna cifra de Aurabase como característica medida del producto. Para conocer la arquitectura general de la plataforma, consulte nuestro artículo principal Arquitectura de Aurabase Rust. Para obtener una comparación concreta entre WASM de arranque en frío y contenedor de arranque en frío, independientemente de la cuestión metodológica abordada aquí, consulte nuestro artículo dedicado WASM vs contenedores.
Cómo leer un número de arranque en frío antes de creerlo
Siete preguntas para hacerle a cualquier cifra de arranque en frío, incluida la nuestra el día que lanzamos una.
- ¿Qué fases están incluidas? Carga de red, validación, compilación, instanciación, primera llamada: una cifra que solo cuenta una parte no es comparable a una cifra que los cuenta todos.
- ¿Estaba realmente “frío” el módulo? Un módulo que ya está en la memoria o en la caché del disco no prueba lo mismo que un módulo cargado por primera vez.
- ¿Compilación JIT o artefacto precompilado (AOT)? Las dos estrategias tienen costos iniciales estructuralmente diferentes.
- ¿Un solo dígito o distribución? No tiene el mismo valor una mejor tirada en diez que un p95 en mil tiradas.
- ¿Equipo y región especificados? Un tercero no puede reproducir una figura sin una especificación de hardware.
- ¿Comparación con igual carga y topología? Comparar un tiempo de ejecución autohospedado con un servicio administrado sin informarlo distorsiona la lectura.
- ¿Fecha y versión del tiempo de ejecución probado? Una cifra sin fecha sobre un proyecto que evoluciona rápidamente no significa nada después de unos meses.
Preguntas frecuentes
Fuentes externas citadas: documentación pública del producto Wasmer (Instaboot), documentación pública del proyecto Wasmtime (Bytecode Alliance), consultadas en la preparación de este artículo, sin una doble verificación independiente de las cifras de rendimiento que muestran.