BlueDragon.NET versus ColdFusion 8: Multiple Instances
A prospective customer recently asked if BlueDragon.NET has any advantages over ColdFusion 8 for running multiple instances. For those not familiar with the topic, Adobe has published a short white paper entitled, Multiple Server instances using Adobe ColdFusion 8 Enterprise Edition; in this white paper, the benefits of multiple instances are listed as, "high availability, enhanced security, fine-grained application optimization, individualized application administration, and clustering." All of these benefits are also available in multiple instance configurations of BlueDragon.NET.
Configuring CF8 multiple instances is a bit complex. My goal was to create three IIS web sites and configure a separate CF8 instance to serve each web site. I got as far as installing CF8 and creating three separate instances--which was fairly straightforward--but it isn't immediately apparent how to configure each IIS web site to use its own separate CF8 instance. Here's a screenshot of the CF8 Instance Manager with three instances configured:
Click for a larger image
Here's a blog entry that contains a number of references for ColdFusion multi-instance configuration; I'm sure one of them has a solution to my problem, but I don't have time to investigate any further right now. For my purposes here today, I was able to get far enough to demonstrate what I really wanted to see: the base memory requirements of multiple CF8 instances.
With three CF8 instances configured, I opened the Task Manager and found five "jrun.exe" processes, each using between 44.7MB and 173.3MB of memory. I assume that three of these "jrun.exe" processes are for the three CF8 instances, and that one is for the CF8 admin server, but I don't know what the fifth process is for, nor what's causing the variance in memory usage. There are also four "jrunsvc.exe" processes, using about 1.7MB each; the total for all the "jrun.exe" and "jrunsvc.exe" processes is about 650MB:
So the "getting started" cost for configuring three CF8 instances is about 650MB of memory--before installing or running any CFML pages. Real memory requirements for CFML applications, including the template (file) cache, query cache, application and session data, and other per-request variables, will be significantly higher. In fact, comments on this blog indicate that even on a server with 4GB of memory, the practical limit is 2 or 3 CF8 server instances. This is a fairly severe limitation of the CF8 multiple instances feature.
Now let's take a look at the BlueDragon.NET memory requirements for a similar configuration.
First, we need to discuss the concept of "Application Pools" introduced in IIS 6.0 on Windows Server 2003. An Application Pool is a process that hosts multiple IIS/ASP.NET applications. Each application has its own isolated memory space within the Application Pool process, so that each application has its own configuration data, application-scope variables, etc. (unlike ColdFusion, where all applications within a single process share configuration data and can potentially access each other's application-scope variables).
In IIS 6.0, there's initially a single Application Pool--the DefaultAppPool--and by default whenever you create a new web site it gets assigned to the DefaultAppPool. In IIS 7.0, introduced in Windows Vista and Windows Server 2008, by default whenever you create a new web site a new Application Pool gets created for that web site, which is considered best practice. Since I'm using IIS 6.0, the first thing I did was to create Application Pools for the three new IIS web sites I'm going to create (if I was using IIS 7.0 this step would be unnecessary):
Then I configured three new IIS web sites. After creating each new web site, I modified its Properties to assign it to a separate Application Pool; essentially, this is all that was necessary to create a new BlueDragon.NET "instance"; again, this step would be unnecessary on IIS 7.0:
After serving a basic "Hello, World" index.cfm page to make sure BlueDragon.NET is initialized for each web site, here is what the memory usage looks like in the Task Manager. Note that unlike ColdFusion, BlueDragon.NET does not create its own separate processes, but instead runs with the IIS Application Pool processes. Therefore, what we're interested in are the "w3wp.exe" processes, each of which is consuming about 38MB of memory, for a total of about 115MB:
Of course, the memory requirements of your CFML application might be the overriding factor in determining how many separate BlueDragon.NET or CF8 instances you can actually configure on a single server. For example, we have one BlueDragon.NET customer who's storing over 1GB of data in the query cache; though this is unusual, it obviously limits the number of instances they can configure. However, as I've demonstrated here, the base memory requirements of three BlueDragon.NET instances is only about 20% of that required by three CF8 instances: 115MB versus 650MB.
From a practical perspective, planning to run 20 or more separate BlueDragon.NET instances on a single server is not unreasonable (again, based on the specific requirements of your applications), whereas 2 or 3 separate instances per server seems to be the upper limit for CF8 due to the memory requirements of CF8 itself.
Finally, a note on pricing. The multiple instances feature is only available with the CF8 Enterprise Edition, which starts at $7500 and goes up based on the number of CPUs. The multiple instances feature is available on both BlueDragon.NET Enterprise and Standard Editions; the Standard Edition costs only $1999 per server for unlimited CPUs.
So, to answer the original question, "What advantages does BlueDragon.NET have over ColdFusion 8 for running multiple instances?", the answers are:
- BlueDragon.NET multiple instances are easier to configure and administer.
- BlueDragon.NET multiple instances require less memory, potentially allowing you to create many more instances per server.
- BlueDragon.NET multiple instances are less expensive.
If you're interested in learning more, download a 30-day evaluation copy of BlueDragon.NET to see for yourself the benefits that multiple instances can provide.
The 5th jrun process is for search (verity) I believe.
Also as your post relies on the benefits of IIS' Application Pool...how would you get multi-instances running for BD on a *nix box or on Apache/Win?
:)
I'd be interested to see a comparison of BD J2EE vs BD .NET on Windows. I know BD J2EE has a smaller footprint than CF.
John
The admin instance is only required if you need to access the JRun Management Console. The cfusion instance is only required for creating new instances - and can safely be stopped once you're done.
The jrunsvc processes are used for auto restarting a ColdFusion instance should it crash, i.e. one for each instance with the exception of admin.
As for configuring multiple instances ... complex. Nonsense. Once you've created the instances. You run wsconfig and tell it (via two drop down boxes), match Instance 1 to Web site 1, Instance 2 to Web site 2, Instance 3 to Web site 3.
Really, that's it. It's not difficult.
all you have to do is click the "remove" button in the "home directory" tab for your website (see the screen shot above).
this will free up memory for other services that would be otherwise wasted. this is a really great tip if your using a VPS with 1 gig of RAM, like the ones you can purchase through hostmysite.com. by doing this little trick we were able to free around 150 megs and host about 5 more CF sites safely.
While not 100% straightforward, it is fairly simple to set up seperate jvm.config files for each CF instance, and there you can indicate how much memory should be allocated. For example, a heavy traffic site with lots of stuff going on should be configured to allow more RAM allocation to the JVM (since it'll use it). A site that has two pages and a contact form should have a seperate jvm.config file with far less memory allocated. This allows you to get the maximum bang for your CF buck (even if it requires you do a little work). I'll bet looking at the requirements for each of those CF instances I could get the memory usage down from your default 650 MB.
As far as instances go, I maintain a server that hosts about 14 CF instances with 3 GB of physical RAM, and the box never has resource issues. That's the benefit of doing the server tuning that any administrator should be doing.
I'd like to see a comparison of site/resource usage between BD.NET and CF 8 where some actual tuning has been done to maximize the effectiveness of the install. And to claim that tuning shouldn't be necessary is nonsense. If you're in a position to need multiple instances (for HA, resource sepeartion, whatever) then you need to know how to tune and perform tuning, it's that simple. Do ignore this vital piece of system administration is, in my humble opinion, bad form.
the memory usage claim are not misleading at all. the numbers are from just creating the instances that any normal person would do under CF. Most people are not going to sit there and mess around with the jvm.config file or create separate ones for each instance, they're just going to create and go like vince did. you're mislead in assuming that everyone out there is a jvm configuration master or will take the time learn how to configure their jvm.
@Lincoln you beat me to the punch on creating separate "jvm.config" files, I have several clients who have successfully done that. I also think you are spot on with your comment "That's the benefit of doing the server tuning that any administrator should be doing."
@Sean you did a very good blog post on application contexts in J2EE JavaEE. Do you have any thoughts on where that lies or might impact application pooling in IIS if at all?
Nor are most people going to use multiple instances ;). I would boil this down to a lack of reliable documentation on Adobe's end, but if you are going to delve into multiple instances, you will need to start reading into things like modifying the JVM configs. And it gets even more complicated if you plan to create a cluster of instances and have to rely on session replication using J2EE variables. None of these is something the average admin is going to do. But, there are a slew of blogs out there that deal with these kind of things.
There are certainly cases where one JVM config will be fine for what you need. At my old job we did just that, and never had problems (at least not JVM problems, the code I wrote was a different matter!). Where I'm at now, with a load balanced cluster and sites ranging from simple to complex, I can't afford to have all sites using the same JVM, so I leverage that control as needed.
YMMV, but the JVM is not something that can be overlooked in dealing with capacity or resource issues. In fact, tuning at that level can make a world of difference in terms of memory and performance.