The Oracle Utilities Application Framework uses connection pooling to manage the number of connections in the architecture. The advantage of the pools is to be able to share the number of connections across concurrent users rather than just allocating connections to individual users, which may be stay allocated whilst they are not active. This ensures that the connections allocated are being used therefore the number of connections can be less than the number of users using the product at any time.
The configuration of the pool has a number of configuration settings:
- Minimum Size - This is the initial size of the connection pool at startup. For non-production this is typically set to 1 but in production this is set to a size that represents the minimum number of concurrent users at anytime. The number of connections in the pool will not fall below this setting.
- Maximum Size - The maximum number of connections to support in the pool. This number typically represents the expected pack concurrent connections available in the pool. If this number is too small, connections will queue causing delays and eventually connections will be refused against the pool.
- Growth rate - This is the number of new connections to add to the pool when the pool is busy and new connections are required up to the Maximum Size. Some pool technologies allow you to configure the number of connections to add each time.
- Inactive detection - Pools will have a collection of settings to define when a connection in the pool can be shutdown due to inactivity. This allows the pool to dynamically shrink when traffic becomes off peak.
There are typically two main connection pools that are used in the product:
- Client Connection Pool - These are the number of connections between the client machines (browser, web services client, etc) and the server. This connection pool can be direct or via proxies (if you are using a proxy generally or as part of a high availability solution). Now, if you are using Oracle WebLogic this is managed by default by a Global Work Manager, which has unlimited connections. While that sounds ideal, this means you will run into a possible out of memory issue as the number of connections increases before you hit the connection limit. It is possible to use configuration to specify Work Managers to restrict the number of connections to prevent out of memory conditions. Most customers use the Global Work Manager with no issues but it may be worth investigating Work Managers to see if you want to use the Capacity Constraint or Max Threads Constraint capabilities to restrict connection numbers.
- Database Connection Pool - These are the number of connections between the product and the database. The connection pools can use UCP or JDBC datasources. The latter uses Oracle WebLogic JNDI to define the attributes of the connection pools as well as advanced connection properties such as FCF and GridLink. The choice to use UCP or JDBC data sources will depends on your site standards and how often you want to be able to change the connections to the database. Using JDBC datasources is more flexible in terms of maintenance of pool information whereas UCP is more desirable where fixed configurations are typical.
Additionally if you are using a proxy to get to the product, most proxies have connection number restrictions to consider when determining pool sizes.
So when deciding the size of the pools and its attributes there are a number of configurations:
- The goal is to have enough connections in a pool to satisfy the number of concurrent users at any time. This includes peak and non-peak periods.
- When designing pool sizes and other attributes, remember wasted connections are a burden on resources. Having the pool be dynamic will ensure the resources used are optimally used as traffic fluctuates.
- Conversely, the establishment of new connections is an overhead when traffic grows. In terms of overall performance the establishment of new connections is minimal.
- The connections in the pool are only needed for users actively using the server resources. They are not used when they are idle or using the client aspects of the product (for example, moving their mouse across the screen, interacting with non-dynamic fields etc).
- Set the minimum number of connections to the absolute minimum you want to start with or the number you want to always have available at all times. It is not recommended to use the non-production default of one (1) as that would get the pool to create lots of new connections as traffic ramps up during the business day.
- Set the maximum number to the expected peak concurrent connections at any time with some headroom for growth. Pool connections that are active take resources (CPU, memory etc) so making sure this number if reasonable for your business. Some customers use test figures as a starting point, talk to their management to determine number of peak user connections or use performance testing to decide the figure. I have heard implementation partners talk about rules of thumb where they estimate based upon total users.
- Set the inactivity to destroy connections when they become idle for a period of time. This value for the period of time can vary but generally a low value is not recommended due to the nature of typical traffic seen onsites. For example, generally partners will look at between 30-60 seconds inactivity time and maybe more. The idea is to gradually remove inactive connections as traffic drops in non-peak.
- If the pool, allows for specification of the number of new connections to create, consider using a number other than one (1) for online channels. Whilst this low value seems logical, it will result in a slower ramp up rate.
- Monitor the connection pools for the connection queuing as that may indicate your maximum is too low for your site.
One other piece of advice from my troubleshooting days, do not assume the figures you use today will be valid in a years time. I have found that as the product implementation ages, end users will use the product very differently over time. I have chatted to consultants about the fact I have personally seen traffic double in the first 18 months of an implementation. Now, that is not a hard and fast rule, just an observation that when a product is initially implemented end users are conservative in its use, but over time, as they get more accustomed to the product, their usage and therefore traffic volume increases. This must be reflected in the pool sizing and attributes.