I was wondering if anyone knows how to set up connection pooling for Sitecore 6 running on SQLServer 2005 ?
And is this a good idea to setup on a Sitecore solution? Or probably more correct, will there be any problems if setup incorrectly?
Any other comments or tips about this are also greatly appreciated.
The answers from Sitecores support:
By default, connection pooling is
enabled in ADO.NET (it means that we
don't need any connection string
parameters to enable it, parameters
are needed only to disable or to tune
the connection pooling). Thats why
there are no connection pooling
parameters in the default connection
strings. For more information please
refer to the following MSDN articles:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx
http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx
If you wish to tune the Database
Connection Pooling, you can add
appropriate parameters to the
connection strings.
Second reply after I asked some more about it:
Please see
http://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.80%29.aspx
When a connection is first opened, a
connection pool is created based on an
exact matching algorithm that
associates the pool with the
connection string in the connection.
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.
Following connection strings
parameters can be applied.
# Max Pool Size - specifies the
maximum size of your connection pool.
Default is 100. Most Web sites do not
use more than 40 connections under the
heaviest load but it depends on how
long your database operations take to
complete. # Min Pool Size - initial
number of connections that will be
added to the pool upon its creation.
Default is zero; however, 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. # Pooling - controls if
your connection pooling on or off.
Default as you may've guessed is true.
I hope this helps others.
The only mentioning about negative impacts I'm aware about is this.
Related
What does it do? How does it work? Why am I supposed to test the database connection before "borrowing it from the pool"?
I was not able to find any related information as to why I should be using it. Just how to use it. And it baffles me.
Can anyone provide some meaningful definition and possibly resources to find out more?
"test-on-borrow" indicates that a connection from the pool has to be validated usually by a simple SQL validation query defined in "validationQuery". These two properties are commonly used in conjunction to make sure that the current connections in the pool are not stale (no longer connected to the DB actively as a result of a DB restart, or timeouts enforced by the DB, or whatever other reason that might cause stale connections). By testing the connections on borrow, the application can automatically reconnect to the DB using new connections (and dropping the invalid ones) without a manual restart of the app and thus preventing DB connection errors in the app.
You can find more information on jdbc connection pool attributes here:
https://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Common_Attributes
I am using version 2.3.7 for Java 6. I have set maximumPoolSize to 200 and connectionTimeout to 30 s. I run into SQLTimeoutExceptions from BaseHikariPool.getConnection in one of our load test cases involving 70 simultaneous users uploading 10 files each. I turned on debug logging and obtained pool stats. So it would seem that the pool isn't being exhausted. Rather, HikariCP takes longer than connectionTimeout to create new connections. How can I debug this part of the process? The underlying data source is SQLServerDataSource version 4.1.
connectionTimeout is the maximum time to wait for obtaining connection from pool.
it is NOT time out for creating connection from data source. there is none.
You may want to consider reducing pool size. begin load testing with minimum and gradually increasing till SqlServer begins to take much longer to create connection.
check about pool size
HTH
It might be because in HikariCP opening a connection is a blocking call (
https://github.com/brettwooldridge/HikariCP/issues/1287)
You might find this option useful com.zaxxer.hikari.blockUntilFilled. With this option connection pool will open minimumIdle connections in parallel during initialization instead of lazy initializing connections.
I have a problem in WSO2 DSS, the database connection timeout is occurring after a few hours, then I have to stopping and starting the DSS to work.
The DSS version is 2.5.1
the database server is sql server
can help me ? Thank
Have you properly configured your datasource that's used in the dataservice descriptor file to enable "validationQuery" parameter to "SELECT 1" (validation query can vary depending on the RDBMS type used but for SQL server you can use the aforementioned query) and "testOnBorrow" parameter to "true"?
To give you a bit of context on the issue, any RDBMS type by default has a connection timeout value defined. For example, MySQL has a default timeout of 8 hours by default. When connection pooling is used in an application, the connections are kept in the pool once they are created without physically closing to reuse them. However, after the aforementioned period of time, the connections become stale and you have to validate the connections before using them. This is done by specifying a validation query which will be executed whenever a pooled connection is reused. and the "testOnBorrow" parameter comes handy as, when specified, it will validate the pooled connections when they are borrowed from the conneciton pool.
Cheers,
Prabath
I was wondering what is maxPoolSize for? what is minPoolSize for?
How do I know which property value to use for my database?
EDITED
I am using Oracle 10g, connecting with Hibernate and bitronix on windows OS.
minPoolSize is the minimum number of database connections being opened all the time, even when none of them are used. maxPoolSize on the other hand represents the maximum number of concurrent connection. Now:
Use minPoolSize to always keep few connections opened (even when idle) so that you don't have to wait for establishing a new network connection when request arrives to the system with low load. This is basically a set of connections waiting "for emergency"
maxPoolSize is much more important. If the system is under heavy load and some request tries to open maxPoolSize + 1 connection, the connection pool will refuse, in turns causing the whole request to be discarded. On the other hand setting this parameter to to high value shift the bottleneck from your application to the database server, as it has limited capacity.
I have a client-server app that uses .NET SqlClient Data Provider to connect to sql server - pretty standard stuff. By default how long must connections be idle before the connection pooling manager will close the database connection and remove it from the pool? What setting if any controls this?
This MSDN document only says
The connection pooler removes a connection from the pool after it has been idle for a long time, or if the pooler detects that the connection with the server has been severed.
A few years ago the answer beneath was the situation, but now it's changed so you can refer to the source and write up a summary :)
Old answer
This excellent article tells us what we need to know, using reflection to reveal the inner workings of connection pooling.
From how I understand it, 'closed' connections are cleaned up periodically on a semi-random interval. The cleanup process runs somewhere between every 2min and 3min 50s, but it needs to run twice before a 'closed' connection will be properly closed. Therefore after 7min 40s of being 'closed' the underlying sql connection should be properly closed, but it could be as short as 2min. At the time of writing the first connection pool created in a process would always have a timer interval of 3min 10s, so you'd normally see sql connections being closed somewhere between 3min 10s and 6min 20s after you call Close() on the ADO object.
Obviously this uses undocumented code so could change in future - or could even have changed since that article was written.
Please go through this:
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28VS.80%29.aspx
The part
"The following table lists the valid
names for connection pooling values
within the ConnectionString."
seems to be of your interest.