I'm having intermediate timeouts when calling this stored procedure from ASP.NET frontend environment on a production site. it returns the following sql exception:
Exception Details: System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Funny thing is, when executing this procedure on the server, or from a remote pc using Management Studio, it executes in 6s. But yet, sometimes times out from when executed from the ASP.NET application? Can this query be improved? Or is this issue related to something else? Anyone who can help? I;ve read some threads about increasing the timeout and enabling pooling on the connectionstring in my web.config, but haven't tried that yet.
ALTER PROCEDURE [dbo].[Report_Activity]
(
@StartDate DATETIME
, @EndDate DATETIME
, @TotalActions INT OUTPUT
)
AS
BEGIN
SELECT @TotalActions = COUNT(EventHistoryId)
FROM dbo.SessionEventHistory
WHERE DateCreated BETWEEN @StartDate AND @EndDate
SELECT EventDescription, COUNT(EventHistoryId) AS EventCount
FROM dbo.SessionEventHistory
WHERE DateCreated BETWEEN @StartDate AND @EndDate
GROUP BY EventDescription
ORDER BY EventDescription
SQL SCHEMAS:
CREATE TABLE [dbo].[SessionEventHistory](
[EventHistoryID] [int] IDENTITY(1,1) NOT NULL,
[SessionHistoryID] [int] NOT NULL,
[CategoryID] [int] NULL,
[UserName] [nvarchar](50) NULL,
[IPAddress] [nvarchar](20) NOT NULL,
[EventDescription] [nvarchar](1000) NOT NULL,
[EventData] [varbinary](max) NULL,
[DateCreated] [datetime] NOT NULL,
CONSTRAINT [PK_UserEventHistory] PRIMARY KEY CLUSTERED
(
[EventHistoryID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[SessionEventHistory] ADD CONSTRAINT [DF_UserEventHistory_DateCreated] DEFAULT (getdate()) FOR [DateCreated]
GO
Table has 3 indexes:
/****** Object: Index [IX_SessionEventHistory_SessionHistoryId_CategoryId] Script Date: 07/04/2012 10:47:06 ******/
CREATE NONCLUSTERED INDEX [IX_SessionEventHistory_SessionHistoryId_CategoryId] ON [dbo].[SessionEventHistory]
(
[SessionHistoryID] ASC,
[CategoryID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/****** Object: Index [IX_SessionEventHistory_UserName_DateCreated] Script Date: 07/04/2012 10:47:09 ******/
CREATE NONCLUSTERED INDEX [IX_SessionEventHistory_UserName_DateCreated] ON [dbo].[SessionEventHistory]
(
[UserName] ASC,
[DateCreated] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/****** Object: Index [PK_UserEventHistory] Script Date: 07/04/2012 10:47:14 ******/
ALTER TABLE [dbo].[SessionEventHistory] ADD CONSTRAINT [PK_UserEventHistory] PRIMARY KEY CLUSTERED
(
[EventHistoryID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
EDIT
I added the following Index, does it look okay?
CREATE NONCLUSTERED INDEX [IX_SessionEventHistory_DateCreated] ON [dbo].[SessionEventHistory]
(
[DateCreated] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Take a look at sys.dm_exec_sessions
for your ASP.Net application and for your SSMS session. I will hazard a guess that at least one of your SET
settings is different. This can contribute to different plans (ultimately this gets attributed to parameter sniffing) and the app side usually ends up worse off for it.
See these other questions for a lot more details:
Stored procedure slow when called from web, fast from Management Studio
Procedure times out from ADO.NET but not in SSMS
Query times out when executed from web, but super-fast when executed from SSMS
ADO .NET vs. SQL Server Management Studio - ADO performs worse
Also please read this great article by Erland Sommarskog.