One of ColdFusion 9's major new features is, of course, its built-in Hibernate-powered ORM capabilities. Ever since the CF9 public beta, there has been a lot of discussion about this feature in the CFML blogosphere. I have to say that this feature seems really cool from the standpoint of productivity and in the way CF9's implementation has simplified working with Hibernate. The notion of letting ColdFusion create and manage your database based on your object model without writing a single line of SQL fits right into ColdFusion's RAD philosophy.
Despite all of this, I have been very wary of using this feature in my own development practices. It's not that I have any philosophical reasons for not using an ORM, my reservations are more of a practical nature, but may be ill-founded which is why I'm writing this blog post in the hopes of getting some good feedback. It is no secret that Adobe targets ColdFusion mainly for the enterprise. However, I don't work on enterprise applications on dedicated servers or clusters. As a solo freelancer, my clients are mostly small businesses and organizations. They either use shared hosting or host with me on one of my VPS accounts. How would CF9 ORM do in these environments? I've tried googling on this subject, but there's really no info out there right now on the subject. But I've seen a couple of comments on blog posts which kind of fed my fear that CF9 ORM is not suitable for shared hosting (or multiple apps on one server). In this comment on Brian Rinaldi's blog, Hussein Grant says "My only major concern about it is the amount of memory ORM systems generally tend to devour, especially in a shared hosting environment" and goes on to paint a hypothetical situation where he puts a client of his on a CF9 shared hosting account which subsequently goes "to hell" because half of the people on the server is using ORM. Then Peter Bell comments on his own blog post to say that "Hibernate doesn't come for free" and expresses his reservations about how CF9 ORM would work "hosting (say) 50 websites each with its own Hibernate session on a single regular server."
So I'm interested to hear from those who may know more about this than me. Is CF9 ORM an "enterprise-only" feature or am I way off base having these concerns?
Dec 24, 2009 at 9:01 AM It is no secret that the use of any ORM will cause an increase in processor usage and in memory. There are no free lunches and if you want the computer to do more work, it must consume more resources. Just like if you want the computer to do less work, you must do more work to fine tune the processes and such.
I'm not saying that ORM is an Enterprise feature, not at all. I'd say that ORM might not be for shared hosting though. As the manager of a popular ColdFusion framework I answer emails all the time about issues with frameworks on shared hosts. Some hosts are better than others, that much is true, but I have very little respect for shared hosts and I wouldn't put much more than a simple website with a few simple forms on shared hosting.
However, shared hosting has nothing to do with Enterprise. You aren't using the word Enterprise correctly because your post largely assumed a dichotomy of Shared Hosting or Enterprise. There are heaps and heaps of other options out there. For example, a Virtual Private Server (VPS) can be had for barely more than a shared hosting account, but you'd have the protection of your own server resources. Meaning that while you are actually on a physical server with other customers, the resources on that server are fractioned off and protected from runaway applications/customers on the same server. You get what you pay for...
DW
Dec 24, 2009 at 9:19 AM Thanks for the feedback, Dan. I do realize that there are performance tradeoffs with using frameworks, as I've had experience using them.
I also recognize that I may have simplified the dichotomy of Enterprise vs. shared hosting. I was merely alluding to the fact that you won't find enterprise apps on shared hosts, and so if CF9 ORM isn't suitable for shared hosts, that would make it "enterprise-only."
You also brought up VPS as an alternative. As I mentioned in my post, I use VPS accounts for my clients as well as shared hosts. In fact, most of my clients are on my VPS servers and I only really use shared hosting for the simpler sites, for the reasons that you mentioned in your comment (so again, we're in aggreement).
But what about VPS? Say I have a CF9 VPS account with 1 GB of RAM hosting 20-30 web sites. Would I have anything to worry about if all of those sites were using CF9 ORM? Is it all right for there to be 30 separate Hibernate sessions running on one server? You see, I have a good understanding of those issues when it comes to running sites on CF frameworks, because I have a better understanding of them. But Hibernate to me is all voodoo.
Dec 24, 2009 at 9:29 AM Actually, Dan, I take it back -- I wasn't presenting an Enterprise/shared host dichotomy. If you read my post carefully, I also asked about VPS. Basically is CF9 ORM cool with multiple apps/sites on one server (which includes the shared host and VPS scenarios), or is it really meant for enterprise apps?
Dec 24, 2009 at 9:42 AM I think that there are many, many apps that wouldn't be considered "enterprise", but are way too big to be put on shared hosting of any sort.
I think that ORM applications have the same base rules as any other application. Depending on the complexity of the app and the expected load, you're going to need more resources. If your apps are small enough with light enough traffic to go into shared hosting, then you probably don't have to worry much about their ORM usage.
Also, your question about VPS is irrelevant in your specific case. You're using your VPS as a shared hosting environment. If you had an app on a dedicated VPS account, that would be a different story.
Dec 24, 2009 at 9:45 AM Tony,
The answer isn't as cut and dried as we may like. It totally depends on how you are using the CF9 ORM and what your applications do.
As you know, there are differences in the way applications in a JVM context can use memory.
For example, if given an infinite amount of space, your application may choose to cache all objects in the database.
This means any object lookup would be from the cache and would avoid having to go to the database for a disk hit.
However, if memory isn't infinite (which it never really is), then garbage collection would kick in, potentially reaping less frequently used objects and reclaim memory. This limits the number of objects stored in RAM and increases the database activity, cfc creation and disk I/O operations.
So it really sort of depends on what the applications do, and how you are using the CF9 ORM. For example, are you using relationships where one to many collections are loaded? If so, that means probably many more objects are loaded to represent a particular object than if you just used a straight up CFQuery.
The only way to know what the impacts are for your particular applications would be to craft a load test and monitor the results. I will say that using the CF9 ORM will consume more memory than not using it, even in light of the immense performance improvements in CFC creation and usage. See: http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-orm-and-cfc-performance/
Dec 24, 2009 at 9:48 AM Dan always has better responses than I do :)
FYI, when putting Pintley under load testing, I saw my memory usage climb up to 2Gb. It all comes down to performance tuning... setting lower limits in ehcache, increasing the amount of ram available, etc.
Dec 24, 2009 at 10:02 AM Well, I don't think my question about VPS is completely irrelevant. There are shared hosting companies who put hundreds of sites on a single server. I won't put more than 10 on each of mine (my question about having 20-30 sites on a VPS was a hypothetical).
Also, of course I know there are non-enterprise sites that are too big for shared hosting. I think people are getting too caught up with that distinction and missing my main point, which is that there are consequences to using CF9 ORM in certain situations.
Let's see if I can rephrase the issue. Before CF9, we had ORM frameworks like Reactor and Transfer. Now, those are essentially frameworks which add an abstraction layer with which to interact with your database. Everyone understood that to reap their benefits, there is a tradeoff because additional code has to be executed. Therefore, using these frameworks incurs a performance "penalty" over using the cfquery tag. Now CF9 comes along that has Hibernate BUILT-IN. There are no additional librariess or core files needed in order to use it. Since that is the case, there may be CF developers (probably those unfamiliar with Hibernate) who will assume that using the new ORM features is the new "cfquery." And who would blame them? I mean -- it's built in to ColdFusion, right?
But from what I've read and the comments here, using CF9's ORM features isn't like using cfquery (I don't think anyone would advise me not to use cfquery on a shared host). So I just think that there are consequences to using these features in certain situations that aren't really being talked about.
Dec 24, 2009 at 10:22 AM @Dan
It seems to me that a lot of those factors you describe that affect JVM memory usage aren't really Hibernate-specific. I can run a ColdBox app using DAOs and Gateways with methods returning arrays of objects which I can cache using the caching system built into framework and those same considerations apply. I guess I'm more in the dark about how Hibernate itself can affect memory usage. I'll refer back to Peter Bell's comment about his concerns about running multiple Hibernate sessions on a single box. I have experience with memory usage and framework-based apps using CFCs, but how the heck do multiple Hibernate sessions affect memory? (I still barely know what a Hibernate session is). I guess in the end, your recommendation to load test is basically the answer. And this proves my point that just because the ORM feature is built-in, it shouldn't just be used wherever you feel like.
Dec 24, 2009 at 10:27 AM IMHO, memory and processor speed are much cheaper than purchasing additional developer time. It my career, ORM pays for itself again and again by letting developers focus on functionality, not plumbing.
Dec 24, 2009 at 10:28 AM Tony,
I get the basic point of your post. And to help you understand what I'm saying, let me say this: If you need to run some super-complex SQL statement on a high-traffic site, don't use CFQUERY on a shared host.
If you really want a blanket statement, then here it is... If your application matters, don't put it on shared hosting, ever. I define shared as "more than one unrelated application using the same operating system", so even your VPS configurations are shared hosting in my eyes.
Dec 24, 2009 at 11:20 AM @Joe
I have no general biases against using an ORM. I'm just trying to get a handle on the trade-offs and considerations that come into play for the kind of apps I write (i.e. small applications on multi-tenant servers).
@Shannon
I never asked for a blanket statement about whether I should use shared hosting. I mentioned before that I only put very simple stuff on shared hosts (so I think we're in agreement there). But I disagree with equating my VPS setups to shared hosting. With VPS, I have a small number of sites in an environment where I have pretty much complete control of my resources and how it's configured. With shared hosting, the level of control is very limited in comparison and you're sharing resources with who-knows-how-many hundreds of other accounts.
Dec 29, 2009 at 8:01 AM The problem with VPS is that people do tend to think of it as exponentially better than shared hosting. While it does have it's benefits, VPS should not be considered a robust solution (by itself, at least). Yes, you have dedicated resources, but the I/O of that physical machine is still shared. This means disk, CPU and memory access are still bottle-necked by other VPS on the same machine and therefore represent issues with performance of applications.
I have a fair amount of experience with virtualization and my experience is that a virtual machine configured with the same specs as a physical machine will positively be considerably less performant than the physical machine.
I do not agree with Joe's blanket statement of "memory and processor speed are much cheaper than purchasing additional developer time" (sorry Joe!). This is a dangerous mentality to get into, and I have seen it cause issues time and time again. Performance must still be a consideration for development, regardless of how easy your tools make your job. Remember, development is short term, maintaining and hosting the application are long term endeavors. If your application does not perform well given the platform it is hosted on then you will lose customer trust, and also be forced to spend thousands on more hardware and software to eliminate the issues. This is not a one time cost, as your application scales the costs also increase exponentially. To get an idea of costs, I suggest writing a simple CF application without a framework and do the same with a framework and load test both.
I'm not saying that you shouldn't use frameworks and tools that help you code better or faster, they can be a good thing. But you really need to balance whether or not you can AFFORD to use frameworks for the specific app you are developing.
In summary: Don't expect much out of a VPS and always consider platform vs performance vs cost when choosing how you are going to build an application.