Most production Shiro environments will delegate state management to a quality CacheManager implementation. For authentication and authorization caching, this is straight forward - those cache entries can reside in the memory of the local machine only, or with a distributed caching mechanism (Memcache, Ehcache+Terracotta, etc), in the memory of an accessible cache node.
For actual Subject sessions (e.g. subject.getSession()) this same cache mechanism is often used, so long as sessions are saved to a persistent store if memory becomes constrained. This persistent store can be a disk or disk array, an RDBMS, a NoSQL data store, or anything similar. The SessionDAO implementation (e.g. CachingSessionDAO) can be used for a if-not-in-memory-then-query-the-store approach, or you can use the EnterpriseCacheSessionDAO which assumes that the cache itself knows how to overflow to a persistent store (e.g. TerraCotta+Ehcache, Coherence, GigaSpaces, etc) and you don't need to tell Shiro what that persistent store is. So, this question is really about Cache management - how much cache memory will you enable for your application cluster? Is your cache distributed across multiple machine nodes? The cache does not have to be distributed if you use load-balancing with sticky routing. That is, if each application host has a local cache running, and all requests from a particular client can be routed to a particular machine, you'll see good performance benefits. The tricky part is ensuring that once a cache instance starts to fill up on a given host (e.g. ~80% high watermark) you direct new client requests to another cluster node. This implies coordination between the load balancer(s) and each application node so the LBs know when to direct new hosts to a new node. A distributed cache mechanism however can allow one to use 'dumb' load balancers and any local-vs-remote data segmentation can be managed by the caching product itself. HTH, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com On Thu, Jan 26, 2012 at 6:20 AM, vdzhuvinov <[email protected]> wrote: > > Navid Mohaghegh wrote >> >> Thank you Vladimir. I try to be as specific as I can: Image a cluster of >> 4 servers each has a quad processor AMD Opteron 6272 (e.g. total of 64 >> cores per server running at 2.1 GHz sharing a 16 MB of L3 cache). Each >> server has 64 GB of ECC registered DDR3 memory clocked at 1333MHz. The >> servers will be connect using Infiniband links of 40 GB/s. We can add >> SSD/HDD for caching on disk or persistent sessions. I want to know how >> many sessions concurrently in total can be tolerated here and how fast we >> can expect to get the authentication done (e.g. average of 15-20 ms for >> the authentication request and persisting the session ...?). Thank you. >> > > I cannot give you an answer, but here is how you can get a feeling of what > to expect. > > In terms of memory, if a single session object is 1kByte on average, you > would be able to store 1 million sessions in 1Gb. So memory space is not > likely to be an issue for sessions that store just a few strings of info. > > The other factor is processing load and this will depend on the number of > HTTP requests you get per second. You may look at benchmarks to get a > feeling for that. > > If you're planning to use Terracotta here is one useful guide: > > http://docs.terracotta.org/confluence/display/docs35/Deployment+Guide#DeploymentGuide-MemorySizing > > My rule of thumb is not to worry too much about actual hardware performance, > but to make sure fault tolerance, disaster recovery and the ability to scale > and stay fluid is well thought of in advance. > > Vladimir > > ----- > Vladimir Dzhuvinov > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Shiro-on-Cluster-tp7225939p7227093.html > Sent from the Shiro User mailing list archive at Nabble.com.
