Is it inefficient to define caches in application.cfc, and should I move them to .CFConfig.json? I’ve got about 10 of them defined.
Google tells me that I should define them in onApplicationStart() to avoid the extra overhead of defining them on every request via pseudo constructors, but this doesn’t work (ai slop?) I currently a bunch of them defined in application.cfc because I like having my caches in sync with my code and not having to change things in .CFConfig.json whenever a cache is added/changed.
OS: Ubuntu 24.04 (Noble)
Java: OpenJDK 21
Tomcat Version: 11.0.6
Lucee Version: 6.2.6.19
@Redtopia, Defining caches in Application.cfc is perfectly fine. If the caches are specific to your application, keeping them there is a good approach because your cache configuration stays together with your code. .CFConfig.json is useful when cache settings need to be managed separately or shared across multiple applications. Keeping a single source of configuration and avoiding duplicate cache definitions in both places helps prevent configuration mismatch.
Thank you, and yes I’ve been doing it this way for years. But as far as performance is concerned, it seems like a lot of work is being done on every request because the caches have to be defined as pseudo-constructors. With 10 of them, there’s a lot of code that defines them. So my question is more about performance than whether or not you “can” do it this way.
When you say it doesn’t work when done in onapplicationstart, just what is it that fails?
Of course, doing it there means they’re only defined once, on startup of the app (or if you call that method directly, for an app reload request–which has its own risks).
But you say you’ve done it for years otherwise, but somehow in a way that runs on each request, it seems. Are you not using logic that only creates them if they’re not yet defined? If you are, then it’s unclear what problem you’re trying to solve.
That’s not an attack or a call for a duel. 
We can only go on what you’ve said so far. Hopefully we can better help with just a bit more clarification.
Unless I define these caches as psuedo constructors, the caches simply are not defined when they are being used. And because they’re defined as psuedo constructors, I am questioning how performant this method of defining them really is. If people are defining them only in onApplicationStart(), then I’m doing something wrong because this doesn’t work for me.
What I want to do is follow the best practice for defining caches on a high traffic site. I want to squeeze as much performance out of Lucee that I can, and this is one area that I am questioning. What if anything is Lucee doing to make these cache definitions performant? And does it make sense to refactor these cache definitions by moving them into .CFConfig.json.
Does anybody have anything to add to this? My question hasn’t been answered yet. @cfmitrah @carehart
Defining caches in Application.cfc is a supported approach. Whether they live there or in .CFConfig.json is primarily a configuration and deployment decision, not a performance one.
Since you mentioned the definitions don’t work from onApplicationStart(), could you share that code? That part is the key to understanding what’s happening, because caches defined there should normally be available for the lifetime of the application.