Ready to get your mind blown? We're back on 1.4.2_19 running ColdFusion MX 7.0.2. Our attempted upgrade to CF8 was a disaster -- see the snippet here from an earlier post in this thread:
>>>>> 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). <<<<< We were never able to ascertain that Transfer was the culprit, although I am suspicious that it played a part in the Issue i described above. We're tossing around the $800 ante. But we have to be sure that the swap of the Transfer cache to eHCache plus CF8 will result in a stable platform for us, otherwise, it doesn't make any sense to go down that path without fully understanding what the issue (s) were when we were on CF8. On Sep 21, 1:40 pm, Brian G <[email protected]> wrote: > On Sep 21, 8:53 am, Clint <[email protected]> wrote: > > > We sustained our greatest # of unique visits ever last Friday and did > > not require a restart of the JVM due to an OutOfMemoryException. > > Previously, under heavy load (for us), JVM restarts would be required > > every 45 to 90 minutes....which makes for a lot of downtime during the > > day. > > Congrats on achieving this. What JVM version are you using? If it's > newer than 1.6.0 u10, I would suggest you try rolling back to it. > That has made my servers stay up about 4x as long. > > It sounds like you two work at a company... convince your boss to ante > up $800 to end your regular restarts. Match my donation and Mark will > swap out the caching with eHcache which will fix this for good: > > http://groups.google.com/group/transfer-dev/browse_thread/thread/dcf9... > > Brian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
