Switch SqlDataReader.ReadAsync to SqlDataReader.Read in SqlSessionStateProviderAsync because of a known performance issue with reading large data asynchronously

[tjamin]

In one project, we suddenly encountered a major performance issue. The problem arose after deploying a new release. We spent a considerable amount of time searching for the cause within our release. Ultimately, the issue was traced back to the SqlSessionStateProviderAsync.

Since we use Application Insights for logging and tracing, we observed unusual gaps after reading the ASP.NET session. Initially, it appeared as if the session had already been read, and then the gap occurred. After extensive analysis and significantly extending the SqlSessionStateProviderAsync with telemetry, we (my colleague @opneu and I) discovered that time was being lost within this session provider implementation.

The calls to SqlDataReader.ReadAsync and SqlDataReader.GetFieldValueAsync within SqlSessionStateProviderAsync were taking an extremely long time. Further research led me to this ticket:

dotnet/SqlClient#593

After switching to the synchronous versions of the aforementioned methods, the session could be loaded again within just a few milliseconds.

We attribute the sudden occurrence of the massive performance problems to the fact that, with the new release, we are writing more to the ASP.NET session than before the release.

Looking back at past logs, we can say that we were not only able to resolve the new, truly severe performance issue, but the average access times to the ASP.NET session have also been faster since the fix.

[tjamin]

@dotnet-policy-service agree