¿Qué estaba pasando?
El cliente operaba en un servidor multicompañía con más de 80 millones de apuntes contables y múltiples libros contables ejecutándose de forma recurrente. Entre ellos, destacaba el Libro 3.12 – Lib. Inv. y Bal. - Detalle de Saldos Cta. 42 CxP Comerciales - Terceros y Cta. 43 CxP Comerciales - Relacionadas, cuyo procesamiento demandaba un tiempo excesivo debido a la alta volumetría de datos y un código poco optimizado. Como consecuencia, el servidor se llevaba al límite: la CPU superaba más del 70% durante mucho tiempo y el disco mostraba picos constantes de actividad. El impacto era claro: Odoo funcionaba con extrema lentitud, se producían caídas frecuentes del servidor y el equipo de trabajo operaba en un ambiente de incertidumbre. Para el cliente, la generación de estos informes se había convertido en un dolor de cabeza diario.
Lo que hicimos
Etapa 1: diagnostico
Ante la recurrencia del problema, el cliente acudió a nosotros para encontrar una solución. Realizamos un diagnóstico exhaustivo y detectamos:
- Consulta monolítica y costosa: un único query concentraba todo el cálculo, sin particionamiento ni estrategias de reducción.
- Alto consumo de memoria y relecturas: se procesaban grandes volúmenes en memoria, provocando lecturas repetidas.
- Índices desalineados con los filtros reales (compañía/fecha/estado): el plan de ejecución no aprovechaba los índices existentes, forzando escaneos completos.
- Concurrencia descontrolada: ejecuciones simultáneas del mismo libro en la misma compañía, compitiendo por recursos y generando bloqueos y picos de carga.
Etapa 2: Plan de optimizacion
Tras identificar las oportunidades de mejora, diseñamos el siguiente plan de optimizacion:
Base de datos
- Dividimos el trabajo por tipo. En lugar de una “súper consulta” para todo, lo separamos en consultas pequeñas. Así cada parte es más rápida y fácil de controlar.
- Procesamos por lotes, no todo de golpe. Avanzamos en bloques para no saturar la base y mantenerla ágil.
- Atajos para encontrar rápido. Creamos “marcadores” (índices) según cómo de verdad se busca: por compañía, fecha y estado.
Aplicación (Odoo)
- Pedimos solo lo necesario. Traemos a memoria exactamente los campos que se usan y “cargamos por adelantado” lo relacionado para evitar viajes innecesarios.
- Un turno por compañía. Procuramos que se ejecuta un libro por compañia, para asi evitar concurrencias en procesos paralelos.
Operación
- Puesta a punto periódica. Actualizamos las “estadísticas” de la base y ajustamos memoria para que el plan de ejecución sea el óptimo.
Etapa 3: resultados
Finalmente, realizamos pruebas exhaustivas en diferentes periodos y compañias que demostraron una mejora significativa en el rendimiento de los reportes contables:
Pruebas multi-compañias (14 compañías en paralelo):
- Sin transacciones: 27–56 s, prom. 44.21 s.
Rendimiento del servidor:
- Proceso original: CPU sostenida >40% y picos de disco repetitivos.
- Optimizado sin transacciones: CPU pico 6.37% (app 15.9%), lectura máx 12.85 MB/s; escritura 357 KB/s.
- Optimizado con transacciones: CPU pico 17.53% (instante de mayor concurrencia 53.8%), lectura 616 KB/s, escritura 2.92 MB/s.
Recomendaciones
- Procesar en partes siempre es mejor cuando los datos crecen: reduce el consumo de memoria y ofrece mayor control sobre cada etapa.
- Paralelizar con orden: la ejecución en paralelo por compañía es viable, siempre que la arquitectura esté diseñada para evitar conflictos en el uso de recursos.
- Precarga selectiva: traer solo lo necesario disminuye los accesos a la base de datos y reduce el uso de CPU.
- Medirlo todo: sin métricas ni planes de monitoreo, las mejoras parecen cuestión de suerte. La medición constante es la clave para optimizar de forma real y sostenible.
¿Tu informe contable esta lento?
Te hacemos un diagnóstico sin costo y te devolvemos un plan con quick wins