I have heard the term connection pooling and looked for some references by googling it... But can't get the idea when to use it....
When should i consider using
connection pooling?
What are the advantages and
disadvantagesof connection pooling?
Any suggestion....
The idea is that you do not open and close a single connection to your database, instead you create a "pool" of open connections and then reuse them. Once a single thread or procedure is done, it puts the connection back into the pool and, so that it is available to other threads. The idea behind it is that typically you don't have more than some 50 parallel connections and that opening a connection is time- and resource- consuming.
When should i consider using
connection pooling?
Always for production system.
What are the advantages and
disadvantages of connection pooling?
Advantages:
Performance. Use a fixed pool of connection and avoid the costly creation and release of connections.
Shared infrastructure. If your database is shared between several apps, you don't want one app to exhaust all connections. Pooling help to limit the number of connection per app.
Licensing. Depending on your database license, the number of concurrent client is limited. You can set a pool with the number of authorized connections. If no connection is available, client waits until one is available, or times out.
Connectivity issue. The connection pool that is between the client and the database, can provide handy features such as "ping" test, connection retry, etc. transparently for the client. In worse case, there is a time-out.
Monitoring. You can monitor the pool, see the number of active connections, etc.
Disadvantage:
You need to set it up and configure it, which is really peanuts usually.
You should use connection pooling whenever the time to establish a connection is greater than zero (pretty much always) and when there is a sufficient average usage such that the connection is likely to be used again before it times out.
Advantages are it's much faster to open/close new connections as they're not really opened and closed, they're just checked out/in to a pool.
Disadvantage would be in some connection pools you'll get an error if all pooled connections are in use. This usually is a good thing as it indicates a problem with the calling code not closing connections, but if you legitimately need more connections than are in the pool and haven't configured it properly, you could get errors where you wouldn't otherwise.
And of course there will be other pros and cons depending on the specific environment you're working in and database.
In .NET, if you are using the same connection string for data access then you already have connection pooling. The concept is to reuse an idle connection without having to tear it down & recreate it, thereby saving server resources.
This is of-course taking into consideration that you are closing open connections upon completion of your work.
connection pooling enables re-use of an existing, but not used database connection. by using it you eliminate the overhead of the connection/disconnection to the database server. it provides a significant performance boost in most cases. the only reason i can think of not to use it is if your software won't be connecting frequently enough to keep the connections alive or if there's some bug in the pooling layer.
If we required to communicate with the database multiple times then it is not recommended to create a separate Connection Object every time, because creating and destroying connection object impacts performance.
To overcome this problem we should use a connection pool.
If we want to communicate with the database then we request a connection pool to provide a connection. Once we got the connection, by using it we can communicate with the database.
After completing our work, we can return the connection object back to the pool instead of destroying it.
The main advantage of connection pooling is to reuse the same connection object multiple times.
Related
According to this same question, the answer is pretty obvious: without .Net pooling on, the website has to re-connect to the database every time (every Postback time?).
However, there has to be other consequences, such as SQL memory leaks through over use of opening/closing the database without buffering?
With pooling turned OFF, does ASP.net have to recompile the ASPx/C files everytime? Plus reload all dlls?
If there are no direct and "dangerous" consequences, then I'd rather have a new connection each time and give the user better consistency of data directly from the database and not have to rely on buffers that could get corrupted. I just made that up - sorry, but really what are the real dangers?
Thank you
From the MSDN Connection Pooling
Connecting to a data source can be time consuming. To minimize the
cost of opening connections, ADO.NET uses an optimization technique
called connection pooling, which minimizes the cost of repeatedly
opening and closing connections. Connection pooling is handled
differently for the .NET Framework data providers.
On your question "
With pooling turned OFF, does ASP.net have to recompile the ASPx/C files everytime? Plus reload all dlls?" the answer is of cource not, the connection to the database have nothing to do with the compilation.
The pooling technique is transparent to your program. So also have nothing to do with SQL Memory leaks. You open and close your connection normally, and the server is handle the pooling.
can someone explain me that connection pooling in ADO.Net and Throttling in WCF is somewhat same.
They only seem similar.
SQL Connection Pooling is about reusing.
Connecting to a database server typically consists of several
time-consuming steps. A physical channel such as a socket or a named
pipe must be established, the initial handshake with the server must
occur, the connection string information must be parsed, the
connection must be authenticated by the server, checks must be run for
enlisting in the current transaction, and so on.
In practice, most applications use only one or a few different
configurations for connections. This means that during application
execution, many identical connections will be repeatedly opened and
closed. To minimize the cost of opening connections, ADO.NET uses an
optimization technique called connection pooling.
Connection pooling reduces the number of times that new connections
must be opened. The pooler maintains ownership of the physical connection. It manages
connections by keeping alive a set of active connections for each
given connection configuration. Whenever a user calls Open on a connection, the pooler
looks for an available connection in the pool. If a pooled connection
is available, it returns it to the caller instead of opening a new
connection.
WCF Throttling is about limiting how many service instances or sessions are created at the application level.
The main purpose for the throttling settings can be classified into the following two aspects:
Controlled resource usage: With the throttling of concurrent
execution, the usage of resources such as memory or threads can be
limited to a reasonable level so that the system works well without
hitting reliability issues.
Balanced performance load:
Systems always work in a balanced way when the load is controlled.
If there are too much concurrent execution happening, a lot of
contention and bookkeeping would happen and thus it would hurt the
performance of the system.
Two different concepts serving two different purposes.
When using web services (we're specifically using asmx and WCF) with ASP.NET, what is the best way to establish a SQL connection? Right now, I'm establishing a new connection for each web service call, but I'm not convinced this will be too efficient when there will be thousands of users connecting. Any insight on this topic would be much appreciated.
What you are doing is fairly standard.
Assuming you are using the same connection string, the connections will be coming from the connection pool, which is the most efficient way to get connections already.
Only doing the work required and closing the connection on each call is good practice.
One thing you can do is cache results and return the cached results for calls that are not likely to result in changed data over the life of the cache item. This will reduce database calls.
It is strongly recommended that you always close the connection when you are finished using it so that the connection will be returned to the pool. You can do this using either the Close or Dispose methods of the Connection object, or by opening all connections inside a using statement in C#. Connections that are not explicitly closed might not be added or returned to the pool.
You should add "Pooling = true" (and add a non-zero "Min Pool Size") to the connection string.
Let the provider handle connection pooling for you; don't try to do better than it - you will fail.
With the default connection settings the provider will maintain a connection pool. When you close/dispose, the connection is actually just released to the pool. it is not necessarily really closed.
By default, SqlConnections make use of connection pooling, which will allow the system to manage the re-use of previous connection objects rather than truly creating "new" connections for each request - up to a pool maximum value. And its built-in, so you don't really have to do anything to leverage it.
Writing your own pooling/connection manager is fraught with peril, and leads to all manner of evil, so it seems to me allowing the system to manage your connections from the pool is probably your best bet.
We are using NHibernate with OpenSessionInView pattern for our AspNet webapp.
Using ADO connection (SqlServer) we want to log in a different database every acces to pages. For that, do we need to open a connection at every "page load", execute the insert, then close the connection, or can we keep the same connection shared among all requests?
What about locks and concurrent access? We do only insert on this database.
Yes, I'd go with open --> insert --> close. The reason being that SQL Connections -and most DB connections, depending on the driver- are pooled so opening a new connection really implies getting a connection from the pool, which is inexpensive (unless you are running out of connections in the pool). If on the other hand you hold on to an open connection, you'll end up with a TON of concurrency issues since you'll have to synchronize the access to this connection object for every request. A nightmare, in other words. In fact, you'll be blocking your request and slowing things down considerably.
Again, you are not really improving the performance -quite the contrary- and you are complicating your app.
Does the same connection string used on two different physical servers hosting different web applications that talk to the same database draw connections from the same connection pool? Or are pooled connections confined to at the application level?
I ask because I inherited a 7 year old .NET 1.1 web application which is riddled with in-line SQL, unclosed and undisposed sql connection and datareader objects. Recently, I was tasked to write a small web app that is hosted on another server and talks to the same database and therefore used the same database connection string. I created a LINQ object to read and write the one table required by the app. Now the original .NET 1.1 app is throwing exceptions like
"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."
Maybe these are unreleated, but wanted to get your opinions to make sure I cover all my bases.
Thanks!
There is no way connections can be pooled between two separate machines. Your SQL Server will have a connection limit for total connections however.
This error is most likely occurring because the application is not returning connections to the connection pool. This can happen because the connection is not being disposed of correctly. This can happen due to poor code (does it use a using block, or a try catch finally?) or if using a SQLDataReader can cause the connection to stay open after the code to execute the SQL has exited.
Connection Pools are kept in your App Pool, so it shouldn't be possible for a separate machine to steal out of a separate boxes App Pool. Have a look here for some info on the connection pool. I'd also recommend slapping the performance counters on see bottom of this article to see what's going on in there a bit more.
Also might want to check the max number of connections on SQL Server. In management Studio
Right click on the Server name --> Properties --> Connections
look for "Maximum number of concurrent connections (0 = unlimited)"