hi can anyone help me to find how to effectively share database connection objects from .net connection pool. Mine is a web appplication and i have to limit the connection pool size to a particlar number too(say 20 connections) .so that requests from all client browser share this 20 connections.
And i have read that if more than 20 request comes at same time the rest of the requests are forced to wait till any conection in pool is freed. can i have a better way of managing this connections?
My main aim is to process as many requests in webserver without giving much overload on database server. can anyone help me please..
Connections will be automatically pulled from the pool based on the connection string, so if you don't vary your connection string for each user (or other purpose), you will be able to reuse a connection from the pool as soon as you are done with one (note that I am describing the behavior implemented by the pooling code and not anything that you have to do or worry about).
In order to be successful with this, you need to ensure that your connections are only open exactly as long as you need them to be and that they are always, always closed (this is general advice, not just specific to your situation).
If you find that you are running into the connection pool limit, you can trap this error and either tell the user to try again later or spin for a brief period and try the connection again.
The maximum pool size is 100 by default but if you want to reduce this number to just 20, you can specify it on your Connection String.
Using these parameters on your connection string:
Max Pool Size = 20
Pooling = True
You are restricting the pool size to 20.
See here for more details regarding ConnectionString.
Related
For SQL connection pool, why do we need to set up a min pool size? As connections will be saved in the connection pool and reused, why do we need to keep live connections specified by the min pool size? Thanks.
Opening and maintaining connections is expensive, so if you know that you need multiple connections (always) it's better to specify the MinPoolSize because then it's ensured that these connections are available.
Also, from MSDN:
If MinPoolSize is either not specified in the connection string or is
specified as zero, the connections in the pool will be closed after a
period of inactivity. However, if the specified MinPoolSize is greater
than zero, the connection pool is not destroyed until the AppDomain is
unloaded and the process ends. Maintenance of inactive or empty pools
involves minimal system overhead.
why do we need to keep live connections specified by the min pool size
As you may know that connection creation is resource intensive job. So, you may chose to set this to a small number such as 5 if your application needs consistent response times even after it was idle for hours. In this case the first user requests won't have to wait for those database connections to establish. You can read the details of pooling here.
In my C# application I connect to a MySQL database and run 10,000 queries. If I keep a connection to my database, these queries take roughly 14 seconds. However, if I rely on the connection pooling my queries take around 15 seconds. (I have run this test multiple times.)
// Connection pooling.
using (var connection = CreateConnection())
{
connection.ConnectionString = ConnectionString;
connection.Open();
Most samples on the net make use of the 'connect and close' construction above. However, it seems connection pooling is slower than keeping the connection. So the question is...
Q: Why should I use connection pooling?
Its a big debatable topic and would find many blog out there would tell that why we use Pool.
It will not slow things down. There is a lot of time spend on Connecting to DB Server and Hand shake and establishing communication between client and DB server.
So in multi request paradigm where many request are entertained by the server, it would be hard to establish and put on wait each client. POOL helps us that it gives us pre prepared connection and we use it and discard it. POOL get that connection and re-establish it for the next request.
But in a single threaded environment it is the other way around. POOL would be a very heavy resource for a single threaded env.
Q: Why should I use connection pooling?
Usually so that you can use more than one connection at a time. This is clearly important for web applications - you wouldn't want one user query to have to wait for another user's query to finish.
If you're writing a thick client application which talks straight to the database and you know you'll only ever have one query executing at a time, it's less important - but it's still global state, and that tends to be something you should avoid. You're doing several independent things - why would you want to constrain them to use the same connection?
Connection pooling is great for scalability - if you have 100 threads/clients/end-users, each of which need to talk to the database, you don't want them all to have a dedicated connection open to the database (connections are expensive resources), but rather to share connections (via pooling).
The using mini-pattern is also great for ensuring the connection is closed in a timely fashion which will end any transactions on the connection and thus ensure any locks taken by the transactions are released. This can be a great help for performance, and for minimising the potential for deadlocks.
If all your application does is run the 10,000 queries and then close again without any user interaction then it's fine to use one single connection.
However it's generally not a good idea to keep a database connection open while your application is just sitting there waiting for user input. This is where connection pooling is appropriate.
Pseudo code ...
<open connection>
<fetch data>
<close connection>
<user interaction with data ...>
<open connection>
<save updated data>
<close connection>
Depending on the language / database used, the second connection will be generated from the connection pool.
I don't know what kind of error is this.. I can't open my site anymore
Server Error in '/site' Application.
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.
please help me.. tnx
10 Tips for Writing High-Performance Web Applications
Connection Pooling
Setting up the TCP connection between your Web application and SQL Server™ can be an expensive operation. Developers at Microsoft have been able to take advantage of connection pooling for some time now, allowing them to reuse connections to the database.
Always close your connections when you're finished with them. Do not trust the common language runtime (CLR) to clean up and close your connection for you at a predetermined time. The CLR will eventually destroy the class and force the connection closed, but you have no guarantee when the garbage collection on the object will actually happen.
To use connection pooling optimally, there are a couple of rules to live by. First, open the connection, do the work, and then close the connection. It's okay to open and close the connection multiple times on each request if you have to (optimally you apply Tip 1) rather than keeping the connection open and passing it around through different methods. Second, use the same connection string (and the same thread identity if you're using integrated authentication). If you don't use the same connection string, for example customizing the connection string based on the logged-in user, you won't get the same optimization value provided by connection pooling. And if you use integrated authentication while impersonating a large set of users, your pooling will also be much less effective. The .NET CLR data performance counters can be very useful when attempting to track down any performance issues that are related to connection pooling.
Whenever your application is connecting to a resource, such as a database, running in another process, you should optimize by focusing on the time spent connecting to the resource, the time spent sending or retrieving data, and the number of round-trips. Optimizing any kind of process hop in your application is the first place to start to achieve better performance.
A timeout expired (something took longer than it should). Specifically, the timeout period elapsed prior to obtaining a connection from the connection pool. It turns out This may have occurred because all pooled connections were in use and max pool size was reached.
(You're using Connection Pooling and probably not closing your connections. After you are done with a SqlConnection or similar connection object, call .Close() on it)
I've created an old-style .ASMX web service and would like to know how the built-in ADO.NET connection pooling works with it.
The web service is not using a singleton pattern, so it is instantiated anew with every request. My question is will connections be removed from the pool after each service request, or are they kept in the pool across requests? My service is called very frequently but I don't want to be doing setup and teardown of connections every time, if it can be avoided.
I have read that the pool is maintained for the AppDomain, but I'm not sure if each request generates a new AppDomain or not.
I am also curious if it would be beneficial to set Min Pool Size (to a small number other than 0) in this case.
Anyone know?
No each request does not generate a new app domain. All the requests for that web site/application are in the same application domain, and so share the connection pool. Once the asmx request is finished with the connection, it returns it to the pool and the next request in line grabs it (assuming there isn't another connection in the pool readily available).
One point of clarification. You can have two different web applications which point to the same code, and are in different app domains. The two applications don't share anything (think about launching the same application twice).
I am also curious if it would be
beneficial to set Min Pool Size (to a
small number other than 0) in this
case.
So it can be beneficial depending on the application. Creating connections takes time, so having some ready allows you to forgo that. If you have request that say uses one connection, that might be fine to make a person wait for (it all depends on fast you want the application to respond). This can really come into play when you need to say 3 or 4 different ones (you get the point) open for one request. So why would you need multiple connections? What about one for accessing data and a separate thread for logging to the database (logging to the database vs a file is a totally different conversation)? Now you need two. There are multiple scenarios where this can come into play. Depending on your database server holding an open connection can be pretty cheap, so setting it to a small number can be a huge bang for your buck. (For the record I've seen scenarios where connecting to a database took several seconds, like 3-5, so in that case holding an open connection for a user was beneficial.)
This is for Max Pool Size
No it's not beneficial, because all requests to that service use the same pool (assuming the connections are using the same connection string, and aren't hitting different servers. Those have separate connection pools). Having no available connections, is a really fast and surefire way of crushing the performance of your service.
I've got a c# WINDOWS Application that is multi-threaded. It is my understanding that in a web environment, connections are pooled automatically. It is also my understanding that in a Windows app, this is not the case. Therefore, for a Windows app, the same connection should be used and not closed after each call, but instead closed when the app shuts down.
I'm curious though - is my correct? If it is, can two threads use the same connection to get a dataset from the DB at the same time or is that functionality queued up?
Thanks
The Connection Pooling is one feature of ADO.NET. Therefore the connections are already pooled. Not only in the web environment.
http://www.ondotnet.com/pub/a/dotnet/2004/02/09/connpool.html
It is my understanding that in a web
environment, connections are pooled
automatically. It is also my
understanding that in a Windows app,
this is not the case.
No, this is wrong, as m3rLinEz pointed out. Connections are always pooled.
Therefore, for a Windows app, the same
connection should be used and not
closed after each call, but instead
closed when the app shuts down.
You could keep a connection open for the duration of the application in a monolithic WinForms app. But it's better to use the standard pattern of opening/closing connections whenever you need them. Connection pooling means you won't notice a performance difference. And your data access code will be compatible with server applications such as ASP.NET.
If it is, can two threads use the same
connection to get a dataset from the
DB at the same time or is that
functionality queued up?
No. The ADO.NET classes (connection, command etc) are not thread-safe and should not be shared between threads without synchronisation. But as noted above, you should prefer the standard pattern for data access.
ok - so this assumption of mine was brought on by observation: When I tried a win app setup in the typical pool fashion, I always experience a 3-5 second delay while a real connection is established to the remote server. Even when I did an open, then a close, the next query would always have this delay.
When the server connects, it obviously doesn't establish a connection for each connection in the pool. Also, is the pooling mechanism smart enough to grab a connection that it knows is already open or is it possible for it to simply grab any random connection?
What is the default max connections in the pool?