RedisStorageService

[Michael A Grady]

> On Mar 29, 2017, at 9:28 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 3/29/17, 10:18 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
> 
>> Thoughts?
> 
> I had thought there already had been something done, but if you can't find anything, then short of just a quick double check on users (higher traffic, so more likely to get seen), I guess not. I know I've been asked about it for the SP on occasion, so I'm probably thinking of that.
> 
> My opinion of memcache is pretty well known, so I'd be very interested in a better option. Is there a compare/contrast of this with Hazelcast? Unicon has that one mostly done, though I think it needs some shoring up if it were to be pulled in.
> 
> This is one of those faddish areas where people seem to glom onto things all the time and not just stick with a solution, which makes supporting things difficult.
> 
> It's premature to be talking about it, but longer term I think I'd be happier if we had a smaller set of better choices and eventually deprecate the memcache code so we can stop supporting it at some point.
> 
> -- Scott
> 


Hazelcast performs well, has numerous stats comparing its performance to Redis or Memcache, but while they make available an "open source edition", there isn't any support structure in place if you need help. You need to pay for a supported edition. And we aren't really talking "big data" here, where those performance differences would become key. Redis, on the other hand, is fully open source with the usual user mailing list for support.

Unicon has also been considering creating a Redis storage backend for the Shib IdP.  As Marvin indicates, it has the advantage of supporting replication out-of-the-box, and the option for persisting data to disk. And it is one of the two options (memcache being the other) supported by AWS's ElastiCache service. 

--
Michael A. Grady
IAM Architect, Unicon, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170329/85979c21/attachment.html>