El equipo de YDB, base de datos distribuida escrita en C++, detectó que su cliente del benchmark TPC-C consumía más recursos que la propia base de datos que pretendía evaluar. En una ejecución con 15.000 almacenes, el cliente basado en Java y BenchBase requería 150.000 hilos del sistema operativo, unos 600 GiB de RAM y cinco máquinas cliente de 128 núcleos y 512 GiB cada una, frente a las tres máquinas del clúster YDB bajo prueba, con un coste estimado de unos 10.000 dólares por experimento en AWS.
La primera optimización, sustituir hilos de plataforma por hilos virtuales de Java 21, redujo la memoria a unos 90 GiB pero provocó interbloqueos y seguía siendo demasiado pesada para los desarrolladores de YDB, que decidieron reescribir el cliente en C++20 con corutinas. El modelo de TPC-C encaja de forma natural con este paradigma: cada terminal ejecuta una transacción secuencial con 5–10 peticiones a la base de datos separadas por tiempos de espera que simulan la actividad humana, de modo que la mayor parte del tiempo permanece suspendida.
El artículo muestra el código síncrono ideal (un bucle por terminal con llamadas bloqueantes) y explica por qué no escala a cientos de miles de terminales: cada hilo necesita pila, recursos de kernel y paga el coste de la conmutación de contexto. Un micromicrobenchmark comparando hilos del sistema con corutinas sin pila en una máquina de 32 núcleos demuestra que, por encima del número de núcleos físicos, las corutinas mantienen un rendimiento agregado casi constante, mientras que el de los hilos cae en picado y el tiempo total se dispara por la creación, planificación y destrucción de los hilos.
YDB concluye que las corutinas de C++20 permiten recuperar un código secuencial legible y depurable, a la vez que escalan a terminales simultáneas con un consumo de memoria y CPU muy inferiores, dejando la generación de carga fuera del cuello de botella del banco de pruebas.