Connector tuning is an essential part of setting up a ColdFusion server. There are various configurations in connector that needs to be tuned. Incorrect values may lead to “Service Unavailable” or “Server too busy”. In this blog, we will discuss how to handle such errors caused by incorrect tuning and how to tune the connectors for the site correctly.
The connector setting may vary from site to site. It is very important to configure the connectors for your application appropriately. This blog will include connector tuning parameters for IIS. During installation, user can choose to configure connector for “Individual Site” or “ALL” sites in IIS connector configuration.
After the installation, the user can launch the “Web Server Configuration tool” and has the availability to create the connector for “Individual Site” or “ALL” sites in IIS.
When connector is configured with individual sites, separate connector for each site will be placed under {CF-Home}/config/wsconfig/{some no}/. Similarly for “ALL” configuration the connector is configured at global level, which means the same connector binary will be used across multiple sites.
The three most important parameters will be discussed here and will help us to understand the role of the same:-
- Reuse Connections
- Connection pool size
- Connection pool timeout
Re-use connections: – This setting determines the count of connections that can be re-used. When Tomcat connector makes a connection with Tomcat server, it does not closes the connection even after it finished serving the request. Instead it keeps the connection active, so that for the next request, the same connection can be re-used. This increases the performance by minimizing the overhead of creating new connection with tomcat server for every request. This settings needs to be tuned for connector configured with multiple sites. The max value for the re-use connection is determined based on the number of sites configured with same CF server and the load on each site.
The default re-use connection is 250.
Connection pool size: – This setting determines the maximum number of connections that can be created in the connection pool. When multiple requests arrive to the connector from IIS, connector creates new connections in the connection pool only if there are no free connections available in the pool. The connector will not create a new connection if connections reach the connection pool size limit. When connector is configured with “ALL” sites, the same connection pool will be used to serve the request for all sites. So the default value of the connection pool size, works well with the single site configuration, but fails to work well with “ALL” site configuration in some scenarios. Hence this value should be increased carefully based on the need and number of sites that are present within IIS.
The default connection pool size is same as, which is 250.
Connection pool timeout: – This setting determines the timeout value (in seconds) for idle connections in connection pool. This value must be in sync with the connectionTimeout attribute of your AJP connector in Tomcat's server.xml.
The default timeout for connection is indefinite, if not set in server.xml explicitly.
There are other parameters which CF connector inherits from Tomcat AJP connector. Please find the details of those settings from AJP documentation (http://tomcat.apache.org/connectors-doc/reference/workers.html)
The worker.properties is available at {CF-Home}/config/wsconfig/{some no}/ and the server.xml can be found at {CF-Home}/cfusion/runtime/conf/. Below are the changes required to tune the Site:-
- Open the worker.properties file, add below line as new entry worker.cfusion.connection_pool_size=500 (This is connection pool size inside connector which are available to handle request)
- Tune the entry for max_reuse_connections to appropriate value based on number of site. Optimal value is connection_pool_size / {no of site}
- Add another entry in new line worker.cfusion.connection_pool_timeout=60 (This value is idle connection timeout (in seconds), when sites are not under load connections will be recycled back to IIS)
- Now open the server.xml from {cf-home/cfusion/runtime/conf}, add/update the maxThreads=500 and connectionTimeout="60000" to connection node containing the AJP entry.
<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false"/>
- Now the AJP entry in server.xml should look like
<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="500" connectionTimeout ="60000"> </Connector>
There can be multiple use cases. Let us consider three most widely used scenarios:-
- Connector created with “ALL” OR with “Individual” Site and single site in IIS
- Connector created with “ALL” and multiple sites in IIS
- Connector created with “Individual” site and multiple sites site in IIS
Use Case# 1: Connector created with “ALL” OR with “Individual” Site and single site in IIS
In an idle scenario, where the user has only one site (configured with ALL or individual connector) and not running under high load, the worker.properties, can look like this
worker.list=cfusion
worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=250
worker.cfusion.connection_pool_size=500
worker.cfusion.connection_pool_timeout=60
And server.xml should look like
<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="500" connectionTimeout ="60000"> </Connector>
So, we added the connection_pool_size and connection_pool_timeout (in seconds) in the worker.properties. The corresponding connectionTimeout (in milliseconds) is added to server.xml along with maxThreads whose value is equivalent to the connection_pool_size in the worker.properties.
Use Case# 2: Connector created with “ALL” and multiple sites in IIS
Consider a scenario that the connector is created with “ALL” and there is only one site which is running under load. The default 250 re-use connections are utilized by site 1. Later on, the user adds another site in IIS.
Site 1 will make all 250 re-usable connections with ColdFusion and any request for new connection from site 2 will be ignored by ColdFusion. Hence it is required, to increase the re-use connection count to optimal value, so that site 2 does not starve for new connections. This can be achieved by configuring optimal value of max_reuse_connections count. Considering that the site 2 is not running under high load, 100 re-use connection will work. So the max_reuse_connections becomes 350 {250 (for site 1) + 100 (for site 2)}. But, it is a good practice, to start tuning the connection_pool_size first, and then the max_reuse_connections appropriately.
This case would require connection_pool_size=700, as max_reuse_connections= connection_pool_size / {no of site}. So, the worker.properties will look like this
worker.list=cfusion
worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=350
worker.cfusion.connection_pool_size=600
worker.cfusion.connection_pool_timeout=60
And server.xml should look like
<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="700" connectionTimeout ="60000"> </Connector>
Note: The connectionTimeout is in milliseconds
Use Case# 3: Connector created with “Individual” site and multiple sites site in IIS
Consider a scenario that the individual connectors are created for each site. There are three sites – Site 1 is running under high load, site 2 and site 3 running are under low load. For all the sites, there are individual connectors. Now, ideally in this scenario, we should start tuning with the site running under high load first. We can disable the timeout for high traffic sites, if we are not sure for timeout. If not defined, the default timeout for connection is indefinite. To start with, don’t specify the re-use parameter. Set the connection_pool_size=500 and monitor the site. Gradually increase the value by 100 and likewise, till the site is stable. Say, at connection_pool_size=800, the site is stable. Now, set the max_reuse_connections=270 (connection_pool_size / {no of site} i.e. 800/3=270 approx)
Site 1
worker.list=cfusion
worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=270
worker.cfusion.connection_pool_size=800
worker.cfusion.connection_pool_timeout=60
Site 2 and site 3 are running under low traffic, but are bind to same ColdFusion instance (cfusion in this case). The below settings should be optimal:-
Site 2
worker.list=cfusion
worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=100
worker.cfusion.connection_pool_size=250
worker.cfusion.connection_pool_timeout=60
Site 3
worker.list=cfusion
worker.cfusion.type=ajp13
worker.cfusion.host=localhost
worker.cfusion.port=8012
worker.cfusion.max_reuse_connections=100
worker.cfusion.connection_pool_size=250
worker.cfusion.connection_pool_timeout=60
And server.xml should look like
<Connector port="8012" protocol="AJP/1.3" redirectPort="8445" tomcatAuthentication="false" maxThreads="1300" connectionTimeout ="60000"> </Connector>
Note: The connectionTimeout is in milliseconds and the maxThreads is the value equivalent to summation of all the connection_pool_size(s). So, in this case maxThreads=1300 {800 (for site 1) + 250 (for site 2) + 250 (for site 3)}.
Some key points to remember:-
- The connector tool should always run with “Run as Administrator” feature, even if the user is from the Administrator group i.e.
Using the command line:-
![Connector Tool cmd]()
Using the GUI
![Connector Tool gui]()
- Any changes made to {CF-Home}/config/wsconfig/{some no}/, including isapi_redirect.dll or worker.properties, would require an IIS restart.
- Any changes made to {CF-Home}/cfusion/runtime/conf/server.xml requires “ColdFusion 11 Application Server” service restart.
- max_reuse_connections should always be less than or equivalent to connection_pool_size. It can’t be larger than the connection_pool_size.
- The above use cases are scenario based and may vary from site to site, depending upon the load, architecture and traffic on the site.
