Can someone help me diagnose a strange stored procedure performance issue please?

Question

I have a stored procedure (posted below) that returns message recommendations based upon the Yammer Networks you have selected. If I choose one network this query takes less than one second. If I choose another this query takes 9 - 12 seconds.
/****** Object: StoredProcedure [dbo].[MessageView_GetOutOfContextRecommendations_LargeSet] Script Date: 2/18/2015 3:10:35 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[MessageView_GetOutOfContextRecommendations_LargeSet]
-- Parameters
@UserID int,
@SourceMessageID int = 0
AS
BEGIN
-- variable for @HomeNeworkUserID
Declare @HomeNeworkUserID int
-- Set the HomeNetworkID
Set @HomeNeworkUserID = (Select HomeNetworkUserID From NetworkUser Where UserID = @UserID)
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON
-- Begin Select Statement
Select Top 40 [CreatedDate],[FileDownloadUrl],[HasLinkOrAttachment],[ImagePreviewUrl],[LikesCount],[LinkFileName],[LinkType],[MessageID],[MessageSource],[MessageText],[MessageWebUrl],[NetworkID],[NetworkName],[PosterEmailAddress],[PosterFirstName],[PosterImageUrl],[PosterName],[PosterUserName],[PosterWebUrl],[RepliesCount],[Score],[SmallIconUrl],[Subjects],[SubjectsCount],[UserID]
-- From View
From [MessageView]
-- Do Not Return Any Messages That Have Been Recommended To This User Already
Where [MessageID] Not In (Select MessageID From MessageRecommendationHistory Where UserID = @UserID)
-- Do Not Return Any Messages Created By This User
And [UserID] != @UserID
-- Do Not Return The MessageID
And [MessageID] != @SourceMessageID
-- Only return messages for the Networks the user has selected
And [NetworkID] In (Select NetworkID From NetworkUser Where [HomeNetworkUserID] = @HomeNeworkUserID And [AllowRecommendations] = 1)
-- Order By [MessageScore] and [MessageCreatedDate] in reverse order
Order By [Score] desc, [CreatedDate] desc
ENDThe Actual Execution Plan Shows up the same; there are more messages on the Network that is slow, 2800 versus 1,500 but the difference is ten times longer on the slow network.Is the fact I am doing a Top 40 what makes it slow? My first guess was to take the Order By Off and that didn't seem to make any difference.The execution plan is below, it takes 62% of the query to look up theIX_Message.Score which is the clustered index, so I thought this would be fast. Also the Clustered Index Seek for the User.UserID take 26%which seems high for what it is doing.
I have indexes on every field that is queried on so I am kind of at a loss as to where to go next.
It just seems strange because it is the same view being queried in both cases.
I tried to run the SQL Server Tuning Wizard but it doesn't run on Azure SQL, and my problem doesn't occur on the data in my local database.
Thanks for any guidance, I know a lot of the slowness is due to the lower tier Azure SQL we are using, many of the performance issues weren't noticed when were on the full SQL Server, but the other networks work extremely fast so it has to be something to
with having more rows.
In case you need the SQL for the View that I am querying it is:
SET QUOTED_IDENTIFIER ON
GO
CREATE VIEW [dbo].[MessageView]
AS
SELECT M.UserID, M.MessageID, M.NetworkID, N.Name AS NetworkName, M.Subjects, M.SubjectsCount, M.RepliesCount, M.LikesCount, M.CreatedDate, M.MessageText, M.HasLinkOrAttachment, M.Score, M.WebUrl AS MessageWebUrl, U.UserName AS PosterUserName,
U.Name AS PosterName, U.FirstName AS PosterFirstName, U.ImageUrl AS PosterImageUrl, U.EmailAddress AS PosterEmailAddress, U.WebUrl AS PosterWebUrl, M.MessageSource, M.ImagePreviewUrl, M.LinkFileName, M.FileDownloadUrl, M.LinkType, M.SmallIconUrl
FROM dbo.Message AS M INNER JOIN
dbo.Network AS N ON M.NetworkID = N.NetworkID INNER JOIN
dbo.[User] AS U ON M.UserID = U.UserID
GO
The Network Table has an Index on Network ID, but it non clustered but I don't think that is the culprit.
Corby

Answer 1

I marked your response as answer because you gave me information I didn't have about the sort. I ended up rewriting the query to be a join instead of the In's and it improved dramatically, about one second on a very minimal Azure SQL database, and before
it was 12 seconds on one network. We didn't notice the problem at all before we moved to Azure SQL, it was about one - three seconds at most.
Here is the updated way that was much more efficient:
CREATE PROCEDURE [dbo].[Procedure Name]
-- Parameters
@UserID int,
@SourceMessageID int = 0
AS
BEGIN
-- variable for @HomeNeworkUserID
Declare @HomeNeworkUserID int
-- Set the HomeNetworkID
Set @HomeNeworkUserID = (Select HomeNetworkUserID From NetworkUser Where UserID = @UserID)
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON
;With cteMessages As
-- Begin Select Statement
Select (Fields List)
-- Join to Network Table
From MessageView mv Inner Join NetworkUser nu on MV.NetworkID = nu.NetworKID -- Only Return Networks This User Has Selected
Where nu.HomeNetworkUserID = @HomeNeworkUserID And AllowRecommendations = 1
-- Do Not Return Any Messages Created By This User
And mv.[UserID] != @UserID
-- Do Not Return The MessageID
And mv.[MessageID] != @SourceMessageID
), cteHistoryForThisUser As
Select MessageID From MessageRecommendationHistory Where UserID = @UserID
-- Begin Select Statement
Select Top 40 (Fields List)
-- Join to Network Table
From cteMessages m Left Outer Join cteHistoryForThisUser h on m.MessageID = h.MessageID
-- Do Not Return Any Items Where User Has Already been shown this Message
Where h.MessageID Is Null
-- An Order By Is Needed To Get The Best Content First
Order By Score Desc
END
GO
The Left Outer Join to test for null was the biggest improvement, but it also helped to join to the NetworkUser table instead of do the In sub query.