http://coldfusion.com logo
Join Slack
Powered by
A few CacheBox padawan questions: 1. If I’m workin...
# box-products
p
A few CacheBox padawan questions: 1. If I’m working on just a single server setup (no clustering, etc.), I assume the built-in CacheBox cache will work fine? 2. Is there much of a difference between using the Cache and storing information in the Application scope? I’m aware of the goodness of the timing and expiration aspects, I suppose. Is there a way to have CacheBox (or another routine) regularly update the data in the cache? 3. Any issues with storing queries in the cache (that can then be used for QoQ operations)? I think CacheBox could really help and I’ve watched Brad Wood’s CFCast on the intro to it, but there’s no “Zero to Hero” type thing so I’m a little unsure of the best method of implementation. I have looked thru the Ortus docs as well, so these were my leftover questions. Any pointers would be super-appreciated.
s
1. Yes - I like to define a second Cachebox object cache using redis even with no cluster, but that's more for future scalability than a requirement. 2. Kind of the same thing - if you know you're never going to cluster your app, app scope is just fine, but it's not a big investment to start treating every app as though it might be distributed one day. Still, app scope is super fast (as is Cachebox); but the app scope is not a cache and does not have timeouts, while the cahcebox interface has a lot of 
getOrSet()
type helpers and you have a lot more control as you'd expect with a cache. App scope is OK for things that either don't change, or if you can add a lifecycle interception so that it's updated whenever they do change. 3. I don't like storing query objects - I will store mementos of objects (structs and arrays of structs) but I don't find any advantage to storing the actual query, but I also don't like QoQ and reasonable people may like it more than me, particularly now that it's a lot faster than it used to be.
p
All good info. Thanks!
b
Sam hit the nails on the head I think with his reply
One of the nicest thing sabout cachebox is the fact that it presents an API that leaves your code not needing to care about what's behind it. So whether you keep an in memory cache, or move to a JDBC store, memcached, or couchbase or redis in the future means you don't need to touch any of your code, just your cachebox config.
I have no issues storing query objects in cache, but keep two things in mind • in process/memory caches pass the objects by reference so any changes you made to the query will inadvertently also modify the query in cache. • Out of process caches (redis, couchbase, memcached) must serialize and deserialize non-string objects like queries and that may be slow for large objects so keep that overhead in mind.
Also keep in mind just because your CF servers aren't clustered doesn't mean there may not be value in having an out of process and/or clustered cache. Out of process caches like Redis persist across server restarts so they don't need to warm up. They don't consume your heap space, and can scale out in size without affecting your CF app.
Is there a way to have CacheBox (or another routine) regularly update the data in the cache?
The semantics for data freshness in a cache is handled by your timeouts. This makes it a little like the light in your fridge-- it's only "on" when you looking at it. So if you want a value to never be older than 2 hours, then you set the timeout expiration to 2 hours. A fresh value will be automatically created the next time someone requests that object from the cache, which may be at 2 hours and 1 minute later, or 10 hours later. There's no need to proactively "update" anything in the cache. Just let it get refreshed automatically as it's hit.
s
There may be a few unique scenarios where updating the cache behind the scenes could be beneficial if the normal page load without cache takes a long time
Open in Slack
PreviousNext
Powered by