Por Iqbal Khan
Os aplicativos baseados em ASP.NET, a estrutura de aplicativos da Web da Microsoft, estão avançando cada vez mais nas empresas. Ao mesmo tempo, gargalos resultantes de um número crescente de usuários e transações continuam a levar os profissionais de TI a exigir melhor desempenho e escalabilidade.
Afunilamentos podem ocorrer em aplicativos ASP.NET por vários motivos. O mais óbvious: A tecnologia de armazenamento de dados não é tão escalável quanto a arquitetura de aplicativos da Web. Qualquer lugar em um aplicativo ASP.NET que lida com armazenamento de dados ou acesso a dados imediatamente se torna um impasse quando você tenta dimensionar seu aplicativo. Duas áreas em que isso acontece são o armazenamento do estado da sessão e os dados do aplicativo de um banco de dados relacional ou de mainframe.
Outro gargalo ocorre se seu aplicativo ASP.NET estiver fazendo chamadas de arquitetura orientada a serviços (SOA) para serviços da Web. Aqui, a lentidão acontece porque os serviços da Web têm os mesmos problemas que seu aplicativo ASP.NET (ou seja, no armazenamento e acesso a dados). As chances são de que um farm de serviços da Web esteja sendo compartilhado entre vários aplicativos e, portanto, sendo muito mais sobrecarregado do que qualquer aplicativo ASP.NET, criando o gargalo de escalabilidade.
Leia o artigo completoGargalos também podem ocorrer entre o navegador do usuário e o Web farm ASP.NET. Esses entupimentos estão relacionados ao fato de que as páginas ASP.NET precisam ser executadas repetidamente em momentos que envolvem processamento intensivo da CPU. Este processo também envolve o envio repetido de elementos de dados pesados (imagens, documentos, etc.) ao usuário.
Em um artigo anterior da TechNet Magazine, discuti questões de desempenho e escalabilidade do ASP.NET, com foco no estado da sessão e nos dados do aplicativo (consulte "Fornecendo escalabilidade para aplicativos ASP.NET", junho de 2009). Nesse artigo, abordei como esses problemas ocorrem, incluindo os motivos pelos quais o estado da sessão ASP.NET se torna um impasse à medida que um Web farm cresce. Discuti o fato de que o cache distribuído na memória é uma alternativa superior à opção de armazenamento existente da Microsoft para estado de sessão do ASP.NET. Descrevi como os dados de aplicativos provenientes de um banco de dados podem causar gargalos de escalabilidade. Também detalhei como o cache distribuído resolve esses gargalos de armazenamento do estado de sessão do ASP.NET com a ajuda de diferentes topologias de cache, cada uma oferecendo recursos diferentes, mas todas abordando a escalabilidade e garantindo 100% de tempo de atividade.
Leia o artigo completo