Locking the CFX did not help. The CFX is extremely stable. I have run it on 4.5.1 and 5.0 for a long time with massive amounts of hits. Never had any problems.
Why is MX crashing because it is using a CFX tag anyways? The CF API has not changed.... so the only difference is the complete re-write of CFMX. -----Original Message----- From: Mike Brunt [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 1:13 PM To: CF-Talk Subject: RE: MX Crashing _MAYBYE_ solved WAS: CFMX Taking all CPU Resources? Try locking that cfx call also. That way you should get stability and still be able to use it (the cfx thingy). Mike Brunt - CTO Webapper Services LLC http://www.webapper.com Downey CA Office 562.243.6255 "Making the NET Work" -----Original Message----- From: Chad Gray [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 10:39 AM To: CF-Talk Subject: MX Crashing _MAYBYE_ solved WAS: CFMX Taking all CPU Resources? I may have to eat my own words. I think I found the problem with my crashes. You guys got me thinking about some of the code I had been writing for the current applications we are working on. They all had one thing in common and that is a CFX application we have been using. I commented out this CFX application and I can't get the server to crash _yet_. Im going to start pounding the serve with XENU and see what I can get. Anyone else have a load testing utility I can try? -----Original Message----- From: Stacy Young [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 11:22 AM To: CF-Talk Subject: RE: CFMX Taking all CPU Resources? I don't think it's "essential" to optimize for mx but there are opportunities to do so that's for sure. If it's a bug and the system can't scale under a certain condition then I'd agree to raise hell....on the other hand if it's a specific operation(s) or environment issue that causes the anomaly then maybe it can be fixed via an optimization. Now you certainly won't hear this from MM Sales but truth be told that if you want to move your production system to a 1.0 release then you *must* account for the possibility of environment issues no matter how remote. I wish it were so but it's not always black and white...we each operate in a unique environment.... If it helps any I'm interested in helping you track down the cause... Cheers, Stace -----Original Message----- From: Chad Gray [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 12:03 PM To: CF-Talk Subject: RE: CFMX Taking all CPU Resources? Todd, great post, but how do we learn to optimize for MX? Trial and error? You can write crappy slow code in any language, but a few hits as to how to optimize for MX sure would be nice. I guess we need to find out from Joe what kind of code he has written for that test he posted. How complicated is it? Is it Fusebox? What kind of database? Are there certain pages that seem to be taking extremely long amounts of time to process? My personal problem with MX is stability under load. 10+ service crashes per day on two development servers, but that is another story and one that a fellow from MM started helping me try to figure out, but I have not heard from him in a week. -----Original Message----- From: Todd [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 27, 2002 10:42 AM To: CF-Talk Subject: RE: CFMX Taking all CPU Resources? "The content/app was written for CF4.5..." Again, it might be time to start thinking about streamlining for MX. I'm *glad* you tested your application, at least I hope these specs below are not coming from your production server. However, this shouldn't be your source of frustration. This should be groundwork for you to build a case and present to your boss, "Hey Boss, we've got some work to do, check this out..." MX is new (should be considered 1.0 for all intent and purposes of a total rewrite of an existing application). MX is the future (sorry to say it, but ... I think the rest of the world is moving forward with or without you). A proper sweep through the "Content/app written for CF4.5" should be done to identify the bottle necks, move some of the logic to .cfc's, etc. Have you written one application geared towards CFMX yet? Have you seen the speed? I think that once you've written _1_ application (heck, develop more than one, we encourage it!) geared towards CFMX, you'll see what the rest of us are seeing and I think you'll be pleased with the results (as the rest of us are). Please don't take this email personally. This isn't hammering YOU (except, you need to calm down some and get back to reality instead of swearing and pointing fingers about it all). I think the biggest problem I've seen so far is the "branding" of ColdFusion 5. They went from CF4.5.2 to CF5 and didn't realize that they can safely bring their 4.5 apps into CF5 and get such a huge speed burst without rewriting any of their crappy coding. CFMX is a different animal, as their has been several discussions that proper care, education and planning will be needed when approaching CFMX. Granted, some of us out here are still learning it all... some of us out here have had the advantage of being a beta tester and are pretty much up to speed, but ... even I'm finding *NEW* things inside CFMX that I haven't found or played with yet. ~Todd At 11:17 AM 7/27/2002 -0400, you wrote: >Todd, > This was my original post. All of this testing was for the same > content. > Simulated 50 concurrent users on CFMX = average 85% CPU on 750Mhz >DUAL P3 Processor > Simulated 50 concurrent users on CF5.0 = average 12% CPU on >600Mhz Single P3 Processor > > The content/app was written for CF4.5 and we didnt write any CF5.0 > optimized code. >Joe ______________________________________________________________________ Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.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