Tive a felicidade de participar pela terceira vez do Visual Studio Summit, evento sobre tecnologias Microsoft.
Nesta última participação palestrei sobre Profiling de Aplicações .NET.
Aqui existe um link para o evento Visual Studio Summit 2014.
Mais detalhes sobre o uso de profiling podem ser encontrados neste link: Profiling de Aplicações .NET
Mesmo com o melhor desempenho e os melhores profissionais, problemas relacionados a performance podem surgir. Fazer com que uma aplicação execute de forma performática pode parecer uma tarefa fácil, mas isso pode se tornar uma arte oculta.
Ferramentas de profiling monitoram a execução de uma aplicação com o objetivo de medir os recursos computacionais (tempo, processamento e memória) gastos por um método por toda a sua execução. Seu objetivo é identificar pontos na aplicação que causem problemas em sua execução.
O profiling de aplicações .NET é mais complexo do que aplicações em código de máquina, pois o .NET faz uso de recursos como Application Domains, Garbage Collection, Exception Handling e Just-in-Time Compilation, recursos que tornam o processo de captura dos métodos em execução mais complexo.
Nos anos 80 era comum o fato de uma aplicação conter um único processo que executasse um único fluxo de execução. Aplicativos mais complexos, que continham concorrência entre atividades internas, exigiam uma mudança neste comportamento e foram base para uma revolução no modo como os sistemas operacionais funcionavam.
Nesta época percebeu-se que era preciso aprimorar o funcionamento dos processos para que eles fossem associados a múltiplas atividades concorrentes.
Hoje os processos consistem de um ambiente de execução que gerencia diferentes recursos. Dentre estes recursos encontramos as threads, que correspondem a uma abstração do sistema operacional para uma atividade a ser executada.
Métodos assíncronos são convenientes, pois executam trabalhos de longa duração sem bloquear a thread chamadora, isto é, a thread que originou a execução do método assíncrono pode prosseguir a sua execução sem que seja necessário esperar pelo término do método em execução.
Operações tradicionais de criação de métodos assíncronos podem ser complicadas de serem implementadas, sendo difíceis de serem escritas, debugadas e mantidas. Métodos async correm contra estas complicações e facilitam todo o processo de manutenção e criação de métodos assíncronos devido a sua sintaxe enxuta.
A palavra-chave async posicionada antes da definição do tipo de dados de um método (ou lambda expression, ou método anônimo) indica que o mesmo é assíncrono.
Comumente recebo e-mails sobre: “Qual tecnologia de acesso a dados devo utilizar no meu projeto?”, “O EF é performático o suficiente para fazer isso?”, “Tenho uma rotina de acesso a dados lenta, o que devo fazer?”, “Qual a melhor formar de construir minha camada de acesso a dados?”, etc. A resposta para todas essas perguntas é basicamente a mesma. E sempre acabo me referindo ao ADO.NET como um aliado muito forte (e presente) nas aplicações que desenvolvo. Fato este que gera muita surpresa em todos.
A construção de camadas de acesso a dados é complexa e exige cuidados. Nos últimos anos muito se tem dito e apoiado o uso de ferramentas de mapeamento objeto-relacional (ORM). Tomo como exemplo este blog, onde muitos de meus posts são sobre o Entity Framework.
Outro dia me deparei com a seguinte exception ao renderizar um report local:
The Hidden expression for the subreport ‘<DataSetName>’ contains an error: Request for the permission of type ‘System.Security.Permissions.SecurityPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.
Quando processamos um report localmente (leia: fora do Reporting Services) e o Report Viewer carrega uma expressão associada com um assembly, é criado um sandboxed Application Domain (AppDomain) na memória. Esse AppDomain é criado com um conjunto de restrições de segurança.
A combinação de Windows Server 2012 com IIS 8.0 (ou IIS 8.5) pode funcionar um pouco diferente da combinação Windows Server 2012 com IIS 7.5.
Algumas alterações na funcionalidade Schannel Security Support Provider (SSP) impactaram no funcionamento do modelo de segurança e autenticação de aplicações. O SSP inclui recursos como Transport Layer Security (TLS), Secure Sockets Layer (SSL), e Datagram Transport Layer Security (DTLS). Todos esses recursos são muito importantes, pois envolvem tarefas de segurança e autenticação de aplicações.
Para que um serviço seja consumido via NetTcp no IIS, uma série de passos devem ser tomados. E o objetivo deste post é demonstrar como essa configuração pode ser feita.
Por que utilizar NetTcp? Este é o modelo de binding mais eficiente, este modelo é baseado no padrão TCP (Transmission Control Protocol). É bastante utilizado na comunicação entre serviços e dentro de ambientes de intranet. Este modelo de binding é indicado quando queremos fazer uso de um tráfego seguro e confiável.
Por que utilizar o NetTcp no IIS? Por diversas maneiras: (1) se um serviço exposto em um Windows Service tiver um estouro de exceção, então o serviço torna-se offline; (2) serviços expostos em consoles não são confiáveis, robustos e executam no contexto do usuário logado no Windows; (3) IIS é o serviço mais confiável, possui recursos de starting automático e recycling, além de possuir diversos recursos de monitoramento.
Leia mais »
Apesar dos dois tipos de dados compilarem normalmente quando os utilizamos em um query method, existe uma diferença no modo como as queries do Entity Framework são criadas quando utilizamos Expression<Func<T, bool>> e Func<T, bool>.
Quando utilizamos Expression<Func<T, bool>> o Entity Framework reconhece a expressão existente e a transforma em código SQL.
Mas, quando utilizamos Func<T, bool>, a função é compilada em Intermediate Language, e não é transformada em código SQL. Desta forma o filtro é feita em memória, logo após o load dos dados vindos do banco de dados.
Disponível desde a versão 4 do .NET Framework, a classe MemoryCache funciona de maneira similar ao cache do ASP.NET, exceto pelo fato de que a classe MemoryCache foi criada para ser utilizada em qualquer tipo de aplicação .NET, não apenas em aplicações ASP.NET.
Outra vantagem da classe MemoryCache é que ela é thread safe. Essa característica assegura o seu uso em operações assíncronas, operações executadas paralelamente e acessos originados de diferentes threads.
Fernando Henrique Ferreira 