I Despise ColdFusion
25 Sep 2006I really, really do. I despise it. Over the past few weeks, we've been battling in our hosting environment to come up with solutions to a myriad of issues with ColdFusion and how it scales. Now, I don't think that ColdFusion was really designed to be used in a shared hosting environment, with hundreds of sites and thousands of hits per second throwing traffic at it. It certainly doesn't scale well enough.
Now, I know there's a ton of heavily trafficked sites that use ColdFusion. It is possible for it to scale. It's just not possible for ColdFusion to scale when the code in question isn't specifically designed to do so. We've got thousands of customers spread across a handful of servers, and they've all written code that, well, let's say it's not professional. It's all basic "open database, run query, output data" code, 99% of the time against an Access database.
75% of the time, ColdFusion handles its end of the bargain pretty well. We're running IIS6, Windows Server 2003, all the normal stuff. The problems end up being two fold:
- ColdFusion still uses ODBC
- ColdFusion uses Java
Our two basic problem scenarios are cases where we get a lot of concurrent database queries and ColdFusion's ODBC service simply decides it can't handle it. Rather than fail gracefully (allowing us to catch the stopped service and restart it accordingly), the service just keeps running, but simply doesn't do anything. It actively rejects all TCP/IP database connections, and leaves customer sites basically dead in the water.
We've worked around the ODBC issue by having a test page that makes a database connection, which we query every X seconds, determine if the ODBC service is still working, and if not, we actually kill the process and restart it. Obviously, we're adding a little overhead to the box by doing this (not a ton, but it's overhead) and we're not really solving the root cause, which is that the ODBC service doesn't behave the way a normal Windows service should.
This issue is sort of hinted at in this ColdFusion TechNote, but there's no solution other than to limit connections, which is not easy to do in a shared hosting environment (well, not in any meaningful, cost-effective way). Not to mention the fact that using ODBC and DSNs is pretty antiquated and I'm not sure why ColdFusion hasn't deprecated it completely in favor of DSN-less connections (which are not only more reliable and have marginally better performance, but are far far far more portable).
The second issue is simply that ColdFusion uses Java. There's nothing inherently wrong with Java (just as there's nothing inherently wrong with .NET or any other run-time environment). They all have their places. This just isn't a place that Java works well. The Java process gets progressively larger because customers don't write applications that really care about garbage collection or optimization. They're not homogenized. There's hundreds or thousands of very different applications, that instantiate different objects, and then the Java garbage collection has to try to figure out exactly how to handle it. Sometimes it works well. Other times it thrashes the CPU usage up to 100% and causes the box to simply hang out while it decides what to do.
We've been mucking with ColdFusion and JRE settings to work around this, and we've basically mitigated this problem through trial and error, and also some monitoring that will push traffic over to another server if the main server is "hung" and then route traffic back again when things are back to normal.
It's taken us a few months to get to this point, a few calls to Adobe, and a whole bunch of trial and error. Each time we solve one problem, another pops up that needs investigation and resolution. Having now played with ColdFusion for about a year, I can safely say that I would never pick it over Perl or PHP, but I can see why someone might select it over ASP or .NET, which have slightly more difficult methods of connecting to and handling database info.
Still, I despise ColdFusion. It encourages its users to do stupid things (I cannot even tell you how many customers I've had to inform that their code doesn't work because they're using a reserved SQL word as a variable or table name -- something that happens far less frequently with ASP or PHP users). It relies on a bunch of server-side technology that renders its usage fairly non-portable. It's got a horrible design for IIS, leading to cases where ColdFusion dying can cause IIS to stop serving HTML pages on the box (thanks wildcard ISAPI filter!). In a nutshell, ColdFusion has pretty much been the bane of my existance for a few months now, but we seem to have it handled at this point. If I ever ran my own hosting company, I'm 99.999% sure I'd never offer ColdFusion, at least not without charging a significant premium.
I despise ColdFusion.