Systematic diagnosis of CF memory use
[double post] I've inherited a CF app with an apparent memory leak. Does anyone have a systematic plan to diagnose and eliminate possible causes? The Macromedia Knowledge Base article http://www.macromedia.com/v1/Handlers/index.cfm?ID=15014Method=Full is helpful, but doesn't provide a plan of attack. Of the list of causes on that page, the application has possible causes (that I know about) -- unlocked shared-scope variables, large cached queries, large record sets, and COM objects. I strongly suspect that it's the unlocked shared-scope variables, but it's a big undertaking to correct this and I need to show the boss that I've eliminated other causes before undertaking this effort. Any suggestions? = I-Lin Kuo Macromedia CF5 Advanced Developer Sun Certified Java 2 Programmer __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ __ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Systematic diagnosis of CF memory use
I've inherited a CF app with an apparent memory leak. Does anyone have a systematic plan to diagnose and eliminate possible causes? The Macromedia Knowledge Base article http://www.macromedia.com/v1/Handlers/index.cfm?ID=15014Method=Full is helpful, but doesn't provide a plan of attack. Of the list of causes on that page, the application has possible causes (that I know about) -- unlocked shared-scope variables, large cached queries, large record sets, and COM objects. I strongly suspect that it's the unlocked shared-scope variables, but it's a big undertaking to correct this and I need to show the boss that I've eliminated other causes before undertaking this effort. Any suggestions? Sure, but it might take longer to go through that systematic plan than it would to just make sure you've locked all the variables. First, you can look at your server logs. Depending on how you've organized your application code, this may or may not be especially helpful, but it should always be the first step. See if you can find which scripts are most likely to be associated with problems, and see what's in those scripts. As I mentioned, though, this might not give you much to go on, since your application may have things in many scripts that, together, are problematic - like unlocked memory variables. Second, you'll need to set up a testing environment. You'll need to replicate your current environment as much as possible - if you can, take the current server(s) out of service temporarily and use them. Take a copy of your application, and set it up separately, and simply take out portions of your application code in sections. For example, take out all of the COM object code. Then, load test the application, and see what happens. Then, take out the large recordsets, and repeat. On occasion, I've followed the same strategy, turned inside out in a way. I've built a test application that does some of the same things done by the problem app, and load tested that. It's a simple, but tedious, process of elimination. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Systematic diagnosis of CF memory use
As always Dave well said, I would also look for any usage of CFX_ tags and if they are used I would lock them, you never know how well cfx code is written or not as the case may be. When you get beyond the show stoppers look at things like blockfactor= in your sql select queries and there are a whole plethora of CF Administrator settings to tweak things. The crown jewel for you in all of this, as Dave already said are the ColdFusion logs. Hope this helps. Kind Regards - Mike Brunt, CTO Webapper http://www.webapper.com Downey CA Office 562.243.6255 AIM - webappermb Webapper - Making the NET work -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 8:59 AM To: CF-Talk Subject: RE: Systematic diagnosis of CF memory use I've inherited a CF app with an apparent memory leak. Does anyone have a systematic plan to diagnose and eliminate possible causes? The Macromedia Knowledge Base article http://www.macromedia.com/v1/Handlers/index.cfm?ID=15014Method=Full is helpful, but doesn't provide a plan of attack. Of the list of causes on that page, the application has possible causes (that I know about) -- unlocked shared-scope variables, large cached queries, large record sets, and COM objects. I strongly suspect that it's the unlocked shared-scope variables, but it's a big undertaking to correct this and I need to show the boss that I've eliminated other causes before undertaking this effort. Any suggestions? Sure, but it might take longer to go through that systematic plan than it would to just make sure you've locked all the variables. First, you can look at your server logs. Depending on how you've organized your application code, this may or may not be especially helpful, but it should always be the first step. See if you can find which scripts are most likely to be associated with problems, and see what's in those scripts. As I mentioned, though, this might not give you much to go on, since your application may have things in many scripts that, together, are problematic - like unlocked memory variables. Second, you'll need to set up a testing environment. You'll need to replicate your current environment as much as possible - if you can, take the current server(s) out of service temporarily and use them. Take a copy of your application, and set it up separately, and simply take out portions of your application code in sections. For example, take out all of the COM object code. Then, load test the application, and see what happens. Then, take out the large recordsets, and repeat. On occasion, I've followed the same strategy, turned inside out in a way. I've built a test application that does some of the same things done by the problem app, and load tested that. It's a simple, but tedious, process of elimination. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 __ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
