Session-State
Fonte: http://forums.asp.net/p/7504/7504.aspx#7504
1-Localização do armazenamento:
InProc – a sessão é mantida como objetos ativos no web Server (aspnet_wp.exe)
StateServer – A sessão é serializada e armazenada em memória, em um processo separado (aspnet_state.exe). A vantagem é que o Stateserver pode ser executado em outra máquina
SQLServer – a sessão é serializada e armazenada
Performance:
No InProc é mais rápido, mas, quanto mais dados de sessão, mais memória é consumida no webserver, que pode afetar a performance. Além disso, qualquer situação que provoque o restart do aspnet_wp.exe fará com que um novo processo seja criado e, assim, todas as sessões atuais serão perdidas.
StateServer: quando tipos básicos, como string, inteiros, etc. são armazenados, é cerca de 15% mais lento que o método In-Proc. Quanto mais serialização/desserialização for necessária, maior a penalidade na performance. A vantagem é que, rodando em um servidor separado, este pode ser dedicado a essa função (um luxo?).
SQLServer: quando tipos básicos, como string, inteiros, etc. são armazenados, é cerca de 25% mais lento que o método In-Proc. Mesmas considerações para o StateServer. A vantagem desse método é que se o aspnet_wp for reiniciado, os dados das sessões serão preservados (dentro do tempo limite de validade). Pode-se ainda, utilizar um SQL em cluster, para garantir escalabilidade e, combinado com um balanceamento de carga de rede, distribuir as requisições, diminuindo o tempo de resposta.
Prevalece o entendimento de que se deve procurar armazenar as sessões com tipos básicos, visto que estes utilizam um código performático para a serialização, desserialização. Para outros tipos, é utilizado um método binário, que é mais lento, para esta tarefa.
