Rendimiento

El rendimiento de Chinaski está diseñado en torno a lo que la carga de trabajo realmente es: un admin con un puñado de editores y builds por lotes periódicos. Esta página cubre las palancas que puedes girar: paralelismo de build, índices de base de datos, cabeceras de caché, y las perillas correctas ordenadas por impacto.

Primero: paralelismo de build

Los builds son la operación costosa, y su paralelismo es configurable:

• La variable de entorno CHINASKI_JOBS tiene la máxima precedencia.
• La setting build_jobs (Settings) va a continuación.
• De lo contrario, el builder usa la cantidad de CPUs que tengas.
• Los valores se limitan entre 1 y 16; un valor de 1 compila secuencialmente sin hacer fork: el modo de depuración.

Arquitectura de build paralelo: olas de renderizado por idioma más olas por fase (los archivos se construyen juntos) para que una máquina completamente cargada ejecute los builds secuencialmente por pool de workers.

Cabeceras de caché para el lado estático

Los ejemplos de nginx y Caddy incluidos fijan los tiempos de vida de la caché para que los visitantes tengan visitas repetidas rápidas y el contenido fresco no se demore:

• HTML: revalidación de 5 minutos; la obsolescencia del contenido queda acotada al ciclo de publicación.
• sw.js: no-cache, must-revalidate (los service workers nuevos se publican de inmediato).
• Fuentes: caché inmutable de un año.
• Otros assets: caché de un día.

La aplicación establece sus propias cabeceras de seguridad; las cabeceras del proxy son una doble red de seguridad para las respuestas servidas antes de que la app pudiera responder.

Bases de datos e índices

La base de datos viene con índices de rendimiento en pages y posts (ordenamiento por active/updated, arcos published+idioma, el índice de categoría de los posts), aplicados automáticamente al arrancar la app, idempotentes al reejecutarse. SQLite corre embebido (sin proceso de servidor, sin credenciales) en modo WAL con una caché de 64 MiB y un busy timeout de 5 segundos. Para la carga de trabajo esperada: una sesión de admin activa, builds por lotes periódicos, SQLite es la elección correcta.

Palancas del tiempo de build

• La minificación de HTML está activada por defecto; desactivarla (settings) cambia tamaño de página por velocidad de build (la minificación basada en regex tiene un costo de build medible).
• Los builds incrementales son el comportamiento por defecto para las recompilaciones disparadas desde el admin: las páginas sin cambios se reutilizan en lugar de reescribirse; un build estancado recurre a un build completo.
• Los tiempos por fase en cada build log: las fases de nivel superior y los contadores de hoja de los bucles críticos (renderizado de templates, minificación de HTML, post-queries) se reportan por separado; no sumes las dos secciones; la salida del verificador muestra dónde se fue realmente el tiempo.
• El historial de tiempos se persiste como JSON por build, así que el análisis de tendencias sobre el historial de tu propio site es fácil (el último: consulta el timings_json de la fila más reciente de build_log).

Qué mide el proyecto

El documento de benchmarking incluye un protocolo reproducible: una DB de prueba sembrada con un corpus de 7,000 posts y un build cronometrado (con un flag activado para corridas de prueba). El baseline documentado actual (tres núcleos): corpus de 7,008 artículos construido en ~162.6 s, 9,129 archivos, 588 MB de salida, con el renderizado de templates notablemente sin ser el cuello de botella; los costos dominantes son el regex de minificación, los pases de validación de enlaces/accesibilidad y el índice de búsqueda. Usa los números para comparar tu propio baseline en lugar de tomarlos como promesa.

Las cosas pequeñas

• La caché de settings en el CMS tiene un TTL: las lecturas repetidas de settings se sirven desde memoria.
• Los webhooks están limitados a 8 envíos concurrentes, así que un build con muchos webhooks no deja sin recursos al loop de peticiones.
• La poda de las tablas de log/auditoría está regulada (una vez cada ~15 minutos) para que el trabajo de mantenimiento no tenga picos periódicos.
• El historial de builds del admin y el guard de promoción ejecutan verificaciones de corrección dentro del mismo presupuesto de tiempo que el build; un build fallido no puede colgar tu deploy; los deploys hacia los destinos SSH/rsync o S3 son inmediatamente el siguiente paso.