Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Stored procedure slow when called from web, fast from Management Studio

I have stored procedure that insanely times out every single time it's called from the web application.

I fired up the Sql Profiler and traced the calls that time out and finally found out these things:

  1. When executed the statements from within the MS SQL Management Studio, with same arguments (in fact, I copied the procedure call from sql profile trace and ran it): It finishes in 5~6 seconds avg.
  2. But when called from web application, it takes in excess of 30 seconds (in trace) so my webpage actually times out by then.

Apart from the fact that my web application has its own user, every thing is same (same database, connection, server etc) I also tried running the query directly in the studio with the web application's user and it doesn't take more than 6 sec.

How do I find out what is happening?

I am assuming it has nothing to do with the fact that we use BLL > DAL layers or Table adapters as the trace clearly shows the delay is in the actual procedure. That is all I can think of.

EDIT I found out in this link that ADO.NET sets ARITHABORT to true - which is good for most of the time but sometime this happens, and the suggested work-around is to add with recompile option to the stored proc. In my case, it's not working but I suspect it's something very similar to this. Anyone knows what else ADO.NET does or where I can find the spec?

like image 283
iamserious Avatar asked Jul 05 '11 15:07

iamserious


People also ask

Why is my stored procedure so slow?

Storage of Execution Plan – One of the biggest reasons why you are facing slow procedures in SQL Server is probably because your Execution plan is stored in the cache. To find out if it is in the cache, you need to search it there and see if it exists in the top 10 appearing plans.

Do stored procedure run faster?

Conclusion. Overall, stored procedures outperform dynamic SQL. They are faster, easier to maintain, and require less network traffic. The rule of thumb would suggest using stored procedures in scenarios where you don't have to modify queries, and those queries are not very complex.

Which is faster inline query or stored procedure?

Stored procedures are precompiled and optimised, which means that the query engine can execute them more rapidly. By contrast, queries in code must be parsed, compiled, and optimised at runtime.


2 Answers

I've had a similar issue arise in the past, so I'm eager to see a resolution to this question. Aaron Bertrand's comment on the OP led to Query times out when executed from web, but super-fast when executed from SSMS, and while the question is not a duplicate, the answer may very well apply to your situation.

In essence, it sounds like SQL Server may have a corrupt cached execution plan. You're hitting the bad plan with your web server, but SSMS lands on a different plan since there is a different setting on the ARITHABORT flag (which would otherwise have no impact on your particular query/stored proc).

See ADO.NET calling T-SQL Stored Procedure causes a SqlTimeoutException for another example, with a more complete explanation and resolution.

like image 83
StriplingWarrior Avatar answered Sep 28 '22 04:09

StriplingWarrior


I also experience that queries were running slowly from the web and fast in SSMS and I eventually found out that the problem was something called parameter sniffing.

The fix for me was to change all the parameters that are used in the sproc to local variables.

eg. change:

ALTER PROCEDURE [dbo].[sproc]      @param1 int, AS SELECT * FROM Table WHERE ID = @param1  

to:

ALTER PROCEDURE [dbo].[sproc]      @param1 int, AS DECLARE @param1a int SET @param1a = @param1 SELECT * FROM Table WHERE ID = @param1a 

Seems strange, but it fixed my problem.

like image 39
Zane Avatar answered Sep 28 '22 03:09

Zane