Skip to content

Commit 2eec21e

Browse files
authored
Merge pull request #656
Add some known performance issues to troubleshooting
2 parents 92ffcce + 0a7fa34 commit 2eec21e

1 file changed

Lines changed: 78 additions & 0 deletions

File tree

src/content/docs/identityserver/troubleshooting.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -166,3 +166,81 @@ version used.
166166
<PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="7.4.0"/>
167167
</ItemGroup>
168168
```
169+
170+
## Performance Issues
171+
172+
In some installations, upgrading .NET and IdentityServer has caused performance issues. Since the IdentityServer and
173+
.NET version upgrades typically are done at the same time, it is sometimes hard to tell what the root cause is
174+
for the performance degradation. When working with installations to find the root cause, there are some dependencies
175+
that have been found to cause issues in specific verisons.
176+
177+
### PostgreSQL Pooling
178+
179+
There are issues with some versions of the PostgreSQL client library that gives large memory consumption. Enabling
180+
pooling on the operational store has solved this in the past:
181+
182+
```csharp
183+
.AddOperationalStore(options =>
184+
{
185+
// Enable pooling:
186+
options.EnablePooling = true;
187+
188+
// More settings....
189+
})
190+
```
191+
192+
### Entity Framework Core & Microsoft SQL OPENJSON
193+
194+
Entity Framework Core version 8 introduced a new behaviour when creating `WHERE IN()` sql clauses. Previously, the
195+
possible values were supplied as parameters, which meant that the query text was dependent on the number of items
196+
in the collection. This was solved by sending the parameters as a JSON object and using `OPENJSON` to read the parameters.
197+
While this enabled query plan caching, it unfortunately caused Microsoft SQL Server to generate bad query execution plans.
198+
199+
Please see [this EF Core GitHub Issue](https://github.com/dotnet/efcore/issues/32394#issuecomment-2266634632) for information
200+
and possible mitigations.
201+
202+
### Microsoft Azure
203+
204+
The `Azure.Core` package versions `1.41.0` and prior had an issue that caused delays when accessing Azure resources.
205+
This could be Azure blob storage or key vault for data protection or Azure SQL Server for stores, especially if managed
206+
identities are used. This package is typically not referenced directly but brought in as a transient dependency
207+
through other packages. Ensure to use version `1.42.0` or later if you are hosting on Azure.
208+
209+
### Entity Framework Core, Microsoft.Data.SqlClient, and SqlServerRetryingExecutionStrategy
210+
211+
As more developers migrate their database-powered application to the cloud,
212+
they will need to handle intermittent connection failures. In most cases, these transient connection failures occur and resolve in a short period of time, allowing the application to self-correct and continue processing requests. The strategy is known as **connection resiliency**.
213+
214+
In recent versions of Entity Framework Core and `Microsoft.Data.SqlClient`, you can enable this retry strategy explicitly, but in the case of `Microsoft.Data.SqlClient`, when operating in a cloud environment, this strategy is enabled by default or defined in the connection string.
215+
216+
```csharp
217+
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
218+
{
219+
optionsBuilder
220+
.UseSqlServer(
221+
@"Server=(localdb)\mssqllocaldb;Database=EFMiscellanous.ConnectionResiliency;Trusted_Connection=True;ConnectRetryCount=0",
222+
options => options.EnableRetryOnFailure());
223+
}
224+
```
225+
226+
In most cases, this is a _good feature to have enabled_ but there are drawbacks that can cause severe system degradation.
227+
228+
- Enabling retry on failure causes Entity Framework Core to buffer the result set. This significantly increases memory requirements and causes garbage collection pauses.
229+
- Some versions of `Microsoft.Data.SqlClient` call `Thread.Sleep` that can lock threads for up to **_10 seconds_**. This can lead to thread exhaustion and server unresponsiveness. We've isolated this issue to versions.
230+
231+
| Microsoft.EntityFrameworkCore.SqlServer | Microsoft.Data.SqlClient | Status |
232+
|:----------------------------------------|:-------------------------|:-----------|
233+
| `8.0.0` | `>=5.1.1` | ✅ Good |
234+
| `8.0.3` | `>=5.1.5` | ❌ Affected |
235+
| `8.0.4` | `>=5.1.5` | ❌ Affected |
236+
| `8.0.6` | `>=5.1.5` | ❌ Affected |
237+
| `8.0.11` | `>=5.1.6` | ✅ Good |
238+
| `9.0.1` | `>=5.1.6` | ✅ Good |
239+
| `>9.0.1` | `>=6.0.0` | ❌ Affected |
240+
241+
Architectural issues that may be causing connection resiliency issues you may want to investigate:
242+
243+
- Lack of caching in a high-load production environment.
244+
- Under-provisioned database instance with limited resources or connections available.
245+
- Datacenter networking issues caused by incorrect zoning choices.
246+
- Under-provisioned application host with limited cores/threads.

0 commit comments

Comments
 (0)