This section of the ColdFusion Administrator is particularly important for server performance. Therefore, the settings discussed here will have a direct impact on user experience. Optimal values for most of the settings in this section can only be determined by observing your application under simulated or controlled load conditions. A tool is used to generate a large number of artificial requests against your server while watching certain metrics. Then, a setting is adjusted, and the tests are replayed to watch for performance changes. As with all advice presented in this guide, we strongly recommend extensive testing in an isolated environment prior to rolling out any updates to your production systems.

Request Limits –

Simultaneous Requests

ColdFusion is a multi-threaded server. When a request is passed to ColdFusion, it is assigned to a thread for processing. This means the system is capable of concurrently handling a multitude of requests simultaneously via these threads (generally one thread per request, although there are exceptions). The value in the above setting dictates how many threads the server will allocate for requests before they become queued and must wait.

This single value is one of the most important performance settings in ColdFusion. For the sake of performance, it is critical to get this value right. The optimal value can only be determined through rigorous testing of your application while under simulated load. Once the system is stressed, this value can be experimented with to find the sweet spot where the system is performing optimally. Learn more about performance tuning ColdFusion here.

The default is 25.

Request Limits – 

Flash Remoting Threads

Similar to threads, the number of Flash Remoting requests that can also be tuned independently. Unless you are serving data to a Flash application, this setting can safely be ignored. The default setting is 5.

Request Limits – 

Web Service Threads

The number of Web Service requests the system will process concurrently is set here. If you are servicing such requests, this value should be determined through load testing of your application in an isolated environment. The default setting is 5.

Remote Function Calls Threads

This setting depends on the nature of your application. If the application is serving up an API via Web Service, it is possible you are invoking CFCs directly. It is also possible to configure ColdFusion to invoke CFCs directly with an HTTP request. If your application meets these criteria, this setting should be tuned. Again, only through a structured load testing and tuning regimen can the optimal value be determined. The default setting is 15.

Tag Limit Settings – 

Report Threads

ColdFusion ships with extensive report generation capability, exposed through the cfreport tag. The creation of reports using this tag can be very resource intensive, depending on the size and scope of your reports. In order to avoid cannibalizing all server resources during report generation, you may limit the number of threads available to that process. The maximum number of ColdFusion reports that can be processed concurrently will depend on the nature of your application(s). The optimal value for this setting can be determined through load testing and tuning. The default setting is 8.

Tag Limit Settings – 

CFThread threads

Requests handled by ColdFusion are assigned to a single thread. However, it is possible to offload some processing to additional threads asynchronously through the use of cfthread. But, with great power comes great responsibility. If not used carefully, your application can spawn more threads than your system can handle, thus queuing additional requests. This setting allows an administrator to manage the allocation of threads to cfthread requests. Note if you are running ColdFusion 2018 Standard edition, the maximum number of concurrent cfthread‘s which can be executed is 10. The Enterprise edition carries no such limitation.

Queue Timeout Settings – 

Timeout Queued Threads

ColdFusion will attempt to simultaneously process as many requests as it can (up to the Maximum Number of Simultaneous Template Requests setting). If requests are received when there are no available threads, ColdFusion will add these requests to a first-in-first-out queue. Once a thread becomes available, ColdFusion will pop a request off the queue for processing. This setting determines how long requests will sit in the queue before they are killed with a 500 error. It is a best practice to keep your application responsive to the user, even if that means returning an error to them. Depending on your application, you may want to consider lowering this number to provide more timely feedback that a user should retry their request.

However, if you are routinely dropping requests from the queue you will need to investigate how to improve your request time or scale your infrastructure to accommodate the load.

The default setting is 60 seconds.

Queue Timeout Settings – 

Request Timeout

In the event your server is fully engaged serving requests and all threads are busy, the server will queue the additional requests. When those requests timeout, the user will be presented with a generic 500 error. This is not the greatest user experience.

This setting allows you to specify a static HTML page informing the user of a problem. This page must be declared relative to the site root. For example: “/CFIDE/request-timeout.html”.