On 1/11/06, Adam Haskell <[EMAIL PROTECTED]> wrote: > Ok so we're finally begining the process of upgrading to MX 7, from 5. I did > this at my last company (4.5 -> MX6 -> MX6.1) with very very few problems. > One problem we always had was when the server came back up the page load was > incredibly long for the first 10 minutes while CF compiled all the template. > Was there something I was missing back in the day that could have mitigated > that [problem some and has MX 7 improved on this at all? This is a major > concern here, my old job was ecommerce we only had 1 site to complie, here > we run about 100+ small projects on the server and at one time 10-15 of them > could be being accessed I have some major concerns about the compile time. >
There are a few things you can do. First off, back when MX was first released, the CF code was first compile to java source code and then to byte code. This caused the delays you were seeing. There were some shell scripts floating around to pre-compile your code. With the release of MX 6.1, the hotspot compiler was optimized such that CF code was compiled directly to byte code, so the resulting "pause" was substantially smaller. With MX 7, the compiler was optimized that much more to the point where now you don't really notice the hit on the first request of the template. The history lesson aside, here are some options if you still find it unacceptable: 1) You can uncheck the "Save Class Files" option in the Administrator. This prevents a write to disk of the resulting byte code. *However*, the downside to this is that if you need to restart the instance, all the code will need to be re-compiled, as it only resides in memory. 2) Deploy your code using MX 7's EAR/WAR deployment options. There are several articles out that explain this process (including one I wrote for CFDJ). The upside is that the code is pre-compiled to byte code, so that initial hit is no longer needed. The downside is that you have a little more maintenance overhead of having to re-compile your source code changes into the EAR/WAR file and then re-deploying it to your production instance. 3) Just don't worry about it. Really, the performance hit is so negligible now (on decent hardware) that it's not worth the headache of trying to get around it. The initial sluggishness you see when you first start your instance is likely more related to the underlying JRun/ColdFusion processes caching themselves along with the JVM heap getting itself sorted out. Regards, Dave. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:229178 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
