Perché ci sono differenze di prestazioni quando viene chiamata una funzione SQL dall'app .Net vs quando viene effettuata la stessa chiamata in Management Studio

Question

Stiamo riscontrando un problema nei nostri ambienti di test e di sviluppo con una funzione che viene eseguita abbastanza lentamente a volte quando viene chiamata da un'applicazione .Net. Quando chiamiamo questa funzione direttamente dallo studio di gestione, funziona bene.

Qui ci sono le differenze quando si sono profilate: dall'applicazione:
CPU: 906
legge: 61853
scrive: 0
Durata: 926

Da SSMS:
CPU: 15
Letture: 11243
Scrive: 0
Durata: 31

Ora abbiamo determinato che quando ricompiliamo la funzione, la prestazione ritorna a ciò che ci aspettiamo e il profilo delle prestazioni quando viene eseguito dall'applicazione corrisponde a quello di ciò che otteniamo quando lo eseguiamo da SSMS. Inizierà di nuovo a rallentare in corrispondenza di ciò che appare a intervalli casuali.

Non abbiamo visto questo in prod, ma possono essere in parte perché tutto è ricompilato lì su base settimanale.

Quindi cosa potrebbe causare questo tipo di comportamento?

Edit -
siamo finalmente in grado di affrontare questo e ristrutturare le varables per affrontare con il parametro sniffing sembra aver fatto il trucco ... un frammento di quello che abbiamo fatto qui: Grazie per il vostro aiuto.

 -- create set of local variables for input parameters - this is to help performance - vis a vis "parameter sniffing" 
    declare @dtDate_Local     datetime 
      ,@vcPriceType_Local    varchar(10) 
      ,@iTradingStrategyID_Local  int 
      ,@iAccountID_Local    int 
      ,@vcSymbol_Local    varchar(10) 
      ,@vcTradeSymbol_Local   varchar(10) 
      ,@iDerivativeSymbolID_Local  int 
      ,@bExcludeZeroPriceTrades_Local bit 

    declare @dtMaxAggregatedDate  smalldatetime 
      ,@iSymbolID    int 
      ,@iDerivativePriceTypeID int 

    select @dtDate_Local     = @dtDate 
      ,@vcPriceType_Local    = @vcPriceType 
      ,@iTradingStrategyID_Local  = @iTradingStrategyID 
      ,@iAccountID_Local    = @iAccountID 
      ,@vcSymbol_Local    = @vcSymbol 
      ,@vcTradeSymbol_Local   = @vcTradeSymbol 
      ,@iDerivativeSymbolID_Local  = @iDerivativeSymbolID 
      ,@bExcludeZeroPriceTrades_Local = @bExcludeZeroPriceTrades 

Answer 1

Questo di solito è perché si sta ottenendo un piano di esecuzione diverso nella connessione SSMS. Spesso correlati a problemi di snifing dei parametri in cui il piano viene generato con un valore specifico non ottimale per altri valori dei parametri. Questo spiega anche perché la ricompilazione potrebbe risolvere il problema. Questa discussione sembra avere una buona spiegazione Parameter Sniffing (or Spoofing) in SQL Server

Answer 2

Ho avuto un problema simile con le stored procedure, e per me è risultato essere "parametro sniffing". Google e per vedere se risolve il tuo problema, per me è stata una drammatica accelerazione una volta sistemata.

Nel mio caso, l'ho risolto dichiarando una variabile locale per ogni parametro passato, quindi assegnata la variabile locale al valore di quel parametro e il resto del proc utilizzava le variabili locali per l'elaborazione ... per qualsiasi ragione, questo ha sconfitto il parametro sniffing.

Answer 3

Una causa probabile è la statistica non aggiornata e/o l'annidamento dei parametri che causa il riutilizzo di un piano di query memorizzato nella cache che non è ottimale.

SSMS emette dichiarazioni pre-amble che non si vedono, che causano la ricompilazione della query inviata ogni volta, eliminando così la possibilità di utilizzare un piano memorizzato nella cache errato.

Questo aggiornerà tutte le statistiche e aggiornare viste e stored procedure (ma fate attenzione a esecuzione su una macchina di produzione):

EXEC sp_updatestats 

EXEC sp_refreshview 

EXEC sp_msForEachTable 'EXEC sp_recompile ''?'''