A general question about using the application scope to store business
objects.
Historically, we’ve used it to store simple things that hardly ever change.
We have an application that has about 700k of client text/html that is
displayed throughout the application. Every page uses some of it. The
legacy version of this uses cfquery and cachedwithin. We are updating it to
use Hibernate.
At what point is a second level cache appropriate? Putting these text
blocks into the application scope is certainly ‘easiest’, but am I chewing
up 700k of RAM to do that?
Using a 2nd level cache is only very slightly more difficult, but we’re not
yet sure if this app will remain on ACF10 (which had a lot of issues with
2nd level caches and ORM last we tried it) or move to Lucee with the rest
of our apps.
All the best-
Sam–
Samuel W. Knowlton
Chief Leagueologist
inLeague * @Samuel_W_Knowlton
http://www.inleague.org
Office: 512.814.8022
There’s a few of ways to handle data that doesn’t change frequently…
Putting it in the app scope is certainly one way, and there’s nothing wrong
with that if you have the RAM overhead to handle it. 700k is minuscule for
most servers and will give the best performance.
Another way of achieving the same thing would be to use a RAM cache w/
cachePut()/cacheGet() functions. Same high performance, roughly the same
memory usage.
The second way of handling it would be to utilize EHCache w/
cachePut()/cacheGet() functions and let EHCache manage it in memory or
on-disk with various settings available to you. This is a middle of the
road approach that can save on RAM at the expense of disk I/O, and also
provides for distributed caching schemes for clustered servers, etc.
The third way would be to objectSave() them to disk and objectLoad() them
when you need them. Saves all the RAM but takes a performance hit for disk
I/O and requires you to expire your own data (vs. RAM/EHCache/cachedwithin
timeouts). You can also just store it to ram:/// and get the performance
back, but then you’re back to using RAM anyway.
You can also mix and match between those depending on the data, how often
it’s used, how often it changes, etc. And if you’re running SSD’s, the disk
I/O performance is only slightly slower than direct RAM access.
I ran into too many issues with ORM caching (in both ACF and Lucee) so I’ve
leaned towards using the other functionality I mention for most of the
static data caching I do these days.
My 2 cents 
– Denny
Thanks, Denard, that’s very useful!
Just out of curiosity, which issues did you run into with ORM caching in
Lucee? We were still planning on employing it for some other functions.
Hey Samuel,
Sorry for the delay in responding. My evidence is merely anecdotal and I
never did determine the actual root cause, so take what I’m about to share
with a grain of salt as it is unlikely to apply to all situations, but…
I had a client come to me about 7 mos ago that had rewritten a
significant portion of their application to use ORM and 1st/2nd level
caching in an attempt to improve performance of their clustered
application. After having done so, however, they noticed performance
degraded over time and required a restart every couple of weeks. They were
initially running ACF10 and the nearest I could figure was that the number
of cache ‘misses’ were disproportionately high, causing reloads of data to
occur with an ever increasing frequency. We ended up migrating them over to
Lucee 4.5 and performance jumped back up and stayed up longer, but
ultimately still required a restart about once a month as performance
degraded again. Ultimately I ended up helping them to isolate what parts of
their query caching strategy could be better served with an object cache
instead and another re-engineering effort later they seem to have remained
stable ever since.
Again, that’s totally anecdotal and applied only to the one specific
client in a clustered environment, and root cause other than ‘cache misses’
was never established, much less understood, so mileage with ORM caching
may vary wildly from this one use case. So, I don’t want to poo-poo ORM
caching in general - just a personal preference of mine to avoid ORM
caching as a result of working with that one client, and the ease and
control over caching the other functions I mentioned provide.
– DennyOn Thursday, July 7, 2016 at 8:39:14 AM UTC-4, Samuel W. Knowlton wrote:
Thanks, Denard, that’s very useful!
Just out of curiosity, which issues did you run into with ORM caching in
Lucee? We were still planning on employing it for some other functions.