Michael Sprague has written a very nice set of CFML custom tags that use the jQuery JavaScript libraries to implement alternatives to the CFGRID, CFWINDOW, and CFTOOLTIP tags introduced in ColdFusion 8 (CF8). In Michael's words:

"This (CFjqAjax) is a library of custom tags that replicate the CFGRID, CFWINDOW, and CFTOOLTIP tags from ColdFusion 8. The CF8 tags work, but I find YUI and Ext much harder to work with than jQuery, and the file size of the JavaScript libraries that CF8 includes is excessive. So, I created CFjqAjax."

My first thought on reading this was, "Gee, I wonder if CFjqAjax will run on BlueDragon.NET?"

Click here for the answer

No changes were required to any of Michael's code to run on BlueDragon.NET (the data displayed in the CF_WINDOW example is different than the demo on Michael's web site, but is displaying correctly based on the contents of the downloaded package).

Nice work, Michael!

CFML-to-.NET integration is the ability to create and invoke methods on .NET objects from CFML using the CFOBJECT tag and CreateObject function. In a previous blog entry I discussed the architectural differences between BlueDragon.NET and the implementation of the ColdFusion 8 (CF8) .NET Integration feature. To summarize:

• CF8 implements .NET integration via remote procedure calls (RPC) to an external process and a Java-to-.NET bridge.


• BlueDragon.NET is implemented as an in-process extension to ASP.NET; creating and invoking methods on .NET objects is done using the .NET reflection APIs.

The implications of these architectural differences for CFML-to-.NET integration are:

• BlueDragon.NET performance is much better than CF8;


• BlueDragon.NET provides much better compatibility with .NET than CF8 (CF8 imposes limitations that BlueDragon.NET does not); and,


• BlueDragon.NET provides a wealth of opportunities for integration with IIS and ASP.NET that CF8 does not support at all.

In this blog entry I'd like to delve into more detail on the first point: performance. To test performance, I found these two examples: Ben Forta's GetDriveInfo UDF and Anuj Gakhar's System.Environment example. I combined these into a single CFML page, wrapped them each in a CFTIMER tag, then enabled debug output to display the page execution times and CFTIMER output.

On Windows Server 2003, I executed the example page 20 times each on CF8 and BlueDragon.NET, then took a snapshot of the timings produced by the 20th execution. Here are the timings produced by CF8 (click for a larger image):

Here are the timings produced by BlueDragon.NET (click for a larger image):

For the GetDriveInfo example, CF8 is about 3.5 times slower than BlueDragon.NET (219ms versus 62ms). For the System.Environment example, the results are even more dramatic: CF8 is more than 15 times slower than BlueDragon.NET (250ms versus 16ms). In overall page execution times, CF8 is about 6 times slower than BlueDragon.NET (469ms versus 78ms).

These results are not surprising, based on an understanding of the architectural differences between BlueDragon.NET and the implementation of the CF8 .NET Integration feature.

(In my previous blog entry I stated that the CF8 .NET Integration feature is architecturally very similar to web services calls. Given these poor timings, it might be an interesting exercise to redo these examples as .NET web services, and then see if the CF8 .NET Integration feature provides any performance benefit over web services at all).

If you're planning to use the CF8 .NET Integration feature, you'll have to be very concerned about performance. As these examples demonstrate, it's very easy to get execution times into the 200-250ms range just for creating and invoking methods on a single .NET object, and into the 400-500ms range for multiple objects per page. You might want to consider a caching strategy where the results of .NET method invocations are stored in a shared variable scope--such as Session or Application--rather than making .NET method calls for every request (of course, this won't always be possible). It's probably best to avoid creating and invoking methods on multiple .NET objects for a single request, at least on a regular basis.

With BlueDragon.NET, performance is much less of a concern. You'll generally be free to create and invoke methods on multiple .NET objects, on a per-request basis, without worrying about your page execution times extending up into the 400-500ms range (as they can with CF8).

In future blog entries I'll follow-up on advantages of .NET compatibility and ASP.NET integration provided by BlueDragon.NET.

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:

1. BlueDragon.NET multiple instances are easier to configure and administer.
   
2. BlueDragon.NET multiple instances require less memory, potentially allowing you to create many more instances per server.
   
3. 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.

I was approached by a prospective customer at Microsoft's TechEd conference who asked if BlueDragon.NET could solve the performance issues he's having with ColdFusion. I told him that based on our experiences with companies such as MySpace, eBags, HealthGrades, DevX, and dozens of others I was very confident it could, but that "the proof was in the pudding" and the only way to know with any certainty was to test his application.

A few weeks ago I was able to pay him a visit and help set up his application for testing on BlueDragon.NET. We ran into two minor CFML compatibility issues that we were able to fix with patches very quickly, and a few days later I received this email:

"Here are the results of preliminary testing over 1 minute:

CF7: 381 pages served
Blue Dragon: 1007 pages served

So Blue Dragon served up 164% more pages or 2.6 times the number of pages as CF 7 running on the same server. This is very encouraging."

This prospective customer is now moving into full production testing with BlueDragon.NET and I expect that within a few weeks I won't have to refer them as "prospective," but simply as another satisfied BlueDragon.NET customer.

These performance gains are typical when doing performance benchmarking of real-world applications on BlueDragon.NET; in fact, a performance gain of 2.6 times is actually on the low end--we regularly see performance improvements of 5 to 10 times just by migrating an existing ColdFusion application to BlueDragon.NET.

If you're having performance problems with an existing ColdFusion application, download a 30-day evaluation copy of BlueDragon.NET to see for yourself the immediate performance improvements it can provide.

New Atlanta is sponsoring and exhibiting at Microsoft’s TechEd conference in Orlando next week, where we will showcase the upcoming BlueDragon.NET 7.1 release. As I've discussed in previous blog entries, the key new features of BD.NET 7.1 include:

• IIS 7.0 Integrated Pipeline (onRequestStart and onRequestEnd for all content types)
  
• IIS 7.0 Integrated Configuration
  
• IIS 7.0 Integrated Administration

Here's the latest screenshot of BlueDragon.NET 7.1 administration and configuration integrated with the new IIS 7.0 Manager application:

In addition to demonstrating BD.NET 7.1 at TechEd, we are also announcing our new ColdFusion-to-.NET and ColdFusion-to-Java migration services. As experts in ColdFusion, ASP.NET, and Java technologies, New Atlanta is uniquely positioned to assist organizations that want to migrate their ColdFusion applications to either the ASP.NET or Java EE web application platforms. Look for additional information on these new services to be posted on our web site before the start of TechEd next week.