4dim / Notas
Un temporizador cada minuto, y por qué no cada cinco
La tienda cerraba y una campaña de trescientos contactos se quedaba encolada hasta la mañana, porque lo único que empujaba la cola era el navegador de alguien. Cómo se elige el intervalo mirando qué se rompe por cada lado.
La campaña que esperaba a que alguien abriera el navegador
Si tu sistema tiene una cola de trabajo, esta nota te dice quién debe dispararla y cada cuánto, con el razonamiento completo de por qué un minuto y no cinco. Vale para cualquier cola, no solo para mensajes.
Durante meses, nuestro proceso que saca los mensajes por la puerta tenía un solo disparador: una petición del navegador. Alguien tenía la consola abierta, y eso lo empujaba.
Funciona perfectamente mientras alguien mira. El problema es la noche: la tienda cierra, se apaga el computador, y una campaña de trescientos contactos se queda encolada hasta la mañana siguiente.
Una cola que solo avanza cuando alguien mira no es una cola. Es una lista de cosas pendientes.
Y es un fallo especialmente incómodo porque no da error. Todo está bien guardado, todo saldrá. Solo que a las nueve de la mañana, y el cliente escribió a las once de la noche.
Un minuto, y el razonamiento de los dos lados
La solución es un temporizador del sistema operativo, que corre haya o no haya alguien. La pregunta interesante es cada cuánto.
Y se decide mirando qué se rompe por cada lado:
| Cada cuánto | Qué pasa |
|---|---|
| Cada pocos segundos | El cerrojo hace que la mitad de los pases no haga nada |
| Cada minuto | El grano correcto |
| Cada cinco minutos | Un mensaje encolado justo después espera demasiado |
Por debajo del minuto no se gana nada: hay un cerrojo para que dos pases no salgan a la vez, así que los pases de más se encuentran la puerta cerrada y se van. Trabajo sin resultado.
Por encima, la espera se nota. Un mensaje que se encola justo después de un pase espera el intervalo entero, y cinco minutos es demasiado para algo que el negocio vive como inmediato.
Importante: el camino del navegador sigue existiendo. Quien está delante sigue teniendo la respuesta instantánea. El temporizador no lo sustituye: es la garantía de que sale igual aunque no haya nadie.
El reparto que hay que desactivar
Detalle que sorprende la primera vez y que explica temporizadores que «no corren cuando deben».
Los sistemas operativos modernos, por omisión, reparten los disparos dentro de una ventana. Si tienes veinte tareas programadas al minuto, no las lanza todas a la vez: las esparce, para no despertar la máquina de golpe y ahorrar energía.
Es sensato en un portátil y estorba aquí: nuestro pase es un solo proceso corto y queremos el minuto exacto. Así que se reduce esa ventana a unos segundos.
La lección general: los valores por omisión de tu sistema están pensados para el caso común, que rara vez es el tuyo. Cuando un temporizador parece impreciso, mira si hay un reparto activado antes de buscar el fallo en tu código.
El corte antes del siguiente pase
El pase tiene un plazo máximo: se corta antes de que llegue el siguiente.
La razón no es la elegancia. El proceso ya se aparta solo si otro sigue vivo —ese es el cerrojo—, pero eso no evita que se acumulen. Si uno se queda colgado hablando con Meta, el del minuto siguiente no debe encontrárselo todavía dentro. Y el de después tampoco. Sin corte, una llamada colgada deja una fila de procesos esperando su turno para no hacer nada.
El número sale del intervalo: un poco menos de lo que tarda en volver a dispararse. Así, en el peor caso, siempre hay como mucho uno vivo.
La regla: todo trabajo periódico necesita un plazo máximo menor que su periodo. Si no, el día que algo se cuelgue, el problema no es el cuelgue: es la pila.
Desde dónde corre, que no es obvio
Queda la pieza que rompe estos temporizadores semanas después de montarlos.
El pase necesita correr desde un directorio con las dependencias frescas. Hay tres candidatos y dos están mal:
- El clon del repositorio. Mal: ahí no se instalan las dependencias. Se instalan en la copia que se despliega.
- Una carpeta fija. Mal, si el despliegue alterna entre dos copias para no cortar el servicio. Acierta la mitad de las veces.
- Un enlace que apunta a la que está sirviendo. Bien. El despliegue lo mueve al cambiar, y el temporizador siempre encuentra la copia buena.
El síntoma del segundo caso es precioso y desconcertante: el temporizador funciona, y después de cada despliegue deja de funcionar, y después del siguiente vuelve. Alterna. Nadie sospecha del despliegue porque el despliegue sale bien.
Qué hacer entonces
- Comprueba qué dispara tus colas. Si es una petición del navegador, tu sistema descansa cuando descansa tu cliente.
- Elige el intervalo mirando los dos lados. Por debajo, pases que no hacen nada; por encima, esperas que se notan.
- Deja también el disparo inmediato. El temporizador es la red, no el camino principal.
- Pon un plazo máximo menor que el periodo. Contra la pila, no contra el cuelgue.
- Apunta a la copia viva, no a una fija. Si tu despliegue alterna, una ruta fija acierta la mitad de las veces.
Esta nota sale de nuestro trabajo en Desarrollo de Software a medida.