SQL Server TCP settings and why not using connection pooling is a bad idea

I’ve been talking to a contact who has been experiencing some connection issues with a large scale SQL Server implementation. The database is serving as the back-end to a well used Internet site. They reported that during the course of normal operation that they’d received dropped TCP connections and difficulty in achieving automatic failover at the database layer. They’d investigated the possibility of running without database connection pooling enabled. I advised that this was not a suitable idea. Afterwards this support article was found: support.microsoft.com/kb/328476

The article advises:

Note that Microsoft strongly recommends that you always use pooling with the SQL Server drivers. Using pooling greatly improves overall performance on both the client side and SQL Server side when you use the SQL Server drivers. Using pooling also considerably reduces network traffic to the computer that is running SQL Server. For example, a sample test that used 20,000 SQL Server connection opens and closes with pooling enabled used about 160 TCP/IP network packets, for a total of 23,520 bytes of network activity. With pooling disabled, the same sample test generated 225,129 TCP/IP network packets, for a total of 27,209,622 bytes of network activity.

The moral of the story – connection pooling is advised and think carefully before turning off.