Hi again,

On 4 July 2011 11:45, Vedrin Jeliazkov <vedrin.jeliazkov at gmail.com> wrote:

> So basically, for holding circa 20K policies you need > 2 GB RAM just
> for the OpenDJ server.

As the number of policies in our test setup grows, this rough
estimation is confirmed:

10000 policies require about 1 GB of RAM allocated to the OpenDJ service

We have now more than 41000 policies registered and OpenDJ's JVM
instance has consumed all the allocated heap space (4GB). In order to
proceed further with out tests, I've increased the allocated RAM for
this purpose to 6GB.

Some interesting questions pop in my mind:

1) do we have a rough estimation of the number of policies we would
like to be able to support (at least at this stage)?

2) what is the upper limit of the allocated RAM in a virtual appliance
in the cloud?

3) what is the upper limit of the supported RAM in state-of-the-art hardware?

Since the number of resources in the final OT framework is in the
order of several millions (let's say 10 millions to make calculations
easier), and if the above mentioned linear relationship is maintained
indefinitely as the number of policies grows (this is something to be
verified), this would result in a requirement for 1 TB of RAM
allocated to OpenDJ alone for a setup that scales up to 10 million
policies. This brings up my next series of questions:

4) is such requirement satisfiable?

5) what is the upper limit of RAM supported by modern hardware?

6) what is the upper limit of RAM supported in a single virtual
appliance in the cloud (note that this figure might differ for various
providers)?

7) what would be the associated costs of building and maintaining such
a service, that scales up to 10 million policies?

8) is it possible to distribute the policy processing load between
many instances of OpenDJ? if "yes" -- how does such distribution scale
up (to what number of OpenDJ instances)?

IMHO, all these are things that we should consider when looking
forward for a restful AAA solution that scales better.

Kind regards,
Vedrin