Scale, una empresa de evaluación de infraestructura en la nube, pospuso la publicación de los resultados de su "Scale Invitational" del 8 al 17 de junio tras descubrir, durante el diseño de la prueba, problemas de fondo que invalidaban sus primeras mediciones. El benchmark busca comparar proveedores de sandboxes (entornos aislados de ejecución) cuando una aplicación debe levantar decenas de miles a la vez.
La primera versión (v1) ejecutaba 10.000 iteraciones desde una sola máquina virtual. Los resultados medían más los límites del propio banco de pruebas que el rendimiento del proveedor, ya que un único host comparte pila de red, bucle de eventos e IP de salida. Lección uno: a gran escala, el banco de pruebas se vuelve parte del experimento.
Para corregirlo, el equipo pasó a fragmentación (sharding): cada ráfaga lógica se reparte entre muchas VM, cada una ejecuta una porción del total y un coordinador lleva metadatos del fragmento para reensamblar los resultados. Tras iterar, fijaron unas 100 iteraciones por fragmento, un punto que mantiene cada VM por debajo de sus límites de recursos y reduce la flota a unos 1.000 fragmentos para 100.000 sandboxes.
El hallazgo más relevante fue conceptual: la prueba original medía rendimiento de creación secuencial rápida, no concurrencia real. Si los sandboxes se crean y se destruyen de inmediato, no se comprueba si el proveedor puede mantener 100.000 activos al mismo tiempo. Son preguntas distintas que estresan partes diferentes: planificación y admisión frente a capacidad sostenida, presión de memoria y reclamación.
Para medir concurrencia verdadera, los sandboxes deben permanecer vivos hasta que toda la ejecución alcance su pico y destruirse coordinadamente. El modelo de resultados distingue ahora cuatro estados: éxito, parcial (creado e interactivo pero muerto antes del teardown, categoría imposible de detectar en pruebas de concurrencia implícita), fallo de preparación y fallo de creación. El bucket "parcial" revela proveedores que crean bien pero no sostienen la carga.
El equipo incorporó agregación de logs en el coordinador, enviando la salida a Tigris (almacenamiento de objetos) en lugar de depender del disco efímero, e implementó un pipeline de datos con dos almacenes: Tigris para datos en frío y ClickHouse para analítica, conservando los registros brutos para reconstruir el modelo estructurado si fuera necesario.