We are currently running a three node cluster with ehcache configured to replicate to the other two nodes in the cluster. Going memcache/repcache would put us in a 2 node cluster?
Not necessarily. The determining factor is the total amount of memory needed to store all ticket-granting and service tickets. The steady state number of service tickets is relatively low compared to ticket-granting tickets due to their typical short lifetime.
I encourage you to do some planning and testing, but our numbers may be helpful to start. We run memcached on each of our 3 CAS nodes with 256M allocated. Right now, one of our nodes is running 46M resident and ~400M virtual with about 3000 tickets (ST+TGT). I'm pretty sure most CAS deployments could live happily inside 512G memory inside one or two memcached nodes using the Kryo-based transcoder, which we use.
I took some time over the past several days to improve the memcached documentation for CAS 4, which I believe you'll find helpful:
http://jasig.github.io/cas/installation/Configuring-Ticketing-Components.html#memcached
I have adjusted the heap in jetty (ehCache in production) to 2G now and we have been watching the memory usage over the last couple days. I did notice a bit of a spike which I attached an gif of.
In working on the ticket registry docs for CAS 4, I realized that our Ehcache example was not configured for disk overflow. Have you configured that? I imagine it would be helpful for your situation. I would definitely investigate that before jumping ship yet again.
M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
