none
asp.net performance RRS feed

  • Pergunta

  • Estamos desenvolvendo um ERP web e esta muito lento. Estamos testando em uma intenet de 10 mg da NET e o sistema parece uma carroça.

    Estamos pesquisando algumas soluções aqui no site, e uma delas é o sistema cache.

    Através do link: http://www.techrepublic.com/article/try-these-aspnet-caching-strategies/1049845 pude ver +/- como funciona:

    ASP.NET’s caching engine supports three kinds of caching:

    • Page output caching: Pagina inteira
    • Fragment caching: Fragmento de Pagina
    • Data caching: Dados

    No nosso caso, temos as 3 opções, onde temos a pagina inteira em cache, porem temos fragmentos através do AJAX e também acessa dados de banco de dados.

    Alguém poderia me ajudar para me orientar o que poderia usar?

    Obrigado!

    quinta-feira, 26 de julho de 2012 18:36

Respostas

  • 6) O Rafa Santos disse que nunca deve usar cache em paginas dinamicas que acessam dados. Portanto o uso de cache em um ERP esta totalmente descartada? Ja a Priscila o Alexsandre disse que precisamos verificar varias questoes, porem o uso do cache é bom.

    Depende muito do tipo de aplicação para usar ou não cache. Mas pode ser usado sim cache, vamos a um exemplo:

    Por exemplo a página de classificação do brasileirão, muita gente acessa, é um conteúdo dinâmico, porém sabemos que ela muda os dados apenas alguns dias da semana. Essa seria uma boa candidata para utilizar cache, não precisamos a cada requisição efetuar a consulta no banco.

    Em um ERP é um pouco mais complicado, porque geralmente as informações precisam ser em tempo real, mas pode usar sim cache.

    • Marcado como Resposta Harley Araujo terça-feira, 7 de agosto de 2012 16:57
    domingo, 29 de julho de 2012 16:25
  • O Danimar foi perfeito na sua colocação. O cache só será útil se você tem um tempo pré-estabelecido de atualização dos dados. Aqui na minha empresa, por exemplo, não funcionaria porque é um call center. Os nossos clientes desejam extrair relatórios diariamente com dados atualizados na hora, conforme as chamadas forem entrando. Ou seja, não tem como fazer isso se as páginas de relatórios estiverem travadas com cache.

    Agora, eu vi Davi, que você utiliza session do tipo DataSet. O DataSet é um tipo de armazenamento de dados em memória que exige bastante do servidor. Seria muito melhor se você fizesse a recuperação das permissões dos usuário, cada vez que fosse necessário, através de um DataReader. Eu acredito que as permissões estejam em um banco de dados e vocês as armazenam em uma session assim que o usuário faz o login. Eu não faria desta forma. Segue como eu faria:

    Existe uma classe que te retorna os dados do usuário autenticado: HttpContext.Current.User. Ela te retorna se o usuário está em alguma regra (AspNetRoles) e, através do atributo Identity você vai mais além, recuperando o name do usuário. O name é o login e é único. Se você estiver usando o controle de login e permissões integrado do ASP.NET, as coisas ficam muito mais fáceis, pois você estará usando Profile e aumentam as informações de quem está autenticado, como e-mail, etc. A partir daí, você pode recuperar em qualquer lugar os dados únicos do usuário, sem se preocupar com sessions. Quando você estiver em algum momento no sistema que precisar recuperar as permissões do usuário, utilize esse dado único, identifique o usuário no banco e recupere suas permissões utilizando um DataReader. 


    Rafael Santos
    E-mail: rsdsantos@gmail.com

    Pequeno Gafanhoto

    • Marcado como Resposta Harley Araujo terça-feira, 7 de agosto de 2012 16:57
    terça-feira, 31 de julho de 2012 15:00

