Usuário com melhor resposta
Performance Session X Viewstate

Pergunta
-
Pessoal,
Estou trabalhando num projeto e o mesmo usa updatepanel.
Com isso o Viewstate nao funciona.Pergunta:
O que pesa mais pro servidor:1. Trabalhar com Updatepanel e Session (somente 3 campos texto serao armazenados na session)
2. Trabalhar com viewstate mas atualizando todo o conteudo da pagina ?E ai ?
Abracos
Respostas
-
Nenhum dos dois vai pesar muito pro servidor no seu caso, 3 campos textos são poucas informações e o Session armazena apenas as referências pros dados na memória do servidor, então depende apenas da memória mesmo.
O session deve ser usado se você desejar que esses dados sejam mantidos durante todo o tempo que o usuário permanecer em sua app web e se você precisa desses valores em mais de uma página(como um carrinho de compras online).
No caso do ViewState, assim que o usuário mudar a páginas essas informações serão perdidas, lembrando que o Viewstate é envidado também para o cliente no corpo da página, portanto se forem muitos dados isso pode aumentar o "peso" da página e deixar o carregamento mais lento.
O viewstate também é transferido durante um postback assíncrono, então se for possível não utiliza-lo para evitar essa transferência constante de dados. Ou seja, se você estiver usando um updatepanel em volta de um label apenas e fizer a atualização dessa região todo o viewstate da página será enviado.
Mas deixando claro que isso depende do seu contexto, das suas regras de negócio e de como está estruturada a aplicação.
Rodrigo Reis Ferreira
Microsoft Certified- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:03
-
-
[..]Session armazena apenas as referências pros dados na memória do servidor[...]
Boas Rodrigo,
Isso que escreveste só é absolutamente verdade se o SessionState.Mode = InProc.
A questão do uso, ou não, de Session prende-se não só com o uso que a página faz do Session mas acima de tudo da volumetria de uso da própria página.
Se a página for de uso intensivo com sessões diferentes (muitos clientes) então guardar apenas 3 campos pode ser um problema.
Quanto ao ViewState é um problema de largura de banda e latência mas não deverá ter impacto significativo na performance do servidor.
Nuno Gomes http://nunogomes.net
- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:02
-
Agradeço a complementação Nuno, mas como disse:
"[...]deixando claro que isso depende do seu contexto, das suas regras de negócio e de como está estruturada a aplicação."
Mas você tem razão, depende sim da quantidade usuários, uma alternativa seria utilizar o modo(SessionState.Mode) como SQLServer para armazenar a sessão em banco, caso sua estrutura permita.
Uma forma de tirar essasdúvidas é executar testes de carga pelo Visual Studio (Load Tests) para simular uma grande quantidade de usuários.
Rodrigo Reis Ferreira
Microsoft Certified- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:02
Todas as Respostas
-
Nenhum dos dois vai pesar muito pro servidor no seu caso, 3 campos textos são poucas informações e o Session armazena apenas as referências pros dados na memória do servidor, então depende apenas da memória mesmo.
O session deve ser usado se você desejar que esses dados sejam mantidos durante todo o tempo que o usuário permanecer em sua app web e se você precisa desses valores em mais de uma página(como um carrinho de compras online).
No caso do ViewState, assim que o usuário mudar a páginas essas informações serão perdidas, lembrando que o Viewstate é envidado também para o cliente no corpo da página, portanto se forem muitos dados isso pode aumentar o "peso" da página e deixar o carregamento mais lento.
O viewstate também é transferido durante um postback assíncrono, então se for possível não utiliza-lo para evitar essa transferência constante de dados. Ou seja, se você estiver usando um updatepanel em volta de um label apenas e fizer a atualização dessa região todo o viewstate da página será enviado.
Mas deixando claro que isso depende do seu contexto, das suas regras de negócio e de como está estruturada a aplicação.
Rodrigo Reis Ferreira
Microsoft Certified- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:03
-
-
[..]Session armazena apenas as referências pros dados na memória do servidor[...]
Boas Rodrigo,
Isso que escreveste só é absolutamente verdade se o SessionState.Mode = InProc.
A questão do uso, ou não, de Session prende-se não só com o uso que a página faz do Session mas acima de tudo da volumetria de uso da própria página.
Se a página for de uso intensivo com sessões diferentes (muitos clientes) então guardar apenas 3 campos pode ser um problema.
Quanto ao ViewState é um problema de largura de banda e latência mas não deverá ter impacto significativo na performance do servidor.
Nuno Gomes http://nunogomes.net
- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:02
-
-
Agradeço a complementação Nuno, mas como disse:
"[...]deixando claro que isso depende do seu contexto, das suas regras de negócio e de como está estruturada a aplicação."
Mas você tem razão, depende sim da quantidade usuários, uma alternativa seria utilizar o modo(SessionState.Mode) como SQLServer para armazenar a sessão em banco, caso sua estrutura permita.
Uma forma de tirar essasdúvidas é executar testes de carga pelo Visual Studio (Load Tests) para simular uma grande quantidade de usuários.
Rodrigo Reis Ferreira
Microsoft Certified- Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:02