Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsStart by identifying which pool is failing: a SQL Server connection pool or the outbound HTTP connection pool. They produce different symptoms and require different telemetry. A SQL pool timeout means the application could not check out a connection before the timeout; it does not, on its own, prove a leak.
First identify which connection pool is under pressure
ASP.NET Core applications may use several pools. Microsoft.Data.SqlClient manages pooled database connections to SQL Server. System.Net.Http handlers manage outbound HTTP connections. A database connection-acquisition timeout and HTTP requests waiting for a connection are different problems; do not use one subsystem’s counters to diagnose the other.
As an Amazon Associate I earn from qualifying purchases.
Capture the complete exception and stack trace, provider and package, .NET runtime version, affected endpoint or dependency, and timestamp. Note whether the incident coincided with a traffic spike, deployment, database failover, or scale event.
Recognize the SqlClient pool timeout
Microsoft documents this SQL Server exception text: System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached. It indicates that a caller could not obtain a pooled connection before the timeout. It does not explain why connections were unavailable. See Microsoft’s SqlClient troubleshooting guide.
#1 Best Overall
Recognize outbound HTTP queueing
HTTP pressure may appear as requests waiting in a queue, connection setup delays, or socket-related errors. Microsoft describes the pool behavior as follows: “When making a request, if there’s no connection immediately available in the connection pool, the request is added to a request queue to wait for an available connection.” Check HTTP metrics and tracing rather than SqlClient counters. See Microsoft’s networking tracing documentation.
Diagnose Microsoft.Data.SqlClient pool exhaustion
Collect counters during the incident
For .NET Core 3.1 or later, .NET Standard 2.1 or later, and Microsoft.Data.SqlClient 3.0.0 or later, Microsoft documents EventCounters. A starting command is:
dotnet-counters monitor --counters Microsoft.Data.SqlClient.EventSource[hard-connects,hard-disconnects] -p <process-id>Expand the counter list to include the measures relevant to the deployed provider version, such as:
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
number-of-active-connectionsandnumber-of-free-connectionsnumber-of-active-connection-poolsandnumber-of-active-connection-pool-groupsnumber-of-stasis-connectionsandnumber-of-reclaimed-connections
Hard-connect and hard-disconnect counters describe actual opens and closes to the server; soft-connect and soft-disconnect counters describe checking connections out of and returning them to the pool. Verify the names and availability against the exact runtime and provider version. Microsoft documents EventCounters in its SqlClient EventCounters reference. Its connection-pooling guide covers diagnosis and the Windows/.NET Framework-specific PerformanceCounter approach.
Interpret the pattern, not a single number
- Active connections near the configured ceiling and free connections near zero during acquisition timeouts are consistent with pool saturation.
- Growing active pool or pool-group counts can point to pool fragmentation, such as connections being created with differing configuration or identities.
- Reclaimed connections indicate connection objects were collected without explicit Close or Dispose. Inspect ownership and exceptional paths; the counter alone does not establish the full cause.
Correlate application counters with SQL Server sessions, waits, blocking, query duration, and server resource limits. Microsoft lists unclosed connections, slow queries, blocked transactions, excessive concurrency, pool fragmentation, and database capacity among possible causes.
Find why SQL connections remain unavailable
Inspect connection ownership and checkout duration
Ensure each opened SqlConnection is closed or disposed promptly, including when an exception interrupts work. In ordinary ADO.NET use, disposing a logical connection returns it to the pool; it does not necessarily close the underlying physical database connection.
Look for connections held while the application performs unrelated remote calls, streams a response, runs lengthy CPU work, or waits for user interaction. Check that data readers, commands, and transaction scopes complete, and keep transactions bounded. Measure checkout duration before raising the pool maximum. These checks help investigate documented causes; they do not imply that every exhausted pool has a disposal bug.
Check pool identity and application scale
SqlClient pools are local to each application process; separate replicas do not share a pool. Pool grouping depends on connection configuration, and Windows integrated security can create separate pools for distinct Windows identities even when the other connection-string settings match. Review connection-string construction and pool/group counts for unnecessary variations.
Budget database connections across every process and replica, not just one instance. Scaling out can multiply the aggregate number of connections the application may open, so a per-process pool limit is not the database-wide limit.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Diagnose outbound HTTP connection pressure separately
Measure connections, active requests, and queue time
Microsoft’s System.Net metrics reference lists http.client.open_connections, http.client.active_requests, http.client.request.duration, and http.client.request.time_in_queue. Group by destination and protocol where the instrumentation exposes those attributes, then compare queue time and open connections with request concurrency and downstream latency. Open connections includes both active and idle connections.
These metrics are documented as available starting in .NET 8. The http.client.open_connections instrument is an UpDownCounter in .NET 8–10 and an ObservableUpDownCounter starting in .NET 11. Check the System.Net metrics reference for runtime-specific details.
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 →Repair Windows errors before they cause bigger problemsFix Now →Separate queueing from connection setup
Experimental connection-setup tracing introduced in .NET 9 can help distinguish DNS, TCP, and TLS setup time from waiting for or using a pooled connection. The feature is experimental, so confirm runtime support before depending on it. Microsoft documents it in its networking tracing reference.
Best Value
- Applying all key ASP.NET Core components, including MVC for HTML generation, .NET Core, EF Core, ASP.NET Identity, dependency injection, and more
- Integrating ASP.NET Core with leading client-side frameworks, including Bootstrap
- ASP.NET Core code for implementing business logic and data transformations
- Handling configuration, routing, controllers, views, and common tasks (including posting forms and presenting data)
- Performing complementary tasks: error handling, logging, application design, authentication, localization, and more
Review client reuse, protocol, and per-server concurrency
Each HttpClient instance has its own connection pool. Microsoft recommends a supported reuse pattern, such as IHttpClientFactory or a long-lived client with an appropriately configured handler; the factory pools handlers. For bursts of HTTP/1.1 requests, consider a deliberate MaxConnectionsPerServer limit after measuring queueing and downstream capacity. HTTP/2 can multiplex requests over a connection, changing connection demand, but does not remove the need to monitor latency and service capacity.
See Microsoft’s HttpClient guidelines and IHttpClientFactory guidance. These are outbound HTTP controls, not fixes for a SQL connection-pool timeout.
Fix the cause and verify the change
For SQL Server connections
Address the cause indicated by the evidence: timely disposal and shorter holds, slow or blocked database work, fragmented pools, excessive concurrency, or database capacity. Microsoft’s troubleshooting guide lists increasing Max Pool Size as an option, but a higher ceiling can shift pressure to SQL Server. Before raising it, assess server capacity and aggregate connections across all application processes.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →For outbound HTTP connections
Use a reusable client and handler lifetime pattern, and tune per-server concurrency or protocol only after measuring queue delay, latency, and downstream load. A connection limit can bound connection attempts while also increasing the time requests wait; it is not automatically an improvement.
Compare before and after under representative load
Use the same signals on both sides of a change: SQL pool active/free connections and pool counts, database sessions and waits, hard/soft connect activity, or HTTP open connections and queue duration, as appropriate. Also compare error rate and request latency. Microsoft’s documentation provides diagnostic signals and configuration options, not a universal correct pool size or concurrency limit.
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.
