Performance

A performance do Chinaski é desenhada em torno do que a carga de trabalho realmente é: um admin com um punhado de editores e builds em lote periódicos. Esta página cobre as alavancas que você pode girar: paralelismo de build, índices de banco de dados, headers de cache e os knobs certos, ordenados por impacto.

Primeiro: paralelismo de build

Builds são a operação cara, e seu paralelismo é configurável:

A variável de ambiente CHINASKI_JOBS tem a maior precedência.
A configuração build_jobs (Settings) vem em seguida.
Caso contrário, o builder usa a contagem de CPUs.
Os valores são limitados entre 1 e 16; um valor de 1 constrói sequencialmente sem fork: o modo de depuração.

Arquitetura de build paralelo: ondas de renderização por idioma mais ondas por fase (arquivos construídos em conjunto) para que uma máquina totalmente carregada execute builds sequencialmente por pool de workers.

Headers de cache para o lado estático

Os exemplos nginx e Caddy embarcados firmam os tempos de vida do cache para que visitantes tenham visitas repetidas rápidas e conteúdo fresco não seja atrasado:

HTML: revalidação de 5 minutos; a obsolescência do conteúdo é limitada ao ciclo de publicação.
sw.js: no-cache, must-revalidate (novos service workers entram de imediato).
Fontes: caching imutável de um ano.
Outros assets: cache de um dia.

A aplicação define seus próprios headers de segurança; os headers do proxy são cinto-e-suspensório para respostas servidas antes que o app pudesse responder.

Bancos de dados e índices

O banco de dados vem com índices de performance para páginas e posts (ordenação por active/updated, arcos de published+language, o índice de categorias dos posts): aplicados automaticamente quando o app inicia, idempotentes na re-execução. O SQLite roda embutido (sem processo de servidor, sem credenciais) em modo WAL com cache de 64 MiB e busy timeout de 5 segundos. Para a carga esperada: uma sessão de admin ativa, builds em lote periódicos: o SQLite é a escolha certa.

Alavancas de tempo de build

Minificação de HTML está ligada por padrão; desligá-la (settings) troca tamanho de página por velocidade de build (a minificação dirigida por regex é um custo de build mensurável).
Builds incrementais são o padrão para rebuilds disparados pelo admin: páginas inalteradas são reutilizadas em vez de reescritas; um build travado cai para um build completo.
Tempos por fase em cada log de build: fases de topo e contadores das folhas do hot loop (renderização de templates, minificação de HTML, post-queries) são reportados separadamente: não some as duas seções; a saída do verificador mostra para onde o tempo de fato foi.
Histórico de tempos é JSON persistido por build, então análise de tendência pela história do próprio seu site é fácil (o último: consulte o timings_json da linha mais recente de build_log).

O que o projeto mede

O documento de benchmarking embarca um protocolo reprodutível: um DB de fixture semeado com um corpus de 7.000 posts e um build cronometrado (com uma flag definida para execuções de descarte). O baseline documentado atual (três núcleos): corpus de 7.008 artigos construído em ~162,6 s, 9.129 arquivos, 588 MB de saída: com a renderização de templates notoriamente não sendo o gargalo; os custos dominantes são a regex de minificação, as passes de validação de links/acessibilidade e o índice de busca. Use os números para comparar com o seu próprio baseline, em vez de como promessa.

As miudezas

O cache de settings do CMS tem um TTL: leituras repetidas de settings são servidas da memória.
Webhooks são limitados a 8 envios simultâneos, para que um build cheio de webhooks não mate de fome o loop de requisições.
A poda das tabelas de log/auditoria é estrangulada (uma vez a cada ~15 minutos) para que o trabalho de manutenção não tenha picos periódicos.
O build history do admin e o promotion guard executam as checagens de correção no mesmo orçamento de tempo do build: um build com falha não pode travar seu deploy; deploys para a frente, aos alvos SSH/rsync ou S3, são imediatamente o próximo passo.