Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Monitor connection pools through the database driver, not EF Core alone. For SQL Server with Microsoft.Data.SqlClient, attach dotnet-counters to the ASP.NET Core process and inspect SqlClient EventCounters. For PostgreSQL with Npgsql, inspect its .NET metrics for connections by state and pool identity. Then correlate those signals with request load, database latency, and errors to tell pool pressure from other problems.
Choose the monitoring signals for your database provider
Connection pooling is implemented by the database driver. EF Core can report query, save, and context activity, but those signals do not show the driver’s pool inventory. First identify the provider, package version, and runtime in use; instrumentation names and compatibility vary by version.
| Approach | Pool visibility | Pool identity | Physical connection activity | Version considerations |
|---|---|---|---|---|
| Microsoft.Data.SqlClient EventCounters | Active, free, pooled, stasis, and reclaimed connection counts | Active pool and pool-group counts; groups correspond to unique connection strings, with additional pool behavior for Windows integrated authentication | Hard and soft connect/disconnect counters | EventCounters require Microsoft.Data.SqlClient 3.0.0 or later and .NET Core 3.1+ or .NET Standard 2.1+. See Microsoft’s SqlClient EventSource guidance for framework-specific details. |
| Npgsql .NET metrics | Connection counts tagged as idle or used, plus maximum connections | Pool identifier; by default the pool name is the connection string, while data sources can have a stable explicit name | Metrics focus on pool state; do not assume they have SqlClient’s hard/soft counter semantics | Npgsql 10.0 renamed metrics to align with OpenTelemetry. Match dashboards and alert queries to the deployed version. See Npgsql metrics documentation. |
| EF Core metrics | No direct driver-pool inventory | Application-level EF activity, not pool identity | Query, save, and failure activity rather than provider physical connection rates | EF Core 9.0 introduced System.Diagnostics.Metrics reporting. See EF Core metrics documentation. |
Monitor a running ASP.NET Core process
SQL Server with Microsoft.Data.SqlClient
- Find the process ID of the running ASP.NET Core application on the host where it is running.
- Run
dotnet-countersagainst the provider EventSource:dotnet-counters monitor --counters Microsoft.Data.SqlClient.EventSource -p <process-id> --refresh-interval 3 - To narrow the view, use the counter-selection syntax supported by your installed
dotnet-countersversion and select counters such ashard-connectsandhard-disconnects. These EventCounters are distinct from the .NET Framework performance-counter approach; use Microsoft’s framework-specific guidance for other configurations.
The example refreshes every three seconds. Replace <process-id> with the application’s actual process ID.
PostgreSQL with Npgsql
- Identify the ASP.NET Core process ID and confirm the deployed Npgsql version.
- Monitor the Npgsql meter with
dotnet-counters:dotnet-counters monitor --counters Npgsql -p <PID> - Inspect connection counts by
idleandusedstate, the maximum connection count, and the pool or data-source identifier. If you use Npgsql 10.0, verify metric names against that version’s documentation before updating dashboards or alert rules.
Npgsql connections are pooled by default; disposing a connection returns it to the internal pool. Npgsql documents a maximum pool size of 100 since version 3.1, but this is a provider-specific default, not a universal ASP.NET Core limit. Verify the effective configuration and behavior for the deployed Npgsql version and application.
Interpret pool counts as a group
SqlClient: distinguish use, capacity, and connection churn
number-of-active-connectionscounts connections currently in use;number-of-free-connectionscounts ready pooled connections;number-of-pooled-connectionscounts connections managed by pooling.number-of-active-connection-poolsandnumber-of-active-connection-pool-groupshelp reveal pool proliferation. A group corresponds to a unique connection string. Windows integrated authentication can create separate pools per Windows identity within a group.hard-connectsandhard-disconnectstrack physical connections opened to and disconnected from database servers.soft-connectsandsoft-disconnectstrack connections retrieved from and returned to the pool.number-of-stasis-connectionscounts connections awaiting completion of an action and unavailable to the application.number-of-reclaimed-connectionscounts connections reclaimed through garbage collection after the application did not call Close or Dispose; repeated growth is a reason to inspect disposal paths.
High active use combined with few free connections and activity near the configured capacity is evidence of possible pool pressure. A high physical-connect rate relative to pooled reuse can indicate frequent connection establishment. Rising pool counts can point to many distinct connection strings or identities. Treat these as diagnostic clues, not proof of a single cause.
Npgsql: separate states and data sources
Read the idle and used counts alongside the maximum for each pool identifier. This lets you distinguish available connections from those checked out by application work and avoid combining separate databases or data sources into one misleading total. Npgsql uses the connection string as the default pool name; a data source can instead be given a more stable explicit name.
Use EF Core metrics as context, not pool telemetry
EF Core reports activity such as active DbContexts, queries, saves, and failures. These are useful for understanding application work, but they do not report the provider’s actual pool occupancy. EF Core states that driver connection pooling is separate from DbContext pooling. EF generally opens a connection near an operation and closes it afterward so it can return to the driver pool; enabling context pooling therefore does not reveal how many database connections are in use.
Use EF Core’s Microsoft.EntityFrameworkCore meter or legacy counters as supporting signals alongside driver metrics. A spike in query activity or failures can help explain a pool trend, but it is not a substitute for the provider’s connection counts.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
Correlate pool metrics with workload and database health
Collect provider metrics over time and compare them with request rates, database latency, and exceptions. When connection use rises, check whether the configured pool maximum is being approached, whether idle/free capacity remains, and whether physical connection creation is also rising. Segment by pool or data source wherever the provider exposes that dimension.
- High used/active counts with little idle/free capacity can be consistent with demand nearing configured capacity.
- High physical connection creation alongside low pooled reuse can indicate connection churn, but investigate the workload and provider configuration before assigning a cause.
- Pool growth across distinct identities or connection strings may make aggregate counts look different from a single-pool view.
- Slow database responses, connection failures, or a changing request rate can affect the same operational picture; correlate rather than treating any one counter as a diagnosis.
There is no universal pool-size threshold for ASP.NET Core. Defaults and pool semantics belong to each provider, so compare measured usage with the effective configuration for the exact driver and version.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
