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.

Saiba mais

Sobre estes anúncios

Processos e threads

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.

Saiba mais

Async Methods e sua comparação com Tasks

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.

flechas

Saiba mais

E o ADO.NET nunca deve deixar de ser utilizado

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.

Imagem-Animada-How-Do-You-DoWhat

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.

Saiba mais

The Hidden expression for the subreport (…) contains an error: Request for the permission of type ‘System.Security.Permissions.SecurityPermission’

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.

Saiba mais

Your client certificate is either not trusted or is invalid (com Windows Server 2012 e IIS 8.0 (ou IIS 8.5))

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.

Saiba mais

Hospedando serviços WCF no IIS via NetTcp e Windows Process Activation

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.
Saiba mais

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 66 outros seguidores