There was some followup on the Atlanta ColdFusion User Group community mailing list discussion about CFMX as an enterprise platform that I had posted earlier. Some folks had good questions, so I tried to elaborate a bit more. The content of that reply is posted here…

From: Barry Hawkins
Date: March 8, 2004 1:16:35 AM EST
To: community@acfug.org
Subject: Re: .Net vs CF
Reply-To: community@acfug.org

On Mar 7, 2004, at 2:57 PM, Adam Churvis wrote:

>> Barry,
>> …would you please define and expound upon your phrases, “…level
>> of scale…stress at the seams…” in item #3 just a little?
>
> I’d like to hear more about this, too, Barry. For instance, what made
> you
> decide that it was Windows 2000 that was the culprit, rather than
> something
> else?
>
> I’m not trying to challenge your decision; I’m only trying to
> understand
> your deductive process for isolating the problem.
>
> Respectfully,
>
> Adam Phillip Churvis
> Member of Team Macromedia
>
List,
Hi, sorry for not replying sooner. I had to wrap up that post in a hurry on my way out the door for the day. Thanks for the replies! This has been a stimulating turn in the conversation. Here are a few items to clarify what I intended:

1.) Enterprise - yes, indeed, this is an over-used, misapplied term in our industry, surpassing “granular”, “chunky interface”, and “web service”. My favorite definition of enterprise is in the O’Reilly book “Java Enterprise in a Nutshell, 2nd Edition”[0]. Unfortunately, that book is at my desk at work. Here’s a rough idea of what I meant by “enterprise”:

- A significantly-sized user audience within an organization, typically numbering in the thousands and beyond
- A multiplicity of platforms, i.e. mainframe, Solaris, Windows
- A multiplicity of data store platforms, i.e. DB2, Oracle, SQL Server
- High concurrent user loads, anywhere from 500-1,500 depending on the app
- High peak concurrent user loads, in the high thousands
- Complex business logic and high transactional loads
- (Possibly) multiple desktop platforms, i.e. Windows, Mac, Linux, & their associated browsers

2.) Stressing at the seams on Windows 2000 Server - I didn’t like this idiom when I used it, but I was running out of time this morning. Given a single instance of a CFMX server running a single JVM on a Windows 2000 Server, the heap size is significantly limited in comparison to other web application platforms. This is to say that the ceiling for the memory resource pool is lower than the alternatives. I think Windows 2000 Server is a dramatic example, but check this out:

- Windows 2000 Server can only address/allocated 2GB RAM to the user space
- The Sun 1.4.2 JDK has an issue with the Windows 2000 limitation that only allows a 1.3-1.6 GB heap size[1]
- Macromedia recommends allocating a heap size of either half of your system’s physical memory or 1024MB, whichever comes first.
- Macromedia does not officially support the use of an alternative JVM, so the 1GB ceiling is pretty fixed
- Therefore, CFMX does not have access to the memory resources available to other Java web app platforms, i.e., Tomcat
- My guess is that .Net is not shackled with any of these issues except the 2GB limit - though I haven’t checked 8^)

I am not trying to argue against CFMX here, but the facts above generally imply that you will hit a resource threshold in CFMX before you do in the other platforms.

In regards to the application I referenced, it has plenty of room for improvement, tuning, etc. The CFC instances in a given user session are complex and large in size. All data access takes place through stored procedures. There is a great deal of complex business logic evaluating the content of those objects. The size of the average user session and the number of users have provided a vivid example that takes CFMX to its stressing point on this particular platform.

We have been monitoring key performance metrics for CPU, memory, disk I/O, request processing, and database access. The CPU usage for the JRun instance is regularly pegged between 85 and 100 percent for 60-70% of the 14-hour work window, and the JRun instance’s memory is at its max (the max and min are set to the same values to work around the aforementioned Windows 2000 issue). Queued request averages(~7 seconds, going from memory) and request processing averages (~20 seconds) are averaging very high. Disk I/O, overall system memory, and database access are negligible. The server, application, and exception logs are all free from errors related to the application.

3.) Abstraction always carries an associated cost - I definitely agree that the abstraction of CFMX is very nice. However, there is a threshold at which the cost of that abstraction is too high. That threshold is generally reached when dealing with the requirements of an “enterprise” application as defined above.

Consider the same principle at a different scale; how many of you experienced CF developers let Dreamweaver MX Server Behaviors handle all of your database interaction? I don’t anymore; there was a time when I did, though. Server Behaviors are really handy and quick, but anyone with a little experience can tell you that it doesn’t necessarily produce the tightest code. It also doesn’t produce code that leverages the full feature set of the particular server version a shop may be using, particular if the shop stays current on versions. In the same way, I don’t have that much faith that CFMX is always generating Java bytecode that is as efficient or robust as when a particular function’s bytecode was compiled from Java source code.

I hope that I have fleshed out some of the holes I left in my first post. Thanks again for the great discussion. Oh, and thanks to Adam Churvis for the tuning section in the CFMX Bible!

[0] http://www.oreilly.com/catalog/jentnut2/
[1] http://forum.java.sun.com/thread.jsp?forum=4&thread=475618
http://java.sun.com/docs/hotspot/PerformanceFAQ.html#22
http://developer.java.sun.com/developer/bugParade/bugs/4697804.html

Regards,
–
Barry C. Hawkins
All Things Computed
site: www.allthingscomputed.com
weblog: www.yepthatsme.com