MinPoolSize behaviour

  • Thread starter Thread starter Robert Scheer
  • Start date Start date
R

Robert Scheer

Hi.

I think I have basic questions here, but maybe I'm on the right group.

Suppose I set the MinPoolSize of a connection to 10. Then I open and
close the connection for the first time in my application. When I
close the connection, will ado.net creates 10 connections in advance?

Since the MinPoolSize says 10, does it mean that I will have 10
connections in my pool forever?

Thanks,
Robert Scheer
 
Hi,

when the connection pool is created (one pool exists per unique connection
string used), the minimum count of connection objects, given in Min Pool
Size, are created and added to the pool.

More information about the connection pooling:
http://msdn.microsoft.com/library/d...nectionpoolingforsqlservernetdataprovider.asp

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist

Hi.

I think I have basic questions here, but maybe I'm on the right group.

Suppose I set the MinPoolSize of a connection to 10. Then I open and
close the connection for the first time in my application. When I
close the connection, will ado.net creates 10 connections in advance?

Since the MinPoolSize says 10, does it mean that I will have 10
connections in my pool forever?

Thanks,
Robert Scheer
 
Hi,
I've read this paper on M$ sites, and first answer to Roberts question is
yes - there are objects created in advance,
but there is another question for which answer I also looked up some time
ago..
Is the pool created forever ?
That's means, if I create sqlConnection which one connection string. Then
use open(), close() and even kill the application this pool still will be
there ?
Time needed to make open connection at first time when I run my test
application is around 289ms, when I close connection and open it (before
restarting app.) it is around 0ms. Now when I restarted then I agein obtain
ca. 300ms - that's seems like this pool is dead.

But at Performence Monitor -> .NET CLR Data, counter Current # connection
pools - still is growing, no (as I asume) still be around 0 - if there is no
running app. or 1 if I run one (or x if I run X more)...

So where I'm wrong ? Pools are immortal, or sth like this ? ;-)
 
Too many issues, lets take them one at a time:

Performance monitor: this accumulates, there is a kb available on this
somewhere and it is not our fault, unfortunately this makes this feature
very unreliable.

Min Pool Size, The first time you open a connection we will open the 1
connection and return, on a background thread we will start to open
connections on the server until Min pool size is reached, Min Pool Size is
guaranteed from that point on.

Is the pool created forever? the "pool" is created per Process per
Appdomain, if the process or appdomain where the pool resides goes away so
does the pool. There is an extremely good article on how pooling works here:
http://www.sys-con.com/dotnet/article.cfm?id=483 I highly recommend reading
this article by Guy Smith-Ferrier.

Hope this helps
 
Hi Angel.

Really, a very good article. Do you know of any other article that
discuss the Connection Lifetime parameter in more detail?

Thanks,
Robert Scheer


Angel Saenz-Badillos said:
Too many issues, lets take them one at a time:

Performance monitor: this accumulates, there is a kb available on this
somewhere and it is not our fault, unfortunately this makes this feature
very unreliable.

Min Pool Size, The first time you open a connection we will open the 1
connection and return, on a background thread we will start to open
connections on the server until Min pool size is reached, Min Pool Size is
guaranteed from that point on.

Is the pool created forever? the "pool" is created per Process per
Appdomain, if the process or appdomain where the pool resides goes away so
does the pool. There is an extremely good article on how pooling works here:
http://www.sys-con.com/dotnet/article.cfm?id=483 I highly recommend reading
this article by Guy Smith-Ferrier.

Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.


Stefan Turalski (stic) said:
Hi,
I've read this paper on M$ sites, and first answer to Roberts question is
yes - there are objects created in advance,
but there is another question for which answer I also looked up some time
ago..
Is the pool created forever ?
That's means, if I create sqlConnection which one connection string. Then
use open(), close() and even kill the application this pool still will be
there ?
Time needed to make open connection at first time when I run my test
application is around 289ms, when I close connection and open it (before
restarting app.) it is around 0ms. Now when I restarted then I agein obtain
ca. 300ms - that's seems like this pool is dead.

