Posted in ColdFusion | Posted on 11-08-2005 | 3,341 views
Sam asked:
Ray, In your blog software you put certain cfc's in the application scope. I've tried this in some of my code but noticed no performance benefit suggesting that I did something wrong and/or did not understand what to put in application scope. Can you explain?
So - first thing's first. I've said it before and I'll say it again. I like my blogware - I think it is "good", but I do not think it is 100% best practices. Of course, nothing is perfect, but I do think that if I were starting from scratch, I would do things differently. I would most likely use Model-Glue and would definitely not have one giant Uber-CFC.
Speaking of the Uber-CFC, if you look at blog.cfc, it is currently close to 1500 lines. That is pretty significant and would definitely lead to a performance benefit if cached. If your CFC is much smaller, though, you won't see a lot of benefit by caching it in the application scope.
However - that being said - I kinda feel like if something only needs to be created one - why create it again? Consider the simple application variable. I typically have a variable for my datasource name. That is just a string. If I were to stop using the Application scope and just set it in the request scope, my application would probably only be about 0.0001% slower, if that. However - there just isn't a need to keep setting it on every request.
Something else to keep in mind - my blog.cfc started off small and slowly grew into the monster it is today. Because I started off caching it, I didn't have to go back and change things around later on when blog.cfc went off the deep end size-wise.
Not sure if this is best practice but it's quicker to code if nothing else.
On a more serious note, if you have stateless service CFCs you might as well instantiate them once into application scope regardless. This isn't really about performance, more about the fact that a service CFC really only ever needs one instance and application scope is a good place to store that one instance.
Business object CFCs - which usually have request-specific state - will need to be created on each request. You can't cache those in application scope because they are different for each request (you might even be creating several BOs of a given type in a single request). Again, that's not a performance issue, that's just plain ol' business logic.
If you load test your application and you prove that instantiating a CFC is a bottleneck, then you might look at maintaining a pool of instances to avoid some of the overhead of instantiation. However, pool management adds a layer of complexity to your code and the instances still have to be re-initialized so you may not see much of a performance gain anyway.
I am currently building an app that is in one giant CFC (using ray's blog.cfc as a model) and I see the advantages. But, coming from a java background I also see a need to create a more object oriented framework by using DAO (Database Access Object) BO (business objects) and other stateless classes to do the mundane tasks. I can't concieve of there being any advantage to sticking these task's in the application scope since you don't need to maintain state.
But, Like ray said, its his app and it isn't an API or designed to be extended in some way. So it works. I'm enjoying writing this app in one CFC, definately making me think a little differently.