Query runs slow via EF core but fast on SSMS

[meghaaprasad]

Hello,

I have a simple query running from my .Net core api application using EF Core that runs very slow in application (around 30s) but on SSMS it returns in about 1s
Query is

SELECT [a].[Id], [a].[EntityId], [a].[EntityType], [a].[InputPresCount], [a].[InputUserCount], [a].[OutputDomainPresCount], [a].[OutputEmailCount], [a].[OutputUserPresCount], [a].[Priority], [a].[ProcessingEndDateUtc], [a].[ProcessingStartDateUtc], [a].[ProgressPercentage], [a].[Request], [a].[RequestTypeId], [a].[SalesPersonCompanyId], [a].[SalesPersonId], [a].[SubmittedDateUtc], [a].[UmpPermissionQueueStatusId]
FROM [PermissionQueue] AS [a]
WHERE [a].[EntityId] = 1234567

The [a].[Request] is nvarchar(max) type column

[roji]

@meghaaprasad there's a good chance SSMS limits the number of results it asks for, whereas in EF the entire query results are retrieved - check how many rows you're actually retrieving in both cases. Also, it's worth turning on EF's logging feature to make sure it's sending the SQL you think it is.

Otherwise, there's not much we can do with an isolated SQL query - can you please submit a minimal EF Code repro, including a schema and data characteristics? EF

[ErikEJ]

Or do you use the Async API with EF Core to read blobs?

[meghaaprasad]

apologies on late reply. Yes I am querying the blob and converting to my list using .ToListAsync(). I jave tried using .ToList() but that times out

…

On Sat, 13 Mar 2021, 6:04 pm Erik Ejlskov Jensen, ***@***.***> wrote: Or do you use the Async API with EF Core to read blobs? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24391 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGF62IUS3KXDFNOFOIYOK6LTDNLW7ANCNFSM4ZDKTIJA> .

[roji]

@meghaaprasad then I think we're going to need a runnable code sample which reproduces the problem in order to investigate this...

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.