A thread on cfcdev today discussed whether ColdFusion debugging should ever be activated on a production server. The bottom line is no, never turn on debugging on a production server (you should never need to debug on a live server anyway, that’s what development and testing servers are for).
But what about enabling debugging and simply not listing any IP addresses so that debug information is not returned? Not good enough. While turning on and off the display of debugging does have a slight performance impact, the bigger impact is the gathering and tracking of debug output. The IP address list simply turns on or off output of accumulated debug information, but that information will still be maintained if debugging is enabled on the server.
Bottom line, do not turn on debugging on product servers. Ever.
No Debugging on Production Servers
10 responses to “No Debugging on Production Servers”
-
Unless you have a problem that you can’t replicate on the test and dev servers. Then what do you do?
-
Use a production monitoring tool for Java like Introscope http://www.wilytech.com/
-
Ben: Bah, Bug, and Hum. 🙂 I don’t turn on debugging for any length of time, but it’s sometimes necessary because real users uncover things that testing completely misses.
-
sure… turn off debugging, but let those nice easily exploitable error messages be.
-
This has been shown for CFMX, but is it also true for CF5?
-
You might also consider using a tool like log4j to insert debugging statements into your code at development time… then you can toggle debugging granularity and endpoints at runtime using a properties file or an xml config file. I wrote an article on using log4j with CFMX for CFDJ here:
Integrating log4j and CFMX
http://www.sys-con.com/coldfusion/article.cfm?id=700 -
Brian, Roger, logging is a better option in those cases, either writing to log files, or dumping data with <CFDUMP>.
Nathan, CF5 behaved the same way, although I don’t know if the performance delta was as significant as debugging and performance data was collected and managed in totally different ways.
Jared, I am not sure I understand your comment. Use <CFERROR> and <CFTRY>/<CFCATCH> to manage what is displayed. -
The real reason I started that thread is because the Macromedia documentation and support information is ambiguous on this subject. The docs and best-practice pages really need to be updated to make this crystal clear.
-
As stated in the thread, most developers do not have staging environments, either because they never bothered to set one up or because they are on shared hosting. From my experience, few even use a separate server for development, which causes shared hosting providers such as ourselves a lot of head aches.
Nevertheless, that’s the way it is, and I don’t see it changing. Consequently, the enormous performance hit that debugging causes in ColdFusion MX as compared to previous version, even for requests that aren’t being debugged, is problematic.
It would be nice if Macromedia could eliminate the performance hit on non-debugged requests so that, if we had to temporarily enable debugging on a production server for a customer, we could do so without affecting our other customers. As it stands now, performance is so poor with debugging enabled that we don’t enable it even on our development servers. -
Personally what we do is use the cferror tag in our application.cfm file. All we do is have a type exception and request for the cferror tag and when an error occurs it goes to an error page that uses cfdump to dump all the scopes and then email then to me.
I put this in every client site I write. It’s great because I get all the information I need to debug the problem. The visitor just sees a message that an error has occurred and will be fixed shorty, and I get to fix the problem before the client knows about it. By the way here is the code
application.cfm
===============
<cferror type="EXCEPTION" template="error.cfm" mailto="me@me.com">
<cferror type="REQUEST" template="error2.htm">
error.cfm
=========
<cfmail to="#error.mailto#"
from="error@rolist.com"
subject="Error has occured on #cgi.http_host#"
type="HTML">
<cfdump var="#url#">
<cfdump var="#form#">
<cfdump var="#error#">
</cfmail>
<cflocation url="/error2.htm" addtoken="No">
error2.htm
==========
<h2>An Error has occured</h2>
<p>The error has been emailed to the webmaster and will be fixed immediatly</p>
<p>Please click back on your browser</p>
Leave a Reply