Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FirstOrDefaultAsync performance issue when the db entity contains a very large BLOB #32766

Closed
NazarieCiprian opened this issue Jan 10, 2024 · 2 comments

Comments

@NazarieCiprian
Copy link

When using FirstOrDefaultAsync there is a considerable performance drop if the entity that is loaded contains very large strings.
In our case the entity which we want to read from database contains a column of type NVARCHAR(max) which stores an xml formatted string. If the size of the xml goes above 10MB the reading time is about 1-2 even 3 minutes.

If the FirstOrDefault method is used the reading times is of a few seconds up to 1 minute.

This issue reproduces only for MSSQL database. We are also using Oracle and PSQL, but for these databases both the synchronous and asynchronous method work as expected.

 public async Task<Test> Get(int id)
{
     return await _context.Tests.FirstOrDefaultAsync(s => s.Id == id);
}

EF Core version: EFCore 7
Database provider: Microsoft.EntityFrameworkCore.SqlServer 7.0.9
Target framework: .NET 7.0
Operating system: Windows
IDE: Visual Studio 2022 17.6.5

@roji
Copy link
Member

roji commented Jan 10, 2024

Duplicate of dotnet/SqlClient#593

@roji roji marked this as a duplicate of dotnet/SqlClient#593 Jan 10, 2024
@roji
Copy link
Member

roji commented Jan 10, 2024

Assuming the synchronous variant (FirstOrDefault()) is fast, then this is the above issue - it's a well-known SqlClient performance issue with async that EF can't do anything about.

@roji roji closed this as not planned Won't fix, can't repro, duplicate, stale Jan 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants