none
Configuração do Entity RRS feed

  • Pergunta

  • Bom dia,

    Estou com uma aplicação que está com 100 no entity Framework, porém os selects estão ficando cada vez mais pesados, gostaria de saber se existem uma otimização real, as configurações populares já estão inseridas.
    Não desenvolvi a aplicação e nem posso propor uma mundaça geral no projetos de dados.

    Hardware: 4 núcleos, 8 de ram, ssd de 500 Intranet, media de 120 usuários logados ao mesmo tempo.

    Obrigado  


    terça-feira, 22 de novembro de 2016 11:54

Respostas

  • Felipe,

    Qual versão do EF está usando? Já verificou no SQL Server as queries com maior custo ou mais frequentes para verificar se podem ser otimizadas no EF (ou criadas de outra forma)?


    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, remember to "Mark as Answer".

    Se achou este post útil, por favor clique em "Votar como útil". Se por acaso respondeu sua dúvida, lembre de "Marcar como Resposta".



    terça-feira, 22 de novembro de 2016 11:58
  • Olá Felipe,

    Como você comentou, se já fez as otimizações recomendadas na internet, acredito que a solução seria migrar a forma como está fazendo as queries, pelo menos as mais pesadas. Alguns ORM's são melhores e mais performáticos para esses casos, como o Dapper. Se deseja atingir a melhor performance aí eu recomendo usar ADO.NET (Escrever as queries com SQL Puro), dessa forma você fica mais livre para otimizar sua consulta e as alternativas aumentam bastante. Eu recomendaria utilizar ADO para consultas pesadas, ainda mais tendo hardware limitado.

    Espero ter ajudado!
    Valeu!


    Se a resposta for relevante ou tenha resolvido seu problema, marque como útil/resposta!

    André Secco
    Microsoft MSP & MSDN Tech Advisor
    Blog: http://andresecco.com.br
    GitHub: http://github.com/andreluizsecco
    Twitter: @andre_secco

    terça-feira, 22 de novembro de 2016 12:00
  • Muitos fatores , são relevantes nessa questão , avaliar mudanças de ORM ,talvez não te dará o resultado esperado , pois o motivo continuará o mesmo

    O EF não nasceu para ser lento , a lentidão e causada por Querys mal escritas na aplicação , onde o desenvolvedor acredita que dentro do bloco do using

    pode escrever as querys de qualquer jeito,

    uma solução proposta , e fazer as alteração referente a performace do EF ( existe diversos links sobre esse assunto)

    outra e iniciar o Profile nas buscas lentas e analizar suas querys, 

    já tive diversas ocorrencias desse tipo 

    var lancamento  = from ( t in tabela  where t.chave = @id select t);
    
    if(lancamento.Any())
     { 
       faz algo
      }
    
    
    var existe= from ( t in tabela  where t.chave = @id select t.chave).Any();
    
    if(existe)
     { 
       faz algo
      }
    
    
    // ou coisa pior que é selecionar todos os campos da tabela
     para recuperar apenas alguns



    Wesley Neves

    terça-feira, 22 de novembro de 2016 12:44

