Oh, I misunderstood you earlier. Yeah, we definitely had it off- all three app functions disabled, and the app itself was closed, so it wasn't connected to the runtime via Flex.
Like I said, though, we experienced issues in both cases: Monitor on and Monitor off. On Sep 4, 2:33 pm, Bob Silverberg <[email protected]> wrote: > If you go to the Server Monitor, you'll see three buttons at the top > of the screen, one for each of: > > Monitoring, Profiling, Memory Tracking > > If the option is currently off, the button will read "Start xxx", if > it's currently on it will read "Stop xxx" > > Make sure that all of them are currently turned off. > > You can also do this via the admin api, using the stopMonitoring() > method. More info is available > here:http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=ser... > > Cheers, > Bob > > > > > > On Fri, Sep 4, 2009 at 3:15 PM, Clint<[email protected]> wrote: > > > How do you actually turn it off to completely disable it? We > > experienced issues both with Profiling and Memory Tracking on and off, > > but like you suggested, maybe the monitor was completely disabled? > > > On Sep 3, 10:50 pm, Bob Silverberg <[email protected]> wrote: > >> Were you perchance running the server monitor while these problems > >> were occurring? I ran into a situation in which Transfer was having > >> major problems when I had the server monitor running in the > >> background, even though Profiling and Memory Tracking were turned off. > >> I was led to believe prior to this that having just Monitoring on, > >> without Profiling and Memory Tracking, would not impact the server's > >> performance, but it did. As soon as I turned off all monitoring my > >> problem went away. > > >> This may not apply to your situation, but if it does, try turning off > >> the monitor entirely and see what happens. > > >> Cheers, > >> Bob > > >> On Thu, Sep 3, 2009 at 11:28 PM, Clint<[email protected]> wrote: > > >> > I want to chime in and give some slightly tangential information about > >> > this issue we ran into. (I work with "Z" on this product): > > >> > Because we originally thought that our application code was leaking > >> > memory (and indeed, it may still be, and the memory profiling options > >> > on ColdFusion 7 (JVM 1.4 series) are limited, to say the least, we > >> > thought we would go ahead upgrade ColdFusion to the last version of > >> > 8.0.1 running on JVM 1.6. (This is all running on 32-bit Windows > >> > 2003). > > >> > Z made the necessary changes to our app and we upgraded our server to > >> > CF8. The app ran but not as fast as expected- we expected very fast > >> > performance based on many reports of heavy CFC-based apps. (We are > >> > aware of the classloader bug in JVM 1.6_04 and experienced the issue > >> > I'm describing on JVM 1.6_04, 1.6_11, and 1.6_16, and JVM 1.5_19). > >> > Even more surprising than the diminished application performance, it > >> > was never very long before the app server's CPU would be pegged at > >> > 100%. A few times this happened we were able to peek under the hood > >> > with Adobe's Server Monitor app. We saw at least one long running > >> > thread during these times referencing Transfer's SoftReferenceHandler. > > >> > Upon further investigation, we realized that after the app started up, > >> > under no load whatsoever the CPU usage would be 25%, 50%, 75%, or 100% > >> > (notable b/c this is a 4 core machine). As best as I can tell, the > >> > long running thread I observed was completely monopolizing the core on > >> > which it was running, preventing the application from serving any > >> > other requests. > > >> > After we rolled back to CF7 for current production, we provisioned a > >> > Windows 2003 VM on Amazon EC2 and installed CF8 and our application. > >> > We were not able to reproduce the problem that we described, and the > >> > performance was more or less as we expected on 8 (reasonably fast > >> > considering the minimal CPU power dedicated on the "smallest" EC2 > >> > instance). > > >> > I don't know that any of this will help you, Mark, or anyone else > >> > here, but it is an interesting observation and I want to provide as > >> > much information as possible to aid in the resolution of this problem. > > >> > Thanks! > > >> > Clint > > >> >> > > Hi Everybody, > > >> >> > > We have an e-commerce website developed using Coldfusion 7, Model- > >> >> > > Glue, Coldspring and Transfer. Over the past months we have > >> >> > > struggled > >> >> > > with what we thought was a "Memory Leak". We could see the jrun > >> >> > > memory > >> >> > > usage climb until it just became unresponsive (queue a bunch of > >> >> > > requests and never serve them). We would then have to restart jrun > >> >> > > and > >> >> > > repeat the process over and over again. > > >> >> > > After months of trying to figure out what was going on we finally > >> >> > > realized who the culprit was; the Transfer cache. > > >> >> > > Now, here's our original cache configuration: > > >> >> > > <objectCache> > >> >> > > <defaultcache> > >> >> > > <maxobjects value="60"/> > >> >> > > <maxminutespersisted value="10" /> > >> >> > > <accessedminutestimeout value="10"/> > >> >> > > <scope type="instance" /> > >> >> > > </defaultcache> > > >> >> > > <!-- SOME CLASSES WE DONT WANT TO CACHE --> > >> >> > > <cache class="Users.Orders"> > >> >> > > <scope type="none" /> > >> >> > > </cache> > >> >> > > .... > >> >> > > </objectCache> > > >> >> > > It turns out leaving the cache on by default was killing us. > >> >> > > Although > >> >> > > performance was always great, under heavy load our site would > >> >> > > sometimes have to go down every hour. > > >> >> > > After some experimenting we decided to turn the cache off by default > >> >> > > and be very conservative on the objects we cached. Our latest > >> >> > > transfer.xml looks something like this: > > >> >> > > <objectCache> > >> >> > > <defaultcache> > >> >> > > <scope type="none" /> > >> >> > > </defaultcache> > >> >> > > <cache class="Users.Customer"> > >> >> > > <maxobjects value="60"/> > >> >> > > <maxminutespersisted value="10" /> > >> >> > > <accessedminutestimeout value="10"/> > >> >> > > <scope type="instance" /> > >> >> > > </cache> > >> >> > > <cache class="Products.ProductType"> > >> >> > > <maxobjects value="10"/> > >> >> > > <maxminutespersisted value="30" /> > >> >> > > <accessedminutestimeout value="10"/> > >> >> > > <scope type="instance" /> > >> >> > > </cache> > >> >> > > ... > >> >> > > </objectCache> > > >> >> > > I guess the main question I have is whether anyone here has had > >> >> > > similar experiences or has any rule's of thumb when it comes to > >> >> > > caching objects. We are still unsure on whether the behavior we were > >> >> > > experiencing was an actual memory leak or just poor cache > >> >> > > management. > >> >> > > Any comments? > > >> >> > -- > >> >> > E: [email protected] > >> >> > T:http://www.twitter.com/neurotic > >> >> > W:www.compoundtheory.com > > >> -- > >> Bob Silverbergwww.silverwareconsulting.com > > -- > Bob Silverbergwww.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
