Can anyone please tell me if ColdFusion2018 and REDIS (on Azure, or even another REDIS service) are currently viable?
Viable, as in what? Do they work? Yes. Can cf2018 session vars in Redis be stored in an azure redis cache (or any other)? Yes. Do I mean I've done it? Yes. Can I confirm it's highly scalable? No I cannot, because that depends on so many variables, both in terms of your traffic volume and nature, what you store in the session vars, the cf config, and the configuration of the Redis store, its redundancy, etc.
But viable as in, does it work? Again, yes.
Thanks Charlie. Our ISP told us that there were some problems with REDIS for their customers, in that sessions were lost and that there were bugs, and Adobe could not find them or assist. We will give it a go and see anyway. We'd use it for login sessions and other data primarily (nothing complex). I just wanted to see if performance could be improved.
If you or they could share more info, that would be helpful. Sometimes problems like that have a more specific explanation, to counter the more generalized assertion.
Or I hope you'll let us know how it goes. 🙂
I can think of one way to get information on the state of Redis in ColdFusion 2018. If you go to tracker.adobe.com and search for redis, under ColdFusion, you will get the following status
CF-4126425 Closed Withdrawn Unable to start API Manager: "Not able to connect to Redis server." 03/09/2016
CF-4126461 Closed Fixed Setting session storage to Redis causes high CPU usage consistently 03/09/2016
CF-4126479 Closed Fixed Using Redis for Session Management Fails 03/09/2016
CF-4156552 Closed Fixed Add Support for Multiple Caching Engines 05/23/2016
CF-4195240 Closed Fixed external session storage: redis becomes unresponsive under load. 10/05/2016
CF-4195722 Closed Fixed onSessionEnd method is not called when using Redis as external session store. 10/09/2016
CF-4199873 Closed Fixed Typos etc in CFAdmin 10/03/2017
CF-4201603 Closed Withdrawn Memory Variables Redis Password gets changed between Verify Button and Submit Changes 03/19/2018
CF-4203125 Closed Fixed When inputting Redis Password on Session Storage, it is displayed on Caching Page 07/23/2018
CF-4203450 To Track NeedMoreInfo ObjectLoad() Component Never Garbage Collects / ObjectLoad() = Memory Leak 11/09/2018
Good list, BK. And note that only one is open.
So Mark (Tribule), how have things gone for you the last few weeks?
Thanks for the link. We tried REDIS for a week, but disabled it after seeing lots of errors in the CF logs that we could not resolve. Our CMS uses a lot of sessions (even for anonymous users) and so it may have been that our REDIS store (on Azure) ran out of resources.
We will probably re-investigate it some more when our project has gone live. We could see no visible performance gain over the default cache in CF either.
Did you look some more into the use of REDIS in ColdFusion? We, too, are weighing up alternative caching solutions for use in ColdFusion. Like you, I have been unable to find anyone who has successfully implemented REDIS as the main caching engine in a ColdFusion application.
Wait, let's not mix things up. What Tribule was referring to initially and until his last comment was CF's ability to use Redis as an alternative session store. The only choices are that or the default of storing them in CF's heap (not even in ehcache).
The "alternative caching" you refer to now BKBK (and in tribule's very last sentence of his previous comment) is instead about the change in CF2018 to allow "alternative caching engines". That's quite different.
As background for some who may come upon this thread, from CF9 until then, the only caching engine was ehcache. Now in CF2018 Standard one can switch to JCS (Java's caching engine), while in CF2018 Enterprise one can switch among those or memcached or redis.
So BKBK, when you say you have been looking for anyone who has used REDIS as "the main caching engine" for CF, let's just be clear that while you may not have been able to find "anyone" using that, just know that the ONLY people who COULD do it would be a small percent of the CF population: those who are a) running CF2018, b) running Enterprise, c) use CF's caching features, d) knew that CF2018 let you change the caching engine, e) chose to change it, and f) chose redis (vs memcached or jcs). And then g) they'd have to be people who had reason to somehow discuss publicly their use of it. That may well be a very small population. 🙂 But it doesn't mean they've had a problem with it, of course.
Still, I realize you may prefer (or simply hope) to see more word of people using it. That will come in time.
Another challenge is that implementing Redis on Windows is challenging, and lots of CF shops really do use Windows--yep, even large scale enterprises.
But that's where alternatives like Azure's Redis service (as Tribule mentioned) or others will help ease the transition. Of course, then it's an outside resource, with network latency, and its managed elsewhere (so one has to learn how to monitor and twiddle its knobs). I have more hope that Windows shops might instead leverage a Docker container running Redis (in Linux) just to make it easier.
If you are a Windows shop and might be intrigued about leveraging redis, either for sessions or for caching, and you've tripped over implementing redis, do consider using a docker container of it instead. I'll be curious to hear if folks try that, especially those who either test or just run a large load against it.
And of course, like you both, I would look forward to hearing more from ANYONE using redis (in any implementation) for those. But let's do keep distinct the original question (using it for CF sessions--where it's the only alternative and is in CF 2016 and 2018 Std and Enterprise) vs this later discussion (using it for CF caching in CF2018, where it's one of 4 alternatives, but along with memcached it's in CF2018 Enterprise only) .
The explanation may be useful to others, but is not relevant to my question. My question was to tribule. I wish to hear of his experience with REDIS. His original post is, in my opinion, on REDIS as a caching solution in ColdFusion in general. Not only as a cache for sessions. In any case, any information from anyone who has used REDIS will be greatly appreciated.
It was relevant to the two sentences after your question. And I too expressed interest in your question, and repeated it.
As for whether Tribule's first post was about using Redis for CF caching (available in CF2018 Ent) or Redis for CF sessions (available since CF2016), it was admittedly not clear. But his second note did say that one of his concerns was that he heard "that sessions were lost", so he was at least talking about Redis for sessions.
As for most of what I shared, note that I did say it was "As background for some who may come upon this thread..."
Mark (tribule), did you ever get any further with assessment of Redis? And if you did, can you clarify if it was using Redis for sessions or Redis as an alternative distributed caching engine for CF caching?
Sorry, missed a reply to this one.
We were originally on Azure and so REDIS was a built-in option. We tried it again for 2 months, for sessions. No noticable performance gain was noted. It did cause a lot of reported errors, and none could be fixed, we just had to live with them. We eventually moved from Azure since its performance was poor and the costs of using it too complex, so we ended using REDIS at that point.
Thanks for your update.
Yep, thanks. And I realize that you may have otherwise left the whole matter behind (and perhaps wouldn't try it again even if something were fixed).
But I will point out for others who may find this thread that since our discussions here (all from last year, until today), there has been discovery of yet another bug and serious contributor to poor perfmance of CF with redis sessions used, if the CF2018 PMT (performance monitoring toolset) is enabled and monitoring that CF instance. For more, see https://tracker.adobe.com/#/view/CF-4205489.
Was that perhaps the case for you, Mark (tribule)? If it was, it may have been the cause all along.
And if folks read the bug report and comments, you will see that while indicated as "fixed", the build number indicated is beyond the current latest CF2018 update 9's build number (I clarify more in my comment there). Hopefully the fix will make it to the next CF update.
You will see that there was ALSO a problem with FusionReactor (another CF monitor), of the same sort. In fact, the bug was identified and reported by them. So some folks were suffering a double-whammy--IF they had the CF PMT monitoring the instance, and FR as well (which is otherwise normally ok).
Again, leaving this for others even if it does not apply to Mark. HTH.