Todas as Respostas

  • Felipe,

    Qual versão do EF está usando? Já verificou no SQL Server as queries com maior custo ou mais frequentes para verificar se podem ser otimizadas no EF (ou criadas de outra forma)?


    If you found this post helpful, please "Vote as Helpful". If it actually answered your question, remember to "Mark as Answer".

    Se achou este post útil, por favor clique em "Votar como útil". Se por acaso respondeu sua dúvida, lembre de "Marcar como Resposta".



    terça-feira, 22 de novembro de 2016 11:58
  • Olá Felipe,

    Como você comentou, se já fez as otimizações recomendadas na internet, acredito que a solução seria migrar a forma como está fazendo as queries, pelo menos as mais pesadas. Alguns ORM's são melhores e mais performáticos para esses casos, como o Dapper. Se deseja atingir a melhor performance aí eu recomendo usar ADO.NET (Escrever as queries com SQL Puro), dessa forma você fica mais livre para otimizar sua consulta e as alternativas aumentam bastante. Eu recomendaria utilizar ADO para consultas pesadas, ainda mais tendo hardware limitado.

    Espero ter ajudado!
    Valeu!


    Se a resposta for relevante ou tenha resolvido seu problema, marque como útil/resposta!

    André Secco
    Microsoft MSP & MSDN Tech Advisor
    Blog: http://andresecco.com.br
    GitHub: http://github.com/andreluizsecco
    Twitter: @andre_secco

    terça-feira, 22 de novembro de 2016 12:00
  • Muitos fatores , são relevantes nessa questão , avaliar mudanças de ORM ,talvez não te dará o resultado esperado , pois o motivo continuará o mesmo

    O EF não nasceu para ser lento , a lentidão e causada por Querys mal escritas na aplicação , onde o desenvolvedor acredita que dentro do bloco do using

    pode escrever as querys de qualquer jeito,

    uma solução proposta , e fazer as alteração referente a performace do EF ( existe diversos links sobre esse assunto)

    outra e iniciar o Profile nas buscas lentas e analizar suas querys, 

    já tive diversas ocorrencias desse tipo 

    var lancamento  = from ( t in tabela  where t.chave = @id select t);
    
    if(lancamento.Any())
     { 
       faz algo
      }
    
    
    var existe= from ( t in tabela  where t.chave = @id select t.chave).Any();
    
    if(existe)
     { 
       faz algo
      }
    
    
    // ou coisa pior que é selecionar todos os campos da tabela
     para recuperar apenas alguns



    Wesley Neves

    terça-feira, 22 de novembro de 2016 12:44
  • Bom dia,

    Devido a falta de interação do autor dessa pergunta,

    essa thread está sendo fechada. Caso o problema ainda

    esteja ocorrendo, favor abrir uma nova thread.

    Atenciosamente,


    Robson William Silva

    Esse conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita

    MSDN Community Support

    Por favor, lembre-se de Marcar como Resposta as postagens que resolveram o seu problema. Essa é uma maneira comum de reconhecer aqueles que o ajudaram e fazer com que seja mais fácil para os outros visitantes encontrarem a resolução mais tarde.

    quinta-feira, 24 de novembro de 2016 11:36
  • Muitos fatores , são relevantes nessa questão , avaliar mudanças de ORM ,talvez não te dará o resultado esperado , pois o motivo continuará o mesmo

    O EF não nasceu para ser lento , a lentidão e causada por Querys mal escritas na aplicação , onde o desenvolvedor acredita que dentro do bloco do using

    pode escrever as querys de qualquer jeito,

    uma solução proposta , e fazer as alteração referente a performace do EF ( existe diversos links sobre esse assunto)

    outra e iniciar o Profile nas buscas lentas e analizar suas querys, 

    já tive diversas ocorrencias desse tipo 

    var lancamento  = from ( t in tabela  where t.chave = @id select t);
    
    if(lancamento.Any())
     { 
       faz algo
      }
    
    
    var existe= from ( t in tabela  where t.chave = @id select t.chave).Any();
    
    if(existe)
     { 
       faz algo
      }
    
    
    // ou coisa pior que é selecionar todos os campos da tabela
     para recuperar apenas alguns



    Wesley Neves

    Wesley,

    Não somente uma query mal escrita, mas principalmente uma modelagem mal definido ou uso de forma incoerente dos tipos de dados e tamanhos de campos aplicados nas definições do banco de dados podem com o passar do tempo se tornarem grandes vilões.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quinta-feira, 24 de novembro de 2016 23:34
  • Muito obrigado Pedro por sua complementação, como tinha dito , muito fatores são relevantes, e os tipos de dados escolhidos de forma errada também tem consequencias no processo de leitura e escrita no banco,e ainda mais sobre a proporção de banco com milhares ou milhões  de registros.

    segue um link muito bom para ficar registrado.

    http://www.akamud.com.br/2014/11/09/examinando-as-queries-geradas-pelo-entity-framework-7/


    Wesley Neves


    • Editado Wesley Neves sexta-feira, 25 de novembro de 2016 11:15 complemento
    sexta-feira, 25 de novembro de 2016 11:10