Log de aplicações (Avaliando as boas opções)

O log pode ajudar, mas cuidado com o excesso

O post “The problem with loggin” explica alguns cuidados para não se exceder ao usar log.

O System.Diagnostics não é suficiente?

No post “Logging best practices” há uma crítica em relação ao excesso de frameworks alternativas de log, que ao invés de preencher os Gaps que faltam no Trace padrão, o reinventam completamente. Um examplo de proposta que preenche os Gaps é o Essential Diagnostics (http://essentialdiagnostics.codeplex.com/)

Quais as outras frameworks?

No post “When should I use Tracing vs Logger.NET, Enterprise Library, log4net or Ukadc.Diagnostics?” estão listadas várias opções de pacotes de Log.

No nuget, olhando a estatística de mais baixados de 6 semanas do dia 30/1/2016 estão:

• log4net (250K de downloads) (https://www.nuget.org/stats/packages/log4net?groupby=Version)
• NLog (150K de downloads) (https://www.nuget.org/stats/packages/NLog?groupby=Version)

No github, o NLog está com mais popularidade:

• NLog tem mais Estrelas, pessoas contribuindo e mais commits recentes (https://github.com/NLog/NLog/graphs/commit-activity)
• log4net vem sofrendo menos contribuições:
  (https://github.com/apache/log4net/graphs/commit-activity)

No post “log4net vs. Nlog”ainda é discutido a percepção de diversos outros desenvolvedores.

Nos próximos posts, vou falar fazer exemplo dos dois pacotes. Tanto o System.Diagnostics, o log4net e o NLog são excelentes opções - mas pensando no que é mais simples de utilizar(e principalmente configurar) eu acabei preferindo o NLog.

Teste unitário com Selenium WebDriver (Simples exemplo com o Chrome e Firefox)

O vídeo(Selenium WebDriver - Install + Hello World with Visual Studio, C#)  é um ótimo passo a passo de como utilizar o Selenium Webdriver com uma aplicação c#.

Para demonstrar, adicionei ao GitHub um simples exemplo de teste unitário fazendo uma busca no Bing utilizando Chrome e Firefox.

As dependências dos projeto foram instaladas com o Nuget utilizando os seguintes comandos:
Install-Package Selenium.WebDriver
(Pacote básico para permitir o Selenium Webdriver e o firefox)

Install-Package Selenium.WebDriver.ChromeDriver
(Pacote para permitir os testes com o Chrome)

O código acontece no método SearchAndNavigateTest, que basicamente abre a url do Bing, busca pela palavra chave "aplicacoesweb selenium" e clica no primeiro link que contiver "aplicacoesweb.blogspot" no atribute href.

Este código é executado no FireFox e no Chrome no teste unitário TestMethod1()

Caching (OutputCacheAttribute e DonutCachingAttribute)

O OutputCacheAttribute, atributo nativo no ASP.NET MVC, permite que façamos cache de resultados de actions para futuras respostas às requisições dos usuários. Há várias opções de configuração e é sugerido de se utilizar esse artifício quando você precisa otimizar o desempenho de sua aplicação.

Otimizar desempenho é uma tarefa que deve ser feita de maneira muito criteriosa. Primeiro é importante você saber qual o problema atual a ser resolvido e as métricas da situação, por exemplo, está consumindo muito processamento determinada action (Atinge 100% de CPU, gasta muita memória e/ou demora muito tempo para retorno ao usuário). Deve-se tomar o cuidado para não aplicar uma solução de cache que poderá resolver os problemas anteriores, mas acabar gerando um outro problema de consumo de memória por manter as informações em cache. Por isso a importância das métricas antes e depois de aplicar a solução.

Decidindo pela aplicação do OutputCacheAttribute é importante ainda saber que ele gera um cache respeitando configurações de variação por action do Controller, por tempo (Duration), por parâmetros de unicidade (VaryByContentEncoding, VaryByCustom, VaryByHeader, VaryByParam) e por local (Client, Downstream, Server). Se for decidido que o cache será no servidor é importante saber que futuras requisições nas condições de unicidade configuradas anteriormente receberá a informação do cache completa, ou seja, se o cache foi criado pela requisição de um usuário com perfil de administrador (que tem mais opções de menu que um usuário comum), todos os usuários ao requisitarem a página em cache irão ver a página como o administrador (com as opções de menu que não deveria ver).

Se você tiver essa situação, para resolvê-la, há a teoria de cache chamada de Donut Hole Caching, que basicamente você pode escolher qual a parte do conteúdo deseja fazer cache e/ou qual deve ser atualizada automaticamente pelo contexto do usuário requisitante, este artigo em inglês explica a teoria de maneira detalhada e lúdica.

Há uma implementação de pacote para utilizar o Donut Hole Caching no pacote Nuget MvcDonutCaching que também tem o fonte disponível no Github. Neste artigo há uma explicação de todas as dificuldades e escolhas feitas para viabilizar a implementação, mas basicamente a grande sacada é que utilizando o pacote, é possível definir ChildActions como dinâmicas para serem carregadas, mesmo quando o resto da página está em cache. Para viabilizar isso o pacote adiciona  comentário HTML para marcar pontos de atualização de parte de conteúdo nas próximas requisições, quando utilizado as extensões @HtmlAction(), @Html.RenderAction() e definindo o parâmetro excludeFromParentCache, conforme código abaixo:

O ActionFilter (DonutOutputCacheAttribute) irá atualizar esses "buracos" no método OnResultExecuted.