But at Performence Monitor -> .NET CLR Data, counter Current # connection
pools - still is growing, no (as I asume) still be around 0 - if there is no
running app. or 1 if I run one (or x if I run X more)...

So where I'm wrong ? Pools are immortal, or sth like this ? ;-)

--
best regards
stic



http://msdn.microsoft.com/library/d...nectionpoolingforsqlservernetdataprovider.asp
 
You can try searching on google groups for my name and connection lifetime
*grin* I have tried to explain this quite a few times with little success.

The takeaway points are :
We should never have called it connection lifetime, in the whidbey alpha we
have renamed it to something like LoadBalanceTimeout (of course we will
continue to support the old connection string keyword as an alias).

It is hard to explain what it does, but it is simple to explain why it is
there.
(Scenario) We have a Database Cluster (if you are not using clusters you can
safely ignore the rest of the post) that is under a fair amount of load, we
notice this and bring up a couple of servers to balance the load. Happy
ending right? well not quite. After an hour or so we notice that the cluster
is still under the same load and that the new servers we brought up are just
idling, what went wrong?

Problem: We are using Pooled connections on the middle tier, the connections
are always busy (your cluster is under load) so they never get recycled.
Since we never open new connections we never load balance into the new
servers you brought up. This is bad.

Solution: Add a connection string keyword that allows me to throw away
connections to give a chance to load balance my application. Connection
Lifetime is born, every time you close a connection (every time we place a
connection in the pool that is) we will check to see if it has been around
for time>Connection Lifetime, if it has we throw it away.

Hope this helps,

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.

Robert Scheer said:
Hi Angel.

Really, a very good article. Do you know of any other article that
discuss the Connection Lifetime parameter in more detail?

Thanks,
Robert Scheer


"Angel Saenz-Badillos[MS]" <[email protected]> wrote in message
Too many issues, lets take them one at a time:

Performance monitor: this accumulates, there is a kb available on this
somewhere and it is not our fault, unfortunately this makes this feature
very unreliable.

Min Pool Size, The first time you open a connection we will open the 1
connection and return, on a background thread we will start to open
connections on the server until Min pool size is reached, Min Pool Size is
guaranteed from that point on.

Is the pool created forever? the "pool" is created per Process per
Appdomain, if the process or appdomain where the pool resides goes away so
does the pool. There is an extremely good article on how pooling works here:
http://www.sys-con.com/dotnet/article.cfm?id=483 I highly recommend reading
this article by Guy Smith-Ferrier.

Hope this helps
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.


Stefan Turalski (stic) said:
Hi,
I've read this paper on M$ sites, and first answer to Roberts question is
yes - there are objects created in advance,
but there is another question for which answer I also looked up some time
ago..
Is the pool created forever ?
That's means, if I create sqlConnection which one connection string. Then
use open(), close() and even kill the application this pool still will be
there ?
Time needed to make open connection at first time when I run my test
application is around 289ms, when I close connection and open it (before
restarting app.) it is around 0ms. Now when I restarted then I agein obtain
ca. 300ms - that's seems like this pool is dead.

But at Performence Monitor -> .NET CLR Data, counter Current # connection
pools - still is growing, no (as I asume) still be around 0 - if there
is
no
running app. or 1 if I run one (or x if I run X more)...

So where I'm wrong ? Pools are immortal, or sth like this ? ;-)

--
best regards
stic


U¿ytkownik "Teemu Keiski" <[email protected]> napisa³ w wiadomo¶ci
Hi,

when the connection pool is created (one pool exists per unique connection
string used), the minimum count of connection objects, given in Min Pool
Size, are created and added to the pool.

More information about the connection pooling:
http://msdn.microsoft.com/library/d...nectionpoolingforsqlservernetdataprovider.asp
--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist

Hi.

I think I have basic questions here, but maybe I'm on the right group.

Suppose I set the MinPoolSize of a connection to 10. Then I open and
close the connection for the first time in my application. When I
close the connection, will ado.net creates 10 connections in advance?

Since the MinPoolSize says 10, does it mean that I will have 10
connections in my pool forever?

Thanks,
Robert Scheer
 
Back
Top