EF6 SQLQuery muito lento, mas o banco de dados é muito rápido

9

Eu tenho um problema de desempenho, fizemos várias análises e estamos presos. Espero que um de vocês já tenha visto isso antes.

Estou chamando DbContext.Database.SqlQuery a parte do banco de dados leva 3ms, mas a execução completa leva 9 segundos.

Nós usamos o EF Profiler para descobrir isso e também executamos o SQL diretamente no SQL Server Management Studio e ele é instantâneo.

Também usamos o vislumbre e não conseguimos enxergar fundo o suficiente no processo.

O tipo de resultado não é uma entidade do modelo e, portanto, estamos confiantes de que o rastreamento não está envolvido.

Também sabemos que esta não é a primeira consulta executada contra o contexto, portanto, não estamos pagando o custo de inicialização do EF nessa consulta.

Nós tentamos o profiler do .net e tivemos tantos problemas rodando que decidimos que deveríamos apenas perguntar.

Alguma dica sobre como investigar e descobrir isso?

EDIT: O conjunto de resultados para esta consulta é de 1 linha com 4 colunas (decimal)

A linha de código é apenas:

var list=contextInstance.Database.SqlQuery<nonEntityType>(sqstring).ToList();

O próprio SQL não é uma cadeia muito longa. Usaremos um profiler mais detalhado para descobrir onde, no processo, isso está sendo desativado.

    
por RandyDes 06.08.2015 в 22:01
fonte

2 respostas

1
  

Nós usamos o EF Profiler para descobrir isso e também executamos o SQL   diretamente no SQL Server Management Studio e é instantâneo.

Isso não prova nada. A consulta pode ser executada rapidamente, mas os dados podem resultar em 100 MB de dados, que são então transportados para o cliente e materializados em objetos. Isso pode levar mais tempo do que você imagina.

A consulta no SSMS pode retornar instantânea porque mostra apenas parte dos dados. Você não disse quais eram os dados.

Use um profiler real do .NET, como dotTrace ou Ants. Desta forma, você pode ver onde o tempo é perdido exatamente na linha. EF Prof (ou meu próprio ORM Profiler: link ) lhe dirá qual parte da rota total tomada (ORM- > DB- > ORM) leva a que horas. Mesmo EF prof faz;)

    
por Frans Bouma 06.08.2015 / 22:49
fonte
1

Se o cliente, por alguma razão, não puder usar um profiler como Frans sugere, você terá que jogar o jogo de adivinhação e excluir possibilidades.

Antes de mais nada, acho que falta uma informação crítica. Demora sempre cerca de 9 segundos ou varia?

Primeiro passo:

Decida se o atraso é antes ou depois da consulta atingir o banco de dados. Deve ser possível fazer com o profiler EF e observar os timestamps no Sql Profiler.

De qualquer forma, você terá limitado um pouco as possibilidades.

Segundo passo:

Exclua o máximo possível

  • Índices (Não, a consulta é rápida)
  • Como devolver muitos dados (Não, de acordo com as informações que você tem)
  • Compilação de consulta lenta (Não, consulta SQL em bruto é usada)
  • Transferência lenta de dados (Não, as outras consultas funcionam bem)
  • Inicialização lenta do DbContext (Não, você disse que não é a primeira consulta)
  • Bloqueios de linha ou tabela (provavelmente, isso provavelmente seria exibido como uma consulta longa no profiler)
  • Materialização lenta (Não, para alguns campos, a menos que exista um bug sério no caso de borda)

Terceiro passo:

O que resta? Isso depende da resposta para # 1 e também se é sempre 9 segundos.

Meus principais suspeitos aqui são alguns problemas de conexão, porque outra chamada está bloqueando, portanto, ela precisa aguardar uma conexão ou algum cache de segundo nível ou algo que não funciona bem com essa consulta.

Para excluir mais algumas alternativas, eu tentaria executar a mesma consulta usando o ADO.NET antigo simples. Se o problema persistir, você sabe que não é um problema de EF e, muito provavelmente, um problema de conexão. Se ele for embora, ainda pode ser ambos os problemas.

Não tanto como uma resposta como alguns discursos, mas espero que algo que você não tenha pensado já.

    
por Mikael Eliasson 07.08.2015 / 23:36
fonte