Adobe Solution Partner

September 30, 2010

When ColdFusion Hits The Wall

Filed under: ColdFusion, Performance — Patrick Quinn @ 4:18 pm

There’s an immutable law of the performance engineering universe, and it’s this: Performance degrades linearly, up to a point, and then it degrades exponentially. In other words, every server has a wall, and will hit it, eventually. As we’ve seen on thousands of servers over the years in providing our ColdFusion performance engineering services, a simplified diagram of the phenomenon looks like this:

When Servers Hit The Wall

When Servers Hit The Wall

Figuring out where “the wall” is for any given server is actually a pretty complex process that’s specific to all the hardware and software elements that make up that system—RAM, CPU, network, disks (and I/O speeds), threads, database drivers, application code/architecture, etc., etc. The focus of our performance engineering services is to keep our customers’ systems from reaching that point-of-no-return threshold. The best way to do this, by far, is proactively. Waiting until a system has hit the wall to start tuning it is much more complex, and thus costly, than doing the tried-and-true regular maintenance that’s required to keep a system running smoothly over time. We’ve evolved a very well-honed methodology for finding, prioritizing (not all offenders are equally threatening) and fixing the causes of performance and stability problems. As part of our approach, we’ve developed a way of thinking about performance that we call the “PASS”—Performance and Stability Stack. This is a conceptual view of the “stack” of network, hardware and software components that make up ColdFusion performance and stability (or lack thereof, as the case may be), and I’ll be writing about this soon.

In the meantime, if you’re having performance and/or stability problems (sometimes they’re synonymous, sometimes not), contact us to discuss our leading-edge ColdFusion performance engineering services.

Share and Enjoy:
  • Digg
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • StumbleUpon
  • Technorati
  • TwitThis


  1. Very interested in hearing what you have to say about this topic in the future.

    I’ve been a bit worried about the performance of my server as I redesign my app to use CF9’s new ORM functionality. Any experience with that btw?

    Comment by Greg — September 30, 2010 @ 10:35 pm

  2. Hi Greg. Very good question. Our general attitude about ORM, as well as other abstraction layers in your code (code frameworks included), is this—be careful! ColdFusion is itself an abstraction layer. That is, it abstracts us developers from the nitty gritty details of programming with which our predecessors had to struggle. This is a good thing, as it allows us to get useful things done faster, and the trend towards abstraction has taken place all across the software world. But, abstraction has tradeoffs, like all engineering choices. Most significantly, abstraction layers have performance costs that don’t apply when programming in lower-level languages. So, that means developers who program in these abstraction layers have to be extra-cognizant of coding for performance. Now, things like ORM are abstraction layers on top of an abstraction layer (CFML). That can get messy in a hurry, and not just in terms of performance, but also complexity, thereby taking away ColdFusion’s primary advantage–its elegant simplicity. We have seen ORM implementations where the ORM layer itself is a bottleneck, not to mention a significant contributor to the complexity of the application.

    So, in short, we’d advise the following in deciding to use ORM, or any other abstraction layer with CFML (like code frameworks):

    * Ask yourself: Does this application really need this?
    * Ask yourself: Is my life really easier as a result of using this? (Example: Have you ever had to modify, like, 6 code files to make a simple change to an application)?
    * Ask yourself: Is there a simpler/better alternative available?
    * Test like crazy!!!! Abstraction layers tend to hit the wall very quickly and harshly under even moderate load. If you’re going to use one, make sure you load- and stress-test early and often.

    In our own application development practice, we focus these days on design patterns over actual frameworks. As our own Steve Nelson is famous for saying, CFCs are the framework. Food for thought.

    Comment by Patrick Quinn — October 1, 2010 @ 11:16 am

  3. Hey Patrick, thanks for you detailed response! I’ve actually been a ColdFusion developer for a little while now, but I have never really worried about performance issues until my recent developing with ORM.

    I am currently developing quite a large system, where many objects are used and shared by many different applications on the same system. I have built the system up thus far using an object-oriented, service layer architecture. The service layer currently calls stored procedures for the data, and then manually populates and returns bean objects to the caller. But as these objects have grown larger and more complex, often-times relying on other, smaller objects within the system, I find myself making calls to many parts of my model just to populate a given (large) bean object.

    When I first started looking into ORM to possibly manage some of these dependencies, the thing that really sold me was its ability to lazily load relationships within an object. In my system, one application may only need to use just the base data of a given object, while another application may require the entirety of that object, with all of its relationships (which can be quite numerous). I liked the fact that the loading from the database could be handled on a per-application basis, rather than completely populating an object in the service layer (regardless of if all of the data was going to be used or not). Coupling that with the secondary caching of the smaller, dependent objects (which rarely change), I thought that this may be a good solution to the problem.

    So in my case, development-wise, I feel that the ORM is very worthwhile and reduces a lot of the complexity in the system, along with a lot of the work that is involved in developing. So far, I have been able to drop some 100 stored procedures, which were mostly used for simple CRUD operations and a few lookups, as well as most of my gateway objects, which were no longer needed. (This was a source of changing things in 6 places just to make one small change!) I’m still going to be using stored procedures for reporting type functionality, but I am really loving the development with the ORM otherwise.

    However, of course, the problem that I’m now very worried about is if my server is going to be able to handle it all when this new version goes live! At this time, as a somewhat recent college grad and relatively new business owner, I don’t exactly have the highest end server out there for my system (it’s a rather basic dual core machine with 4gb of ram). I would say that there are probably only 50 people using the system concurrently at any given point, but I have never run into any problems thus far. Hence, load testing was never a concern of mine until now! However, I have heard that Hibernate can scale to some quite large applications, so I’m really just hoping that I have implemented it correctly and it won’t be a problem. (By “hoping” I mean “praying,” as I have put about two months of work into converting everything to use the ORM, along with more development on top of it!)

    Can you recommend any load testing tools or procedures that may aid me in determining if this is all going to work correctly? I have a desktop at home that is relatively close in specs to my production server that might give me a general idea. And any other advice that you can give on this subject would definitely be very much appreciated!



    Comment by Greg — October 1, 2010 @ 5:09 pm

  4. Heya Greg. Thanks for the detailed comment! I’m responding with thoughts about load testing tools and procedures, and I’ve invited other members of our team to chime in with comments on your other points, if any.

    Regarding testing tools, there’s the free Web Capacity Analysis Tool from Microsoft (formerly called Web Application Stress Tool):

    For our part, in the days when we did this work for big, public software companies like Allaire/Macromedia, we used expensive tools like Segue SilkPerformer or Mercury Loadrunner. Since then, however, we’ve standardized on Paessler’s Web Stress Tool, which is both powerful and affordable:

    As for testing procedures, that’s actually a pretty complex topic, since capacity planning is a speciality in its own right. If you’re just getting started, the help docs for the load generation tool you’re using should give you a solid introduction to the basic concepts of capacity planning–steady-state vs. increasing load vs. stress tests, virtual users and think time, test scripting, test data analysis, etc.

    Regardless of what tool you use, we can’t recommend strongly enough that you start doing formal capacity planning ASAP. As I note in my post here, often times the moment of the server hitting the wall can seemingly come out of nowhere, and that’s not a pleasant place to be, especially if you’ve got paying customers. Capacity planning will help you avoid hitting the wall altogether.

    Comment by Patrick Quinn — October 6, 2010 @ 1:57 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment


Server Down?

Maximize Web application uptime by drawing upon Webapper's years of experience tuning and stabilizing many of the world's largest ColdFusion Web applications. Contact us today!