

If you’re not familiar with using Perfmon or the sys. This result set contains a number of columns, which can help you troubleshoot any issues. If you prefer a more SQL-centric view of things, you can get the number of user connections with this query: SELECT * If I plot them, I'll see the count over time. You also get it via Performance Monitor directly by looking at these counters. Right now I have a whopping total of 5 connections open. Here’s a query to retrieve the perfmon counter from within SQL. My view is that as long as you use the same counter or query consistently it doesn’t matter a lot whether system connections are included. The user connections counter refers to connections that are not system connections. You have two choices you can query a system DMV or use the perfmon counter called “User Connections” (which is also available from a DMV). Let’s start by looking at our options for monitoring the connect count. If you’ve ever seen calls to sp_reset_connection in Profiler that’s a sign that connection pooling is being used. That seems a little illogical given that connections are expensive to open, but there is some behind the scenes magic called connection pooling that allows us to keep connections open and reuse them while making it seem like we’ve closed the connection. In older client/server applications you might see each desktop application open and sustain a connection for the length of a user session, but in most modern apps (web apps, n-tier, etc) connections are consumed in a pattern often referred to as open-use-close where a connection is opened, a query is executed, and then the connection is closed. Connections are somewhat expensive to open and they require an ongoing memory allocation so we’re going to prefer a lower connection count (and well short of the maximum of 32767 per instance). In the world of SQL Server a connection is what is allows an application or user to authenticate, submit queries, and receive results. My goal today is to make the case for monitoring the number of connections as one of those key metrics. When it comes to monitoring SQL Server there are a lot of metrics available to us - hundreds! In practice while we monitor quite a few, we rely on a handful to help us understand the current and long term health of a server.
