One of our DBAs complained to our team that he noticed about a dozen sleeping connections are virtually permanent. Each of them indicates a very short query (a single record from a single record was returned filtered by its clustered PK).
My assumption is that the cause is the usage of the ADO.NET connection pooling and the application that makes the same query quite often.
I am trying to find out if these sleeping connections can have a meaningful impact on the SQL Server performance. By default, the ADO.NET connection pool has a limit of 100 connections, so my assumption is that a dozen sleeping connections should be negligible.
I could only find information in this thread:
The minimum cost per sleeping session is on the order of 32kb of RAM - very very modest!
There is probably some minuscule additional cost in CPU overheads but it is going to be nearly undetectable even for 10,000 sessions.
On the matter of session/connection overheads, SQL Server is very well behaved!
Is this information accurate?