none
Performance Session X Viewstate RRS feed

  • 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

    quarta-feira, 15 de fevereiro de 2012 03:00

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
    quarta-feira, 15 de fevereiro de 2012 11:09
  • Usa Session com update panel, fica melhor para o usuário final, aparenta ser mais performático que postbacks integrais da page :)
    • Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:03
    quarta-feira, 15 de fevereiro de 2012 12:22
  • [..]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
    quarta-feira, 15 de fevereiro de 2012 16:53
  • 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
    quarta-feira, 15 de fevereiro de 2012 18:16

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
    quarta-feira, 15 de fevereiro de 2012 11:09
  • Usa Session com update panel, fica melhor para o usuário final, aparenta ser mais performático que postbacks integrais da page :)
    • Marcado como Resposta AGA Neto quarta-feira, 15 de fevereiro de 2012 19:03
    quarta-feira, 15 de fevereiro de 2012 12:22
  • [..]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
    quarta-feira, 15 de fevereiro de 2012 16:53
  • Na verdade trata-se de 700.000 visitas por dia, guardando 3 campos na session
    Isso é muito, certo ?

    quarta-feira, 15 de fevereiro de 2012 17:59
  • 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
    quarta-feira, 15 de fevereiro de 2012 18:16