On Fri, Dec 31, 2010 at 11:18 AM, Marcel Offermans
<marcel.offermans at luminis.nl> wrote:
> Hello Mark, all,
>
> On 31 Dec 2010, at 10:04 , Mark Machielsen wrote:
>

>> @Bram: for the cons you state "I got OOM at 500 tenant with 256M memory in 
>> poc setup": what causes this OOM? It seems to me as a pretty simple 
>> application which only 500 tenants (and sure, only 256M memory). It is the 
>> overhead of 500 containers or something else?
>
> My guess would be it is, but you can quite easily run a benchmark that 
> instantiates and starts 500 completely empty containers and measure memory 
> consumption. Only half a megabyte of memory for a container does not sound 
> too bad.
>

Yes, it was basically the overhead of 500 containers in which I
deployed some 5 bundles each (shell/tui/dm/dmshell) along with the
administration in the parent container as each container is a service
in itself, has dependecies etc etc. We would have to do a detailed
analysis of what happens, but agree that half a mb per container does
not sound so bad.

>> What would be the memory footprint for BC assuming all BC specific bundles 
>> are tenant unaware, assuming BC also needs memory for caching purposes.
>
> I'll leave that one to Bram, but in general I think it's a hard question to 
> answer because I cannot imagine that it's independent of how BC is being 
> used. Unless you're talking about code size, not runtime consumption.
>

Very hard to say. In principle BC is only a few objects in term of
business logic (rest services / servlets/ service objects) so that
should not matter significantly. Then there is the reduncancy in class
loading poluting the permgen when bundles are deployed per container.
This can be significant, but largely depends on the amount of classes
and in the BC case that is not very much either. This real diff will
be made by domain objects / caches which is obvisously very
implementation dependent, you could it right or wrong in both
scenarios, but would be a likely reason to have for instance a tenant
cassandra.

Regards,
Bram

Reply via email to