I'm developing a high load web service that would provide as fast response as possible. The service should keep a bunch of connections to various databases for faster performance. I'm suggesting using connection pool for that. There may be connection problems to DB because we have a lot of remote access to the DB through VPN. As I have said, service should retain connection as long as possible.
What is the connection pool management algorithm?
I have a connection string:
Code:
User Id=inet;Password=somePassw0rd;Data Source=TEST11;Min Pool Size=5;Max Pool Size=15;Pooling=True
Then I simply open and close connection in my code. That's it.
At this moment everything is OK. There are five sessions on DB side. So I would kill a session to simulate connection problems. And in some cases the connection will be restored by pool manager and in some cases it won't.
If I kill all five connections they are never restored back.
How can I confiure pooling manager? Any settings for duration between checking DB connections?
I have used validate connection=true; it seems to work fine for me, but it would need some effort if reconnect to DB is needed, and therefore it would be more efficient to have an already good connection.
The component I used is devArt dotConnect for Oracle.
Thanks in advance!
I'm not sure what you're exactly looking after, but this can be useful: pools are automatically cleared if a connection is idle for some time or closed by the server. However you can force pool clearance, using OracleConnection's ClearPool or ClearAllPools methods (these methods usually exist on most ADO.NET providers, also it's not a requirement).
Note that if you're using Oracle 11g, DotConnect also supports Oracle's Database Resident Connection Pooling (DRCP) which is presumably the best way to do pooling, since it's provided by Oracle itself (I don't have any experience on this though).
Related
I have an Azure Function running on a consumption plan. When the function is under heavy load, I've been getting System.InvalidOperationException with the message 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.
I'm using dependency injection, and so far I've been injecting my Entity Framework Core DbContext by using AddDbContextPool. Is DbContext pooling recommended for Azure Functions, or should I rather use AddDbContext?
The connection string to my SQL Server only specifies the server and authentication, meaning that connection pooling should also be enabled by default. Is connection pooling also recommended for Azure Functions?
Apparently, AddDbContextPool is not the same as connection pooling. Instead, it's a pool of dbcontexts: https://stackoverflow.com/a/48444206/5099097
Also, according to https://learn.microsoft.com/en-us/azure/azure-functions/manage-connections#sqlclient-connections, EF and EF Core implement connection pooling by default since they use ADO.NET and that's the default for ADO.NET.
Your function code can use the .NET Framework Data Provider for SQL
Server (SqlClient) to make connections to a SQL relational database.
This is also the underlying provider for data frameworks that rely on
ADO.NET, such as Entity Framework. Unlike HttpClient and
DocumentClient connections, ADO.NET implements connection pooling by
default. But because you can still run out of connections, you should
optimize connections to the database. For more information, see SQL
Server Connection Pooling (ADO.NET).
I think your best bet is to dial down the concurrency like you already said in the comments, but in addition to that I think it's important to note that connection pooling is managed on the client side (Azure Func in this case): SQL Server: where is connection pool: on .net side or server side. So while your func app will be able to take advantage of connection pooling, each instance of the func app will have its own connection pool as it scales out. So the scalability benefits of connection pooling aren't as great as if it were one client side app managing a single connection pool.
Therefore, to get greater benefits from connection pooling per instance of your func app you should do more work per Service Bus trigger. For example, batching several queries together under the same trigger instead of 1 query per trigger. Also, if you're doing writes in other triggers, you can batch several update/insert operations together in 1 func app trigger. According to this, 42 non-query operations is the optimal size per batch in EF Core: https://learn.microsoft.com/en-us/ef/core/performance/efficient-updating#batching
But even better than that is using table value parameters for making bulk updates to hundreds/thousands of records at a time. After I made these changes my errors from hitting the connection limit went away.
Good day!
I'm developing a web application to access an ancient Informix 7.31.UC4 database with IBM Informix Client SDK for .NET. The system is currently built so that each user must connect with his own DBMS credentials (not Identity credentials) which means that I either must
a) connect with different credentials upon each request which is way to slow (over 5 sec for creating, opening and closing connection, not to say about queried themselves)
or b) somehow store connections in Dictionary by username and make use of their pooling and avoid multiple connections for the same user in different sessions
or c) store a connection for each Session.
The first approach is unacceptable for its low speed. The second and the third approaches give me no way of disposing the IfxConnection : IDisposable, which makes me cry.
Am I missing a way to dispose objects stored in session upon session abandoning or ending? Is there a way to take advantages of the connection pooling in case of multiple sets of credentials? Or is it just that the system has been ill-designed in the first place and I should not care?
The only way I currently see is to create an Informix user with sufficient rights and keep one connection with pooling and use another SQLServer database for storing users and roles while ruling all the rights and roles at Controller level, but database designer won't hear me out.
P.S. I've seen several questions about disposable objects in sessions, all say it's bad, but I see no other option.
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 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?