Why does Mach II appear to run really slow?
- Overview
- Reason 1: Debugging Settings
- Reason 2: MACHII_CONFIG_MODE Setting
- Reason 3: Adobe ColdFusion Server Monitor Settings
Actually, Mach-II is very fast. The most likely reason Mach-II may appear to be running slow is that debugging has been enabled on your development or production server. ColdFusion debugging creates a significant amount of overhead when debugging complex CFC models.
Disable ColdFusion debugging output. This is the most common problem. The biggest offender is report execution timings which causes enormous overhead during the execution a request. We've seen execution times 100-200 times longer with debugging on. This is not a Mach-II defect or shortcoming, but a side-effect from the CFML engine's debugging output implementation.
For more accurate average timings, you can temporarily disable debugging on the server and use the TracePlugin (first included with the 1.1.0 version of the core framework files). Instructions for configuring and using the TracePlugin are in the header comments of the TracePlugin.cfc file. If you do not know how to disable ColdFusion debugging, please see the following FAQ for more information.
Another reason Mach-II may appear slow is that the value of the MACHII_CONFIG_MODE variable in the index.cfm file has been set to "1" (always reload). This causes Mach-II to reload your application on every request causing excessive overhead. By setting the config mode to "0" (dynamic reload), Mach-II will only reload the application if it detects a change in your configuration file. For more information about the config mode, please see What does the MACHII_CONFIG_MODE?
The server monitor bundled with Adobe ColdFusion 8 when used with certain monitoring settings such as memory tracking can bring any CFML application (Mach-II or not) to its knees. If you are experiencing severe performance problems with your Mach-II application, please check that the CF monitor is turned off. Memory tracking is very expensive process in the terms of CPU cycles. Certain monitoring tasks can be enabled with little to no perceivable overhead -- experimentation is required. We recommend that the server monitor is not enabled on production servers unless you need to debug a problem that is only reproducible on a production system.