On 12/29/05, Reed Powell <[EMAIL PROTECTED]> wrote: > Hello all - I've googled the heck out of this topic, and there are more > opinions than I can count! Is there any definitive info on whether it is > more efficient to put a CFTRY around an entire page's contents, with a > CFCATCH at the end to trap errors, or to simply have a CFERROR page > specified in application.cfm (and only use CFTRY/CFCATCH in specific pieces > of code that might need special error handling procedures)? In other words, > what is the performance cost for code that is executing within a CFTRY > block?
I'd go with the CFERROR and specific CFTRY/CATCH regardless of performance details. > I'm interested in this because the CF server that I've just recently started > working with seems to be having periodic performance problems (still trying > to determine what "periodic" actually means), and noticed that a lot of the > application's pages have a single CFTRY around them. In general with performance optimization, you figure out what you're working on -- without a good idea about *what* the issue is, you're shooting in the dark and just as likely to cause newer/different problems. I'd start by turning on slow page logging and slow query logging (if you db supports) as well to start. If you see pages that are consistently problematic, you know where to start spending some time -- if it seems truly random, you probably want to do some process/cpu/etc monitoring to see if its *another* process (e.g. the automatic virus scanner someone installed) that's eating your performance. And of course you need to cross-index this with load. As far as noticing a lot of CFTRY around entire pages, that to me seems like it's a bad idea as a general practice -- but you should get *consistent* performance, even if it's slower. > I've also noticed excessive use of CFOUTPUT tags. Is it worth consolidating > these to help performance? I've seen as many as 5 in a block of code that's > only 30 lines long, where only 1 was needed. > What about excessive # marks? It makes me crazy to see code like > <cfif #somevariable# eq "yes"> ... > But does that also make CF crazy? I'd think that this goofiness would not > actually filter down to the Jrun code that actually executes, right? Once you're compiled down to java classes, a lot of this stuff is irrelevant. Again, I think you're looking in the wrong place -- you don't even know for a fact that it's ColdFusion that's causing your problem. > Any good MX7 performance/tuning papers running around? I checked on the > macromedia website, and with google, but only found info on older versions. There are lots of things you can do to change performance -- move SQL to stored procs, cache things, tune the JVM, etc, etc. But all of it is pointless until you can narrow down *what* and *where* your problem is -- everything else is code-and-hope. In my experience, sporadic performance problems have nothing to do with <cfoutput> style, # marks, etc and far more with bad/poor/inefficient SQL (#1 issue with CF code imho). Or with other processes running on the server/network segment you forgot about (the massive backup that runs hourly, the automatic defragger/etc someone set up, the daily email blast that saturates your outbound pipe, etc). -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:227956 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
