Não há absolutamente nenhuma dúvida sobre isso. O ASP.NET chegou à idade e uma boa maioria dos aplicativos ASP.NET agora são de alto tráfego e de missão crítica. Isso significa que você não pode arcar com o tempo de inatividade não programado de todo o site ou de alguns dos servidores onde muitos usuários estão sendo eliminados. Isso ocorre porque esses tempos de inatividade custam caro em receita perdida e uma má reputação que é difícil de consertar.
O armazenamento do estado de sessão do ASP.NET, se não for tratado corretamente, pode causar tempos de inatividade não programados. A Microsoft oferece quatro opções de armazenamento para ASP.NET Session State:
- InProc: Sessões mantidas dentro do processo de trabalho
- Servidor de estado: Sessão mantida em um processo separado
- Servidor SQL: Sessão mantida no SQL Server
- Personalizadas: Sessão mantida em uma loja personalizada de terceiros
Ambos InProc e StateServer não têm a capacidade de replicar o estado de sessão ASP.NET para mais de um servidor e, portanto, causar perda de dados se algum servidor web ficar inativo. Na verdade, se você tiver um único Servidor de Estado para todo o site e ele cai, você está totalmente enxuto porque todo o seu site vai cair.
Servidor SQL é a terceira opção de armazenamento para o estado de sessão ASP.NET e fornece redundância de servidor e replicação de dados porque você pode criar um cluster de banco de dados, seja um cluster espelhado ou com balanceamento de carga.
Mas é caro configurar clusters do SQL Server e existem alternativas mais baratas e viáveis disponíveis. Além disso, o SQL Server (como todos os bancos de dados relacionais) foi projetado para armazenar dados relacionais estruturados e não BLOBs; enquanto o estado de sessão do ASP.NET é armazenado no SQL Server como BLOBs. Portanto, não apenas as sessões são lentas para acessar, mas o banco de dados rapidamente se torna um gargalo à medida que você tenta dimensionar seu aplicativo.
Uma alternativa consideravelmente melhor para tudo isso é usar a opção de armazenamento personalizado de Estado da Sessão ASP.NET e use um cache distribuído na memória (NCache) como seu armazenamento de estado de sessão ASP.NET. NCache replica sessões em vários servidores, portanto, se algum servidor ficar inativo, não haverá perda de dados de sessão. NCache também é muito mais rápido de acessar do que o SQL Server porque está na memória. Finalmente, NCache permite dimensionar facilmente o cluster de cache à medida que o tamanho do seu web farm aumenta. Basta adicionar mais servidores de cache ao cluster para que nunca haja um gargalo.
E, o melhor de tudo, não há necessidade de programação para usar NCache para armazenamento de estado de sessão ASP.NET. Basta modificar seu web.config para especificar o seguinte:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<assemblies> <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.4.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="NCacheTest" enableLogs="false" cacheName="myReplicatedCache"/> </providers> </sessionState> |
Bem, se você tem um aplicativo ASP.NET rodando em um web farm, dê uma olhada em NCache e veja como isso melhorará seu armazenamento de estado de sessão ASP.NET. Aqui estão alguns links úteis para NCache:
Você pode começar com um mínimo de dois servidores dedicados em um cluster de cache para alta disponibilidade e confiabilidade e, em seguida, é recomendável manter uma proporção de 4:1 entre seus servidores Web/App e servidores de cache para obter desempenho e escalabilidade ideais para seus aplicativos .