Has anyone tried using Dragonfly as a drop-in repl...
# lucee
d
Has anyone tried using Dragonfly as a drop-in replacement for Redis yet? https://dragonflydb.io/blog/dragonfly-production-ready They claim you should be able to use it as a direct replacement for Redis and it's supposed to be magnitudes faster and more efficient. Just wondering if it works with Lucee's Redis extension out-of-the-box and if it really lives up to the hype.
👀 1
@bdw429s Have you tested the Ortus Redis Cache Extension for Lucee w/Dragonfly?
b
@dswitzer No, I haven't. @lmajano?
d
@bdw429s Have you had better luck with using Redis for caching over ehCache?
b
I haven't really used EHCache. It's in-memory so doesn't really scale well and doesn't create a shared cache across all my load balanced servers
🙏 1
We actually use Couchbase for all of Ortus' sites
d
Are you referring to Redis or ehCache not scaling well?
b
ECache. And maybe "not scaling well" isn't the right words-- just that if you are using Adobe or Lucee's built in EhCache implementation, then it's locked in the heap of that specific JVM which means • you lose it on restart • it uses your heap • it isn't shared across servers • and all cached data is duplicated across your cluster
Now, if you had some sort of external shared EHCache server, that wouldn't be an issue
But it wasn't clear what you mean there
d
You can definitely cluster ehCache (we're doing it).
b
Well, you know more about it than I do, lol. I've only used the out-of-the-box EHCache implementation Adobe and Lucee give you and it's not clustered ¯\_(ツ)_/¯
d
The way it works in a cluster (or at least the best way we found to configure it) is to just have ehCache send signals when cache has expired, but not to serialize cache across the cluster. This does mean that each node has to warm up the cache separately and it has it's own cache pool, but it works okay.
b
Just having the cache weigh on my heap is enough for me not to want to use it. I like having my cache fully external so it can grow as large as it wants and not affect my java heap space
d
Out of the box it can be clustered, you just have to modify the ehCache XML file
b
With Couchbase, for example, there is only one copy of the document regardless of how many CF nodes I have and it stays there across a restart or deploy
d
Anyway, that's why I was asking if you've been using Redis for cache. I'm evaluating options that might be stronger than ehCache
We occassionally have issues where packets are dropped, so the cache becomes invalid. Doesn't happen frequently, but when it does it causes issues.
b
We have several clients using it and I know @lmajano and @jclausen are fans of it. I just haven't had the opportunity to dug in too much. They may be able to speak to how it compares to EHCache.
l
FYI, ehcache only clusters, it does not distribute
🙏 1
it has a big impact in network chatter.
I did not have very good experience when using under load and many clustered instances
since it has to keep up with all the messaging and replication
Your best bet is a distributed cache that can act on sharding and replicas
👍 1
Couchbase, Redis, and Mongo, even ElasticSearch
are the best bet
We have built all of those extensions so we could test the different approaches
all of them are incredible and solid
it comes down to just your preference in all reality
couchbase is harded to containerize
redis is easy
mongo we hav enot tried
elastic search is easy
I would probably chose between couchbase, elastic, redis, because we have tested those
@jclausen is our Mongo guy
he can attest to mongo
But I can attest that our Couchbase cluster has not been restarted in over 2 years
it's solid
I lie, I restarted them when I updated them one by one
🙂
d
Thank you both!
l
Redis has the added benefits of pub/sub
that couchbase and es don't have
and our extension supports it
this allows you to build event driven paradigms in your code as well