Performance e Escalabilidade de Aplicações ASP.NET e Azure

No TDC 2015 em São Paulo, assisti essa palestra bem interessante.

No Brasil o cenário e as necessidades de performance em aplicações Web crescem o tempo todo… nossas aplicações são consumidas cada vez mais por dispositivos móveis com conexão e recurso limitados e os usuários exigem performance! além disso, escalar a infraestrutura é essencial para suportar o crescimento dos negócios. Nesta palestra demostrarei como trabalhar com ASP.NET e Azure para criar soluções de grande performance e escala.

A palestra foi dada por Alexandre Tarifa, do Grupo Minha Vida. Fazem parte do grupo Minha Vida, o Dieta e Saúde, maior programa de emagrecimento online do Brasil, o Minha Vida, maior portal de saúde e bem-estar do Brasil, o TecnoNutri, ferramenta de alimentação saudável, e o Consulte.me, serviço de busca de profissionais de saúde.

A palestra começou legal sobre um ponto bem importante. Devido ao grande número de pessoas com dispositivos Android, hoje todo desenvolvedor web é um desenvolvedor Android. Legal!!!

Mas o tema da palestra foi sobre cache. Como e onde usar cache ao invés de consultas diretamente no banco de dados. O Grupo Minha Vida utiliza cache massivamente. Todos os acessos utilizam 2 níveis de cache um na API com dados em memória e outra com um cache no Azure compartilhado em todas as APIs. Com isso o acesso a disco diminui drasticamente.

O mesmo processo é utilizado por grandes portais, como o Facebook. A infraestrutura de dados persistidos não aguente a carga, ele funciona com cache.

Bombando no Cache

Controle de cache para elementos estáticos é muito recomendado.

Estava fuçando nestas configurações no IIS e encontrei a configuração <ClientCache>. Ela pode ser utilizando tanto no web.config quando via Gerenciamento do IIS.

Via web.config é:

<system.webServer>
    ...
    <staticContent>
        <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
    </staticContent>
    ...
</system.webServer>

Onde se define a forma do cache-control e o tempo de duração.

Já no Gerenciamento do IIS é feito via “HTTP Response Header” e aplicar as mesmas configurações.

Mais informações na página do IIS Client Cache.

Cache perdidão

Esta semana me deparei com o seguinte problema. Estou usando ASP.NET Web API para uma determinada aplicação. E dois sites diferentes que consomem está Web API.

A Web API fornece os dados com cache-control habilitado para público. O problema que está acontecendo é que quando o primeiro site solicita uma URL os dados são armazenados no cache do browser, já quando o segundo solicita a mesma URL acontece problema de CORS.

Já que requisição que ficou armazenada em cache é para outra Origin o segundo site não consegue carrega-lá.

Depois de tentar algumas coisas, o @elemarjr me comentou que ascrecentar o header Vary no response deveria resolver o problema. Segundo a especificação (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44) este cabeçalho é utilizado para indicar ao cache acrescentar outras Headers na comparação.

Muito bom, funcionou perfeitamente.