Metodologia#
Este capítulo descreve o processo utilizado para recolher as métricas apresentadas neste relatório, garantindo a transparência e a possibilidade de replicação dos resultados pela equipa UNICEF a qualquer momento.
Princípio#
Para garantir uma comparação justa entre o estado anterior e posterior à intervenção, cada ambiente é avaliado em dois momentos distintos com exactamente a mesma bateria de testes, executada no mesmo equipamento e em condições equivalentes:
- Estado inicial — antes de qualquer alteração à base de dados ou aos ficheiros, capturando o desempenho actual da plataforma.
- Estado final — após a execução completa da limpeza, capturando o desempenho resultante.
Os dois momentos são depois comparados directamente, lado a lado, em cada métrica.
O foco está nas proporções de melhoria. Os valores absolutos diferem entre ambientes (hardware, latência de rede, configuração do App Service são distintos entre ambiente local, Qualidade e Produção), mas a percentagem de ganho observada é representativa do impacto esperado em Produção.
Métricas Recolhidas#
Base de dados#
| Métrica | Descrição |
|---|---|
| Tamanho da BD (MB) | Espaço total ocupado pela base de dados em disco |
| Número de registos por tabela | Quantidade de linhas em cada tabela afectada pela limpeza |
| Tamanho por tabela (MB) | Espaço ocupado por tabela individualmente |
| Fragmentação dos índices (%) | Indicador de saúde física dos índices |
| Tempo médio de consultas representativas | Média de 5 execuções de um conjunto fixo de consultas SQL |
As 5 consultas representativas simulam operações reais que o sistema executa frequentemente:
- Resolução de URL para servir uma página (com gestor de redireccionamentos)
- Obtenção da última versão de um conteúdo Umbraco
- Carregamento das propriedades de um conteúdo (página completa)
- Consulta dos registos mais recentes da tabela de logs
- Consulta da árvore de conteúdos no backoffice
Aplicação (browser)#
A captura é feita com o framework Playwright sobre Chromium, num conjunto fixo de páginas representativas. As métricas recolhidas para cada página seguem o standard de performance da W3C:
| Métrica | Significado |
|---|---|
| Cold start | Tempo total da primeira navegação após reinício do servidor (utilizador "frio") |
| TTFB (Time To First Byte) | Tempo até o servidor enviar o primeiro byte de resposta |
| Load | Tempo total até a página estar completamente carregada |
| FCP (First Contentful Paint) | Tempo até o utilizador ver o primeiro conteúdo visível |
| LCP (Largest Contentful Paint) | Tempo até o conteúdo principal estar visível (métrica oficial Google Core Web Vitals) |
Cada página é medida 5 vezes e o valor apresentado nos relatórios é a média.
Páginas testadas#
A validação automatizada percorre as 552 páginas listadas no sitemap.xml da plataforma. Para o conjunto de métricas detalhadas (tempos de carregamento), foi seleccionado um sub-conjunto representativo: página inicial, donativos, IRS, escolas, pessoas, actualidade, e a pesquisa.
Pré-condições controladas#
Para garantir comparações justas entre o estado anterior e posterior à intervenção:
- Ambiente Local: o servidor IIS Express é reiniciado antes do primeiro teste de cada série, garantindo a medição de um cold start real.
- Ambientes Azure (Qualidade e Produção): o App Service é reiniciado antes do primeiro teste posterior à intervenção. A medição anterior é feita durante uso normal, sem qualquer impacto.
- Cache da base de dados: em ambiente local é limpa antes de cada consulta para medir o caso pior. Em Azure SQL não é possível limpar a cache, pelo que as medições reflectem condições de cache normais — comparação válida porque o estado é o mesmo antes e depois.
- Browser: Playwright corre em modo headless (sem interface gráfica), simulando um utilizador real.
Notas importantes para a interpretação dos resultados#
- Ambiente Local não é equivalente a Produção. Hardware, configuração do servidor e versão do SQL Server diferem. Os valores absolutos medidos em ambiente local não são previsão directa dos valores em Produção.
- Proporções são representativas. Se em Qualidade observamos uma redução de 99% no tempo de consultas, é razoável esperar uma melhoria significativa na mesma ordem de grandeza em Produção, dado que ambos correm em Azure SQL com configuração equivalente.
- A medição em Qualidade é a referência mais fiável para o impacto esperado em Produção, por correr em Azure SQL com dados copiados directamente da Produção.