Optimizar una consulta de multas cara: dónde está el tiempo

Una consulta de multas que tarda invita a adivinar. La primera reacción suele ser agregar un índice, agrandar la instancia o cachear la respuesta, y a veces funciona. El problema es que ninguna de esas medidas se puede evaluar sin saber antes qué proporción del reloj ocupaba cada etapa.

En una consulta de infracciones el tiempo se reparte entre trabajo propio y espera ajena: resolver qué fuentes corresponden, pedirle a cada portal, normalizar lo que vuelve, guardar y serializar. Optimizar la etapa equivocada produce una mejora real de algo que no gobernaba el total.

Llamamos atribución al reparto del tiempo de una consulta de patente entre etapas medibles por separado, con un residuo declarado. Sin ese reparto, cualquier optimización es una apuesta.

Un presupuesto por etapa que cierre

Cada etapa se instrumenta con su propia medición y todas se suman contra el reloj observado desde afuera. Lo que no cierra es el residuo, y el residuo también es un hallazgo: suele esconder espera en cola, obtención de una conexión, negociación de transporte o el armado del listado de actas.

Una forma posible del registro interno:

{
  "consultaId": "qry_7f2...",
  "totalSegundos": 8.4,
  "etapas": {
    "cola": 0.2,
    "resolucion": 0.1,
    "fuentes": 7.4,
    "normalizacion": 0.3,
    "persistencia": 0.2
  },
  "residuo": 0.2
}

Los valores son un ejemplo de forma, no una medición de nuestros portales. Lo que importa es que las etapas estén definidas antes de mirar el número y que ninguna quede fuera del presupuesto por comodidad.

Esperar no es lo mismo que trabajar

Conviene separar el tiempo de cómputo propio del tiempo de espera. Una etapa que pasa la mayor parte esperando a un portal provincial no mejora con una máquina más grande ni con una consulta mejor escrita: mejora con concurrencia, con menos llamadas o con un contrato distinto.

Los reintentos viven dentro de la etapa y la distorsionan. Una jurisdicción que “tarda ocho segundos” puede ser dos intentos fallidos más una espera antes del tercero. Si el reintento no se mide aparte, el diagnóstico apunta a lentitud cuando el problema es fragilidad.

Tampoco conviene confundir el corte de la espera con el fin del trabajo: cortar del lado del cliente no cancela por sí solo lo que sigue corriendo del otro lado, como desarrolla timeout del cliente y trabajo del servidor.

El promedio esconde justamente la consulta cara

La consulta que duele es la de la cola —la patente con seis jurisdicciones—, y un promedio la disuelve. La especificación del SDK de métricas de OpenTelemetry contempla la agregación por histograma con límites de bucket configurables, que es la forma de conservar esa cola sin guardar cada medición.

Las recomendaciones de nombres de Prometheus empujan en la misma dirección: unidades base —segundos— y el nombre declarando la unidad, para que dos tableros no comparen milisegundos con segundos sin darse cuenta.

Cuando la consulta abre varias fuentes en paralelo, el total no es el promedio de las ramas sino la más lenta de esa ejecución. Por eso hace falta medir por etapa y por jurisdicción: un percentil alto del total puede convivir con buenos percentiles individuales.

Correlacionar sin volver a exponer datos

Para juntar las etapas de una misma consulta cuando atraviesan procesos distintos hace falta propagar un identificador. La recomendación W3C Trace Context define campos de cabecera para llevar ese contexto entre sistemas sin que cada servicio invente el suyo.

Ese identificador debe ser opaco. Patente, CUIT o número de acta no son etiquetas de métrica ni nombres de tramo, entre otras razones porque la documentación de seguridad de OpenTelemetry advierte que la telemetría puede contener datos sensibles y merece los mismos cuidados que el dato original. El criterio completo está en trazas y métricas sin patentes ni CUIT.

Qué se optimiza cuando ya se sabe dónde está el tiempo

Con la atribución a la vista, las opciones se ordenan solas:

• paralelizar el abanico de fuentes con un límite de concurrencia, cuando domina la espera;
• eliminar trabajo repetido, como pedir dos veces la misma jurisdicción dentro de un lote;
• sacar del camino crítico lo que no condiciona la respuesta, como persistencia diferida o exportaciones;
• devolver un resultado parcial en lugar de esperar a la fuente más lenta;
• cachear sólo aquello que puede cachearse sin mezclar identidades.

Hay una opción más que no baja el total pero cambia lo que percibe el cliente: aceptar el trabajo y exponer su estado, con las condiciones que describe consultas largas en una API.

Qué verificar antes de tocar código

Revisá que la medición sea por etapa y reconcilie con el reloj de afuera; que sea una distribución y no un promedio; que la muestra venga de un barrido real y no de una patente suelta; que el cambio se vuelva a medir con el mismo instrumento y la misma ventana.

Optimizar sin atribución no es optimizar. Es cambiar código y esperar que el número baje.

Preguntas frecuentes

¿Conviene agregar un índice cuando una consulta tarda demasiado?

Sólo si la atribución muestra que la etapa dominante es una lectura propia. Si el reloj se va esperando a un portal externo, un índice mejora una etapa que no gobernaba el total y el tiempo percibido queda casi igual.

¿Por qué el percentil alto del total no coincide con el de ninguna fuente?

Porque cuando varias fuentes se consultan en paralelo el total lo fija la rama más lenta de cada consulta, y esa rama cambia. Basta que una sola fuente caiga en su cola para arrastrar el total, aunque todas tengan buenos percentiles por separado.

¿Alcanza con medir desde el cliente?

El reloj del cliente es el que importa para la experiencia, pero no dice en qué etapa se fue el tiempo. Hace falta atribución interna, y los dos relojes no coinciden: red, cola y serialización viven entre uno y otro.

¿Paralelizar siempre baja el tiempo total?

No. Si la etapa dominante es trabajo propio o si la fuente externa impone un ritmo, más concurrencia agrega presión sin acortar el reloj y puede provocar rechazos que terminan sumando reintentos.

Notas relacionadas