CF8/64-bit/Multi-server Configuration

[jarviswabi]

I'm experimenting with setting up a multi-server configuration of CF8 64-bit on Windows Server 2008 64-bit, thanks to several helpful blogs I found on the topic.  I've got the basic setup complete, but what I'm finding is that when I create my first instance in Instance Manager, that instance is MUCH slower than it should be.  This is immediately noticeable going into the CF Admin on the new instance (port 8301) compared to the initial CFUSION install (the default where you configure the instances from).  Everything is slow--the page load, the image load, etc.  I threw a simple index.cfm page with one cfoutput in the root directory for the main install and in the cfusion.ear/cfusion.war folder for the instance, and it too was much slower to open (repeatedly) in the new instance.

Because everything is slower, I'm prone to blame IIS7, but before I go through the bother of installing Apache, I thought I'd see if anyone had run into this.  Another candidate could be the install on 64-bit, but I thought everything matched up okay.  Is there a specific JVM that runs best on Windows 64-bit?

My goal is to have 2-3 CF instances running on this server (which has 10Gb of RAM), so I can have isolated JVM heaps to run large overnight jobs which tend to create memory issues if they're run on the same instance.  So each instance could have its own codebase.

Speaking of that part, this may be a dumb question, but since I've only ever worked with Single Server installs, I'm not sure.  When I add/modify cfcs and cfms for the instances, do I just update the files within the cfusion.ear/cfusion.war folder for that instance (in the jrun4/servers directory), or is there something you have to do to package and deploy?  I've used Tomcat for JSP apps before and I hate it, so I'm hoping it's nothing like that.

I appreciate any suggestions anyone can provide.

[Charlie Arehart · Accepted solution]

Well, I don't think you can blame IIS. You indicate that you put the files to test in the cf webroot (that cfusion.ear/cfusion.war folder you mention). Those are only served up by the built-in web server port (8301, in your case). So IIS is not involved in serving up those pages.

Are you confirming that pages are slow both when using that port and when not? And to be clear, for you to not use that port, you would need to run the web server configuration tool to connect a given IIS site to a given (your new) CF instance. If you do that, it may be interesting to see if there was a difference. (To be clear, if you connect an instance to an IIS site, you would then put the test CFML pages into the IIS docroot, not that CF webroot.)

That said, I would not suspect that the problem is really related to the web server. It could be, but I'd suspect other things first. For instance, if you turn on CF output debugging, does it show that in fact the slowness is in time spent running the page? It may not, but again it's the first thing to confirm.

And since you are running Enterprise (or Developer, either of which is the only way to run multiserver), you then also have the CF Server Monitor. If you open that and turn on "start monitoring", it has an interface option to show you "slow requests", which could help you also confirm if the time is really "in CF". If it is, then I'll add that there are still other tools in the monitor (or in tools like FusionReactor and SeeFusion) that could help identify specifically why a page is slow. But before we dig into that, let's see what you say to the above.

Now, on a separate matter, you ask if it could be the JVM: it could. You say you're on CF8. Might you mean 8.0.1, specifically? In either case, the JVM that came with them was an early 1.6 build. Subsequent to the release of both CF8 and 8.0.1, Sun discovered and fixed a bug and updated the JVM. People found that that JVM can indeed be better. I'd be surprised that you'd notice that with just a simple test page, but it may be worth considering. See any of many blog entries out there about upgrading the JVM in CF. You want to go to at least 1.6.0.10 (and you want the JDK, not the JRE). Also, though Sun currently offers an update .21, some people have reported problems with .20, so you may want to think twice about going that high.

Here's an old Adobe Technote on updating the JVM for CF: http://kb2.adobe.com/cps/547/2d547983.html, but pay close attention to how it discusses only briefly how to do it with the multiserver edition, where you have to edit the jvm.config. The screenshot shown will only work on a Server edition deployment. You can also find other blog entries talking about the process, such as http://www.coldfusionmuse.com/index.cfm/2009/6/11/upgrade.ColdFusion.JVM. There are still others that talk about downgrading from 1.6 to 1.5 (from before they learned of the jvm bug fix). Their info can be helpful too, but don't go back to 1.5!

Oh, and here's where to find older versions of the JDKs: http://java.sun.com/products/archive/ (and for you, be sure to choose a 64-bit one).

But again, before doing that surgery, let us know what you find with the simpler tests above.

To your final question, about where to put code, again, recall my point above about the CF vs the IIS web roots. If you'll have different IIS web sites for the different instances, note that you could technically tell IIS to have the different IIS sites point to the same docroot location. If you do for some reason want instead to use the built-in web server (like port 8301), then yes you would need to copy the code among the different webroots for the different instances. (Technically, you can also modify the config of the built-in web server to define a mapping that could point each web server in different instances at a single shared doc directory. Most never do it. I blogged about it back in 2002: http://cfmxplus.blogspot.com/2002/08/running-cfmx-code-outside-default.html).

For folks who may have struggles dealing with issues like these, I'll note that there are various companies, myself included, who can help. I keep a list at http://www.cf411.com#cfassist

HTH

/charlie

[jarviswabi]

As we all already knew, you da man Charlie.    I missed the most obvious explanation, that I was loading the instances through the built-in web server and not IIS.  I created a second site in IIS and mapped the instance to it like you suggested and dropped my test page in the new root directory for that site, and bam, loaded up just like you'd expect.  So I think all the other stuff I looked at may be red herrings, although I will check out the JVM alternatives you mentioned (I am running 8.0.1).  Ultimately, I'll want all the performance I can get since some of these jobs that will run on these instances are overnight database loads that take several hours.

So as for the codebase question, it seems like I could create as many IIS sites as I want sharing the same root directory, and therefore the same codebase, and link each site to a different CF instances so that multiple instances could each run copies of the same code, right?  That would serve my purposes best where I want to have one set of core functions and two or three overnight jobs that can run simultaneously, each with its own 2Gb JVM heap.

Speaking of that, I couldn't find any real consensus as to the max heap size usable on 64-bit.  I've always run 1.5Gb on my 32-bit installs, and I was able to start the JVM on 64-bit with 2Gb just fine.  Seems like 3Gb might be the highest one would want to try, but is there any consensus yet on what's optimal?  Theoretically, none of my jobs needs more than 2Gb (if they did, I'd be pretty sloppy), but it's still nice to have more room than you need so I can avoid as many 3AM emergency text messages as possible.

Thanks for your help Charlie.

[Charlie Arehart]

Glad it helped. Thanks for the kind regards.

Yes, you would be able to share the one code base among multiple instances, no problem.

As for the heap on 64 bit, there shouldn't be any limit, I don't think. 64bit opens huge capacity, more than most have in real (or even virtual) memory. Someone else may have another thought.

/charlie

[Guest]

We've been running static 4GB heaps for about a year now with no issues.  Other JVM memory spaces have been adjusted accordingly.  After the server has been in operation for a month or so, we level out around 1.8GB per instance (we run 3 per box in production).