Relatório de Intervenção — Ambiente Local (Docker)#
Resumo
Limpeza completa validada localmente em duas fases. Base de dados reduzida de 6.5 GB para 2.0 GB (−69%), consultas representativas 5.6× mais rápidas (4.4 s → 0.78 s), funcionalidades de criação de redireccionamentos e de reversão a versões anteriores de conteúdos totalmente operacionais. Validação automatizada percorrendo 552 páginas confirma zero regressões funcionais.
1. Resumo Executivo#
| Métrica | Estado Inicial | Após Fase 1 | Após Fase 2 (Final) | Variação Total |
|---|---|---|---|---|
| Tamanho da base de dados | 6 492 MB | 2 088 MB | 2 028 MB | −68.8% |
| Registo de URLs (linhas) | 8 156 835 | 1 914 | 1 971 | −99.98% |
| Propriedades de conteúdos | 1 221 476 | 118 460 | 56 473 | −95.4% |
| Versões de conteúdos | 78 017 | 18 634 | 8 776 | −88.8% |
| Pré-cálculo de versões publicadas | 69 218 | 10 474 | 7 156 | −89.7% |
| Logs aplicacionais | 1 979 595 | 125 351 | 125 351 | −93.7% |
| Tempo médio de consultas | 4 400 ms | 1 547 ms | 784 ms | −82.2% |
Sobre a Fase 2
Após validação interna da Fase 1, executou-se uma segunda fase de limpeza que elimina: conteúdos na reciclagem (3 626 conteúdos + 544 ficheiros de media), conteúdos nunca publicados com mais de 1 ano (378 nós), e ficheiros de media sem qualquer referência detectada (1 198 nós). Esta fase removeu mais 113 788 registos. Cumulativamente, a base de dados ficou 3.2× mais pequena que o estado original.
2. Detalhe da Limpeza#
Fase 1 — Limpeza standard#
| # | Operação | Registos eliminados |
|---|---|---|
| 1 | Eliminar logs de URLs inexistentes (404) | 8 154 951 |
| 2 | Eliminar propriedades de versões antigas | 1 103 016 |
| 3 | Eliminar pré-cálculos de versões antigas | 58 744 |
| 4 | Manter apenas as 2 versões mais recentes por conteúdo | 59 383 |
| 5 | Eliminar logs aplicacionais com mais de 3 meses | 1 931 861 |
| 6 | Reconstrução de índices | — |
| Total Fase 1 | 11 307 955 |
Fase 2 — Limpeza profunda#
| # | Operação | Registos eliminados |
|---|---|---|
| 7 | Esvaziar reciclagem de conteúdos (3 626 nós + propriedades) | 89 738 |
| 8 | Esvaziar reciclagem de media (544 nós + propriedades) | 3 599 |
| 9 | Eliminar conteúdos nunca publicados com >1 ano (378 nós) | 11 393 |
| 10 | Eliminar landing pages que servem apenas redireccionamento | 0 (critério estrito; lista a refinar pela equipa UNICEF) |
| 11 | Eliminar ficheiros de media sem qualquer referência (1 198 nós) | 9 058 |
| 12 | Reconstrução final de índices | — |
| Total Fase 2 | 113 788 |
A ordem de execução respeita a integridade referencial entre tabelas (eliminação primeiro dos registos dependentes, depois dos registos principais).
3. Tempo Médio de Consultas#
Medição executada com cache da base de dados limpa antes de cada execução, para medir o caso pior. 5 execuções, valor médio.
| Execução | Estado Inicial | Após Fase 1 | Após Fase 2 |
|---|---|---|---|
| 1 (cache fria) | 9 393 ms | 3 505 ms | 1 043 ms |
| 2 | 3 048 ms | 795 ms | 736 ms |
| 3 | 3 379 ms | 1 026 ms | 714 ms |
| 4 | 3 161 ms | 1 275 ms | 709 ms |
| 5 | 3 020 ms | 1 134 ms | 717 ms |
| Média | 4 400 ms | 1 547 ms | 784 ms |
| Variação vs original | — | −65% | −82% |
4. Tempos de Carregamento de Página (Browser)#
5 execuções por página, valor médio.
| Página | Estado Inicial | Após Fase 1 | Após Fase 2 |
|---|---|---|---|
/ (página inicial) |
1 044 ms | 1 123 ms | 1 092 ms |
/unicef/ |
411 ms | 664 ms | 530 ms |
/o-que-fazemos/ |
746 ms | 749 ms | 720 ms |
/como-ajudar/ |
569 ms | 568 ms | 593 ms |
/como-ajudar/donativos-unicef/ |
599 ms | 730 ms | 627 ms |
/como-ajudar/consignacao-irs-2026/ |
1 025 ms | 1 033 ms | 1 013 ms |
/pessoas/ |
832 ms | 794 ms | 677 ms |
/atualidade/ |
570 ms | 695 ms | 607 ms |
/pesquisa/?q=criancas |
915 ms | 1 071 ms | 1 019 ms |
Por que os tempos locais são equivalentes
No ambiente local, a base de dados corre na mesma máquina que o servidor web (latência de rede nula, disco SSD rápido). Nestas condições, a base de dados não é o factor limitador do desempenho — o tempo de resposta é dominado por outros componentes (compilação inicial do .NET e do motor de templates do Umbraco). Em Produção, onde o servidor de base de dados é um serviço Azure remoto, é a base de dados que domina o tempo de resposta, e a redução de 82% no tempo de consultas traduz-se directamente em ganhos visíveis para os utilizadores. Esta interpretação é confirmada pelos resultados em Qualidade, onde o tempo de consultas baixou de 179 segundos para 0.9 segundos (−99.5%).
Cold start (primeira navegação após reinício do servidor)#
| Estado | Cold start estável |
|---|---|
| Estado Inicial | 24.8 s |
| Após Fase 1 | 24.7 s |
| Após Fase 2 | 20.8 s |
Nos primeiros 2-3 reinícios após a limpeza, o tempo é mais alto (45-56 s) devido à reconstrução automática dos índices de pesquisa do Umbraco. Após estabilização, o cold start é igual ou ligeiramente mais rápido que o estado inicial.
5. Validação de Funcionalidades — Backoffice#
Operações reais cronometradas no backoffice após a limpeza.
| Operação | Tempo |
|---|---|
| Carregamento da página de login | 267 ms |
| Login (autenticação + redireccionamento) | 929 ms |
| Navegação para a secção de Conteúdos | 8 ms |
| Navegação para a secção de Redireccionamentos | ~3 s |
| Navegação para a Reciclagem | ~3 s |
| Criação de um novo redireccionamento | 50 ms |
| Consulta de um redireccionamento existente | 11 ms |
Criação de Redireccionamentos#
A funcionalidade de criação de redireccionamentos no backoffice estava inutilizável antes da limpeza, devido aos timeouts causados pela tabela com 8 milhões de registos. Após a limpeza, a operação demora 50 ms — está plenamente operacional.
Reversão a Versões Anteriores#
Após a limpeza, mantêm-se as 2 versões mais recentes de cada conteúdo (versão actual + versão imediatamente anterior). A funcionalidade de reverter um conteúdo a uma versão anterior no backoffice está disponível e responsiva. Antes da limpeza, alguns conteúdos tinham 30 a 100+ versões acumuladas, o que tornava a interface tão lenta que a operação era impraticável.
6. Validação Automatizada de Páginas#
A validação percorrendo todas as 552 páginas listadas no sitemap.xml foi executada antes e depois da limpeza, para detectar regressões funcionais.
| Métrica | Estado Inicial | Após Fase 2 |
|---|---|---|
| Total de respostas com erro | 34 | 32 |
| URLs únicos com problema | 20 | 17 |
| Páginas com erro de servidor (500) | 1 | 1 |
| Páginas com erro de navegação | 6 | 3 |
3 páginas com problema desapareceram após a Fase 2 — eram publicações antigas nunca publicadas que a limpeza eliminou. Detalhe completo das URLs identificadas em Validação de URLs.
Zero regressões funcionais — nenhuma página que respondia correctamente antes da limpeza deixou de responder.
7. Limpeza de Ficheiros Físicos (Storage)#
A limpeza da base de dados eliminou 1 198 referências a ficheiros de media órfãos (sem qualquer associação a conteúdo). Os ficheiros físicos correspondentes em disco ou no Storage Account não são automaticamente afectados pela limpeza da base de dados e devem ser tratados separadamente, numa operação posterior à validação completa.
A lógica é a mesma em ambos os ambientes: enumerar os ficheiros de media existentes em disco/storage e eliminar aqueles cujo identificador já não existe na base de dados.
8. Estratégia para Produção#
A abordagem aprovada para Produção evita executar scripts directamente nesse ambiente. Em vez disso, a base de dados de Produção é substituída pela base de dados já limpa de Qualidade, numa operação atómica de restauro:
- Pedido de congelamento de conteúdos à UNICEF (sem alterações editoriais durante a janela de manutenção)
- Refrescar Qualidade com cópia fresca de Produção (já validado neste relatório)
- Re-executar limpeza em Qualidade (já validado neste relatório)
- Validação funcional em Qualidade pela UNICEF (a executar)
- Cópia de segurança completa de Produção (cópia automática Azure + cópia adicional para armazenamento de segurança)
- Substituir base de dados de Produção pela base de dados já limpa de Qualidade — operação atómica de restauro
- Reinício do App Service de Produção + validação funcional + monitorização 72 horas
Vantagens desta abordagem:
- Zero scripts a correr em Produção — apenas restauro de cópia já validada
- Tempo de indisponibilidade mínimo
- Sem risco de execução parcial — a operação completa com sucesso ou é totalmente revertida automaticamente
- Plano de recuperação preparado — em caso de qualquer problema, a base de dados pode ser restaurada ao seu estado em qualquer momento dos últimos 14 dias