Mailing-List: contact user-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@shiro.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Thu, 26 Jan 2012 06:20:57 -0800 (PST)
From: vdzhuvinov <vladimir@nimbusds.com>
To: user@shiro.apache.org
Message-ID: <1327587657854-7227093.post@n2.nabble.com>
In-Reply-To: <DB5169E5-4A35-4368-8830-C735742ACF6B@navid.ca>
References: <C850A1C0-F687-4F5E-9D4B-169272F39F79@navid.ca>
 <1327562419649-7226206.post@n2.nabble.com>
 <DB5169E5-4A35-4368-8830-C735742ACF6B@navid.ca>
Subject: Re: Shiro on Cluster
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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.