Medir el arranque real de un droplet de DigitalOcean: 12 segundos entre active y SSH
Un experimento con 36 droplets en 12 regiones mide cuánto tarda un servidor en aceptar SSH desde que la API lo declara activo, y por qué un sleep fijo no sirve.
Un desarrollador se puso a cronometrar lo que casi todo el mundo resuelve con un sleep. La pregunta era concreta: cuánto tarda de verdad un servidor recién creado en aceptar una conexión SSH. Tras medir 36 droplets de DigitalOcean repartidos en 12 regiones, la respuesta es que entre el momento en que la API declara la instancia activa y el momento en que sshd responde pasan unos 12 segundos de mediana, y hasta 23 en el peor caso observado.
El montaje está acotado: misma talla s-1vcpu-1gb, misma imagen Ubuntu 24.04, tres rondas por región y tres marcas de tiempo por droplet. Cuándo vuelve la llamada POST /v2/droplets (1,75 s de mediana, entre 1,12 y 4,77). Cuándo el sondeo cada dos segundos ve el estado active con una IPv4 pública (34,5 s de mediana). Y cuándo una conexión TCP al puerto 22 recibe el banner SSH (45,1 s). No basta con que el puerto abra: hay que leer los primeros bytes y comprobar que empiezan por SSH-, porque el socket puede aceptar antes de que el demonio hable. Todo se destruyó al terminar y el ejercicio costó céntimos.
La parte que no ves
El hueco entre las dos últimas marcas es el 27% de la espera total. Una cuarta parte del tiempo que pasas esperando un servidor transcurre después de que la API te haya dicho que está listo. Y no es que DigitalOcean vaya lento: 45 segundos desde una petición HTTP hasta una máquina que acepta login es rápido, y la llamada a la API responde por debajo de los dos segundos casi siempre.
Lo raro es que ese hueco no es constante. En Sídney la mediana es de 6,7 segundos; en nyc3, de 20,5. Tres veces más para la misma imagen y la misma talla. Sídney tarda comparativamente más en reportar active y luego termina rápido; nyc3 reporta antes y te hace esperar. O sea, active no significa lo mismo en cada región: es un punto dentro de una secuencia y cada centro de datos lo alcanza en un momento distinto. Un sleep afinado en una región está mal en otra.
El caso de Nueva York es el que más llama la atención. Misma ciudad, mismo tamaño, misma imagen, misma noche: nyc2 tarda 35,0 s, nyc1 45,4 y nyc3 53,7. Elegir una región de Nueva York en un desplegable sin mirar cuesta 19 segundos cada vez que construyes una máquina. Para un servidor suelto da igual; para un job de CI que crea y destruye una flota, se acumula sin que nadie lo atribuya al desplegable.
Qué hacer con el script
La propuesta es dejar de dormir y empezar a sondear. Un sondeo cada dos segundos sobre el banner SSH no cuesta nada y es correcto en cualquier región. Un sleep fijo o se queda corto en ams3 o desperdicia tiempo en nyc2, y no hay valor que sirva para ambos. El puerto tampoco es la señal buena: hay que esperar a que lleguen bytes y que empiecen por SSH-. Y active no es listo, es una señal real y útil, pero indica que el hipervisor ha terminado, no que el huésped esté preparado.
Las salvedades importan. Tres rondas por región son pocas, y el propio autor avisa de que con una sola habría escrito otro artículo. El intervalo de sondeo de dos segundos mete ese margen en cada marca, así que las diferencias de uno o dos segundos no significan nada; las de veinte, sí. Todo se midió desde una máquina en Europa, lo que añade algo de latencia a las regiones lejanas, y con una única imagen, una talla y una noche. Quien repita la prueba el martes que viene debería esperar otras cifras y la misma estructura.
