Settings on this page manage how ColdFusion caches cfm and cfc files, as well as the database cache invoked with cachedwithin or cachedafter.
As you are probably aware, ColdFusion runs on top of Java. When a page is first requested, the underlying templates are compiled into Java classes and stored on disk. On each page view, ColdFusion diligently checks if that page has been compiled yet. If it has, it also checks if the compiled version is current (there haven’t been any changes to it or its dependencies since it was last called).
This setting limits the number of templates cached using template caching. If the cache is set to a small value, ColdFusion might re-process your templates. If your server has a sufficient amount of memory, you can achieve optimum performance by setting this value to the total number of all of your ColdFusion templates. Setting the cache to a high value does not automatically reduce available memory because ColdFusion caches templates incrementally. The default setting is 1024.
On every page request, ColdFusion will first check if the page being requested has been changed since it was last executed. If it has been changed, ColdFusion will recompile it. This introduces a slight overhead with every page request. During development, this is exactly the behavior you want. When a file is updated, the changes must be immediately reflected. However, once your code makes it to production it should not change that often.
Enabling the trusted cache allows ColdFusion to bypass this check. ColdFusion will only compile files one time, and then trust that the version it has compiled is the latest. By removing this verification step during the execution of a request the overall performance of your site can be improved. For sites where templates are not updated during the life of the server, file system overhead is reduced. Not bad for a single checkbox.
However, there are a couple caveats to consider when considering this feature. This feature should only be enabled in your production environment. Any changes to files will not be recognized until the trusted cached is purged (which is explained below). Second, your production deployment process will need to be updated to purge the trusted cache everytime new code is pushed to your server. The default for this setting is disabled.
If this setting is disabled, ColdFusion will check the template for changes every time it is accessed within the same request. By enabling Cache template in request, ColdFusion will only inspect the template the first time it is called for that request. Subsequent calls during the request will not trigger that inspection.
Enabling this setting reduces disk I/O and may yield performance improvements for your application. Your application requirements will dictate whether this setting is appropriate.
The default for this setting is enabled.
Enabling this option prevents the server from resolving the component path on every request. It is generally advisable to enable this setting to prevent unnecessary disk I/O. By default, this option is enabled.
The performance gains realized after enabling this option are typically minimal. We do recommend ticking that box, as it does provide an often overlooked benefit. When enabled, this setting will save the compiled Java class files to disk (C:\ColdFusion2018\cfusion\wwwroot\WEB-INF\cfclasses). By inspecting the timestamps on these files we can discern which ColdFusion code is actually being actively used, and what may be stale code. This is often used during security engagements to identify and purge obsolete code from the system. The default for this setting is enabled.
We rarely see this setting enabled, as most systems are multi-homed (serving multiple sites) and this setting is incompatible. If your server is a single-site installation then this setting will tell CF to cache page paths which provides improved performance. You must restart the server for this change to take effect. The default is disabled.
