The Impact of Consolidations on I-Server Memory

[sunnyphoenixier]

We all know that Consolidation requires calculations to be done in Analytical Engine. But how do you evaluate its impact on I-Server?

we have a situation in which we wonder if we should use Custom Gruop instead of Consolidation to avoid the impact on I-Server.

Have any of you run into this before? How do you evaluate consolidation's impact on memory?

In our case, the consolidation will be based on one attribute with 3 possible values. The consolidation elements are:
-Element 1: Attribute value 1
-Element 2: Attribute value 2
-Element 3: Attribute value 1+2
-Element 4: Attribute value 3
-Element 5: Attribute value 1+2+3

Any suggestions will be greatly appreciated!

Thanks

Phoenixier

 

[iolaper]

I will tell you whatever I know.
Consolidations are always better than Custom groups.
The above scenario can also be done using custom groups based on filtering criteria. But custom groups will cause a lot of overhead to the IS as each filter you use is a report(a pass in the SQL view).
Though there is a load on your analytical engine due to consolidation you will not cause unnecessary clogging due to several users trying to run your report based on custom groups.
From my experience I've found consolidations to be a little time consuming to create(compared to your custom groups which are just filters) but consolidations generate easier SQL and are more efficient.

If I didn't answer your question let me know I can do some more research.

 

[sunnyphoenixier]

iolaper,

Thanks for the feedback. I don't have a definite answer on this. Our understanding is Consolidation impacts the memory of IS much more than Custom Group, probably not much more in this case since there are only 3 values for the attribute, while Custom Group takes much more resources to process the SQL.

We are still exploring this topic as of now. I will post our decision on this finally.

Thanks again,

Phoenixier