Already knew the history leason but thanks, been around for a long time I am just quiet most of the time ;)
I pushed for the Ear/WAR deployment option but as of right now we're using IIS. There's an interesting story about how the Achitecture team (which rules mostly java applications and very much like java) happened to chose a java application server not supported by CF MX. So we're working on that right now for our enterprise shared hosting environment. However we have an immediate need to move one of our divisions over to MX7 which is a is completely different situation. I'm glad to hear the lag time has improved. Unfortunetly I am stuck bringing another division's visual basic code inhouse right now so I am not a project lead on this project. So I won't be able to do load testing and I highly doubt it will get done. Thanks for the info on the JVM slugishness though I'll be watching it closely if we run into issuies. Adam On 1/11/06, Dave Carabetta <[EMAIL PROTECTED]> wrote: > > 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:229251 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