Todas as Respostas

  • Antes de voltarem as atenções para a aplicação, já se atentaram para o servidor? Qto de memória ele tem? Qts pessoas estão acessando? Tem um processamento bom? O link de rede do servidor é bom? O sistema está local na empresa de vocês, se sim, e o banco de dados? Se o sistema não estiver local, está em uma empresa terceirizada tipo UolHost, KingHost, etc? Qual o 'plano' adquirido, um servidor dedicado ou um plano de 15,00? 

    Façam essas perguntas a vocês mesmos antes de questionarem a qualidade da aplicação. Cache pode ser uma saída, mas nunca em páginas dinâmicas. Páginas que buscam dados do banco jamais devem usar cache.


    Rafael Santos
    E-mail: rsdsantos@gmail.com

    Pequeno Gafanhoto

    • Sugerido como Resposta Danimar Ribeiro quinta-feira, 26 de julho de 2012 22:20
    quinta-feira, 26 de julho de 2012 19:09
  • Davi,

    Além do cache, seria bom a equipe se atentar a outros items, como por exemplo:

    1 - Uso de Sessão e ViewState - uso demasiado e desnecessário desses itens traz uma grande perda de performance.

    2 - Utilização de Ajax corretamente - usando frameworks para a realização de tarefas por Ajax de forma automática pode acabar tendo perda de performance também. O AjaxControlToolkit, por exemplo, até onde trabalhei com ele, sempre trabalhava com toda a página apesar de atualizar só uma parte dela. Isso é uma grande perda, visto que a requisição para o servidor vai com a página inteira, o servidor tem o trabalho de tratá-la inteira, e responder com a página inteira, para no cliente ser usada somente uma parte da página para atualização.

    3 - Uso de Http Headers - com um bom uso dos headers http você poderá ganhar em desempenho. Pois você pode configurar o que poderá ser colocado em cache pelo browser.

    Isso tudo são algumas de muitas ações que a equipe pode tomar para aumentar o desempenho da aplicação.

    Entre os tipos de cache que listou, você pode usá-los em uma mesma aplicação sem problema. Na verdade é bom que use cada um dessas alternativas conforme as características de partes da sua aplicação.


    Alexsandre Rodrigues de Almeida - MCTS .NET Framework - Web Applications
    E-mail: alexsandrer@gmail.com
    Twitter: @AlexRAlmeida

    quinta-feira, 26 de julho de 2012 19:20
  • Antes de voltarem as atenções para a aplicação, já se atentaram para o servidor? Qto de memória ele tem? Qts pessoas estão acessando? Tem um processamento bom? O link de rede do servidor é bom? O sistema está local na empresa de vocês, se sim, e o banco de dados? Se o sistema não estiver local, está em uma empresa terceirizada tipo UolHost, KingHost, etc? Qual o 'plano' adquirido, um servidor dedicado ou um plano de 15,00? 

    Façam essas perguntas a vocês mesmos antes de questionarem a qualidade da aplicação. Cache pode ser uma saída, mas nunca em páginas dinâmicas. Páginas que buscam dados do banco jamais devem usar cache.


    Rafael Santos
    E-mail: rsdsantos@gmail.com

    Pequeno Gafanhoto

    Acrescento meus 2 cents.

    Antes de partir para cache de aplicação, você pode melhorar a qualidade comprimindo javascript, css, imagens. 

    E antes de presumir algo, vocês devem fazer um profiler da aplicação e ver quais os pontos mais lentos da aplicação, muitas conexões ao banco talvez?

    quinta-feira, 26 de julho de 2012 22:25
  • Eu ainda tenho mais um ponto a acrescentar:

    Será que as requisições feitas ao seu banco (deve ter alguma... um "ERP") estão sendo feitas da maneira correta? Pode ser esse o problema, você deve estar querendo busca em uma única consulta muitos dados de uma vez, se atrapalhando com pools abertos... essas coisas.

    Enfim, como a galera já falou há muita coisa antes de se pensar em cache. Mas use cache sim, só que dê uma olhada no resto. Cache não é uma bala de prata que vai retirar todos os seus problemas. A aplicação precisa ser bem feita e o ambiente roda ela direito :)


    Terei prazer em tentar te ajudar :)

    Sou só uma little padawan que tem sorte de andar com jedis, mas farei o possível por quem precisar :)

    Se quiser: mayumisatox@gmail.com ou @MayogaX

    sexta-feira, 27 de julho de 2012 12:06
  • Obrigado!

    1) Já testamos em nossos servidores Win Server 2008 R2 e é um pouco lento mas aceitável na rede local.

    2) Para outros clientes o software roda na locaweb em nossa revenda (servidor compartilhado) e com SQL Server 2008 tb compartilhado. Mas tanto o banco quanto o servidor web tem um desempenho satisfatório em outros produtos que desenvolvemos, e também os clientes não muitos usuários.

    3) Utilizamos uma Session do tipo dataset para armazenar permissões do usuario logado. Acredito que esse seja uma questão que pode ser melhorada. Em outra ocasiao um colega do forum disse para usar Cookies no lugar de session que disse ter resolvido varios problemas. Seria melhor partir para Cookies, Profile ou somente melhorar minha session para nao armazenar nada mais que o ID do usuario logado.

    4) AjaxControlToolkit. Estamos usando muito, pois até entao a microsoft vende a ideia que faz tudo o que esperamos do AJAX mas sem precisar implementar muitos codigos complexos, mas como disse Alexsandre sempre trabalha com a pagina inteira.

    5) Utilizamos muito ViewState, não sei se seria de forma exagerada, mas temos uma medias de 5 a 10 viewstate por pagina. Qual outro objeto poderiamos usar para armazenar estado que de mais performance?

    6) O Rafa Santos disse que nunca deve usar cache em paginas dinamicas que acessam dados. Portanto o uso de cache em um ERP esta totalmente descartada? Ja a Priscila o Alexsandre disse que precisamos verificar varias questoes, porem o uso do cache é bom.

    Existem varias outras dicas colocadas que vamos verificar como:

    - Acesso a dados;

    - Compactar CSS, Javascript, etc.

    Agradeço a todos, muito obrigado!!!

    sábado, 28 de julho de 2012 16:08
  • 6) O Rafa Santos disse que nunca deve usar cache em paginas dinamicas que acessam dados. Portanto o uso de cache em um ERP esta totalmente descartada? Ja a Priscila o Alexsandre disse que precisamos verificar varias questoes, porem o uso do cache é bom.

    Depende muito do tipo de aplicação para usar ou não cache. Mas pode ser usado sim cache, vamos a um exemplo:

    Por exemplo a página de classificação do brasileirão, muita gente acessa, é um conteúdo dinâmico, porém sabemos que ela muda os dados apenas alguns dias da semana. Essa seria uma boa candidata para utilizar cache, não precisamos a cada requisição efetuar a consulta no banco.

    Em um ERP é um pouco mais complicado, porque geralmente as informações precisam ser em tempo real, mas pode usar sim cache.

    • Marcado como Resposta Harley Araujo terça-feira, 7 de agosto de 2012 16:57
    domingo, 29 de julho de 2012 16:25
  • O Danimar foi perfeito na sua colocação. O cache só será útil se você tem um tempo pré-estabelecido de atualização dos dados. Aqui na minha empresa, por exemplo, não funcionaria porque é um call center. Os nossos clientes desejam extrair relatórios diariamente com dados atualizados na hora, conforme as chamadas forem entrando. Ou seja, não tem como fazer isso se as páginas de relatórios estiverem travadas com cache.

    Agora, eu vi Davi, que você utiliza session do tipo DataSet. O DataSet é um tipo de armazenamento de dados em memória que exige bastante do servidor. Seria muito melhor se você fizesse a recuperação das permissões dos usuário, cada vez que fosse necessário, através de um DataReader. Eu acredito que as permissões estejam em um banco de dados e vocês as armazenam em uma session assim que o usuário faz o login. Eu não faria desta forma. Segue como eu faria:

    Existe uma classe que te retorna os dados do usuário autenticado: HttpContext.Current.User. Ela te retorna se o usuário está em alguma regra (AspNetRoles) e, através do atributo Identity você vai mais além, recuperando o name do usuário. O name é o login e é único. Se você estiver usando o controle de login e permissões integrado do ASP.NET, as coisas ficam muito mais fáceis, pois você estará usando Profile e aumentam as informações de quem está autenticado, como e-mail, etc. A partir daí, você pode recuperar em qualquer lugar os dados únicos do usuário, sem se preocupar com sessions. Quando você estiver em algum momento no sistema que precisar recuperar as permissões do usuário, utilize esse dado único, identifique o usuário no banco e recupere suas permissões utilizando um DataReader. 


    Rafael Santos
    E-mail: rsdsantos@gmail.com

    Pequeno Gafanhoto

    • Marcado como Resposta Harley Araujo terça-feira, 7 de agosto de 2012 16:57
    terça-feira, 31 de julho de 2012 15:00