There was a vibrant thread on the Atlanta ColdFusion User Group community mailing list at the end of the week. I read through it this morning while compiling the Java 2 1.4.2 SDK on my FreeBSD server. Afterward, I couldn’t help but post a few observations. Here is a copy of my post:

On Mar 6, 2004, at 8:26 AM, Todd Hartle wrote:

>compiled code, that’s so 80’s…
>
[…]

Compiled code is not “so 80’s”; I would say that it’s “so enterprise”. Now that I have taken the time to read through this thread, here are my observations:

1.) Much of the commentary here seems to be from a developer-centric perspective. In an IT practice, where strategy and maximizing resources is key, up-front investments in resources, planning, and development are essential. Not all IT shops have the size or leadership to take that approach, but it is certainly something that most shops would like to be able to do, since reinventing wheels is such a costly practice.

2.) CFMX itself is a J2EE application. All CFMX code is compiled into Java bytecode. Arguments against compiled code, Object-Oriented Programming, and the other major web application development platforms are flawed. The J2EE platform is now the set of shoulders upon which CFMX, and CFMX developers in turn, are standing.

3.) CFMX has it niche, as well as its limitations. I am currently charged with profiling a enterprise-scale OLTP web application authored in CFMX right now, and I can assure you that there is a level of scale at which CFMX starts to stress at the seams, particularly running on Windows 2000 Server.

4.) Object-oriented programming is not a failed movement. It is, in fact, where CFMX seems to be trying to head. CFCs and Mach II seem to be clear indicators that the CFMX product team and its major proponents see OOP as the way to go right now, with certain modifications and exceptions to fit existing CF paradigms.

5.) Ardently and (at times) rabidly defending a particular platform is not a good idea, as a number of entries have illustrated using .Net and Java as examples. Be cautious of being the one to provide an example of those who defend CFMX as their “religion”.

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

That’s enough writing for today.

[Updated at 03/08/2004 01:19:00 AM]

Or so I thought. Some people asked me some great questions and made some really good points, so I responded to some requests to flesh out my ideas a bit more:

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

Time to sleep…