Análise de Performance

Ciclo de Crash

O site entra num ciclo vicioso de crashes que se repete a cada 1-2 dias. O diagrama seguinte ilustra este ciclo:

flowchart TD
    A["Site sem trafego durante ~20 min"] -->|Always On desativado| B["Azure descarrega a aplicacao"]
    B --> C["Utilizador acede ao site"]
    C --> D["Cold Start: Umbraco reinicia"]
    D --> E["Umbraco reconstroi XML cache a partir da BD"]
    E --> F["BD tem ~1.2M linhas em cmsPropertyData\n+ ~8M registos em icUrlTracker"]
    F --> G["Reconstrucao da cache demora muitos minutos"]
    G --> H["Site parece bloqueado/em baixo"]
    H --> I["Administrador reinicia o App Service"]
    I --> J["Site funciona normalmente"]
    J --> K["1-2 dias depois, memoria esgota-se"]
    K --> A

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style G fill:#ff6b6b,color:#fff
    style H fill:#ff6b6b,color:#fff
    style K fill:#ff6b6b,color:#fff

---

Pressão de Memória

O Umbraco precisa de manter em memória a cache XML de todos os conteúdos publicados, o que cria pressão significativa sobre a memória disponível.

pie title "Distribuicao Estimada de Memoria"
    "Umbraco XML Cache" : 45
    "Property Data (~1.2M linhas)" : 25
    "Runtime .NET + IIS" : 15
    "Donut Cache + Sessoes" : 10
    "Outros (Hangfire, APIs)" : 5

Detalhes da Pressão de Memória

Componente	Impacto na Memória	Notas
Umbraco XML Cache	Elevado	Cache completa de 11.503 nós de conteúdo
cmsPropertyData	Elevado	1.220.959 linhas (~358 MB na BD, mais em memória)
Donut Caching	Médio	Camada adicional de cache sobre a cache do Umbraco
ContentApiController	Médio	Chamado em CADA navegação de página

---

Fluxo de um Pedido de Página

sequenceDiagram
    participant U as Utilizador
    participant IIS as IIS/App Service
    participant DC as Donut Cache
    participant API as ContentApiController
    participant UC as Umbraco Cache
    participant DB as SQL Database

    U->>IIS: GET /pagina
    IIS->>DC: Verificar Donut Cache

    alt Cache hit
        DC-->>U: Resposta imediata
    else Cache miss
        DC->>API: ContentApiController
        API->>UC: Pedir conteudo da cache Umbraco

        alt Cache XML pronta
            UC-->>API: Dados do conteudo
        else Cache em reconstrucao (cold start)
            UC->>DB: SELECT * FROM cmsPropertyData...
            Note over DB: ~1.2M linhas para processar
            UC->>DB: Verificar icUrlTracker
            Note over DB: ~8M registos para carregar
            DB-->>UC: Dados (demora minutos)
            UC-->>API: Dados do conteudo
        end

        API-->>DC: Resposta
        DC-->>U: Resposta (apos espera longa)
    end

Problema do ContentApiController

O ContentApiController é invocado em cada navegação de página pelo frontend AngularJS. Este controller depende da cache do Umbraco estar disponível. Quando a cache não está pronta (durante um cold start), cada pedido de página fica bloqueado à espera que a cache seja reconstruída.

---

Hangfire Desativado

O Hangfire (sistema de tarefas em background) foi desativado propositadamente devido a problemas de memória. Isto confirma que a equipa já tinha conhecimento de que a memória era um problema, mas a causa raiz (excesso de dados na BD) não foi resolvida.

flowchart LR
    A["Hangfire ativo"] --> B["Consumo adicional de memoria"]
    B --> C["Crashes mais frequentes"]
    C --> D["Hangfire desativado como workaround"]
    D --> E["Problema de memoria persiste"]
    E --> F["Causa raiz: BD sobrecarregada"]

    style D fill:#ffa500,color:#fff
    style F fill:#ff6b6b,color:#fff

---

Métricas-Chave

Métrica	Valor Atual	Valor Normal
Nós de conteúdo	11.503	-
Linhas em cmsPropertyData	1.220.959	~30.000-50.000
Registos em icUrlTracker	7.996.535	< 10.000
Versões de conteúdo	77.923	< 10.000
Application Insights	Desativado	Ativo com alertas
Always On	Desativado	Ativado
Frequência de crashes	A cada 1-2 dias	Nunca