TM1 Forum

Hi everyone,

I am running what should be a very simple process:
- create a view based on a single month and on one measure, Sales Revenue. Other dimensions are All N/Leaf elements. View only have leaf elements.
- for each cell in the view, look up the corresponding Units via a CellGetN in the same cube, purely a different measure all other elements are the same.
- derive the Price through some division
- write Price back to the cube.

So far pretty basic stuff.
If I run this process on my mega dataset of 3 records, it takes less than a second to run locally.
Running the same on PAoC takes a fair bit longer 812 seconds.

Dataset is identical, processes are identical etc. etc. as I took a backup from the PAoC cloud to run locally.
Local TM1 is 11.8.100.13 (PA 2.0.9.2 I believe), Cloud version I believe is earlier, 2.0.9.1
Local machine is a laptop - cannot comment on the PAoC server.
TM1s.CFG is the same apart from ports and paths.

The sales cube being queried and updated has some rules but no C: level rules above the data being queried or written to.
Remove rules completely with no impact on timing.

Where I do start getting some dramatic changes is when I tweak the ViewExtractSkip functions.

My Standard settings are:
ViewExtractSkipZeroesSet(sCube.Sales,sView,1);
ViewExtractSkipCalcsSet(sCube.Sales,sView,0);
ViewExtractSkipRuleValuesSet(sCube.Sales,sView,0);

If I change ViewExtractSkipCalcsSet to 1 or ViewExtractSkipRuleValuesSet to or have both set to 1, the process finishes almost instantly on PAoC.
Keep in mind that there are no C: levels in the view or when rules were removed no change.

As soon as I set both ViewExtractSkipCalcsSet and ViewExtractSkipRuleValuesSet to 0, the process just seems to get stuck at Completing Prolog...

I don't mind setting all three options to 1 but cannot figure out why it should differ between PAoC and Local.

A bug perhaps? Anyone seen this or noticed that their cloud processes at some point got very slow?

Thanks in advance.


Other notes:
Does not matter if I run via PAW or execute via Perspectives in the rich environment.
Sales cube has 10 dimensions but number of elements is trivial compared to most models I have worked with. Customer and Products are the biggest with about 5000 N levels in each.
Both Customer and Product have Hierarchies but these are not being used - Subsets using ALL N based on a filter by level - dynamic vs static did not seems to have any impact either.

Hi George,

By PAoC, I assume you mean "IBM PA on IBM Cloud"? Within that, there's several products that IBM offers: Trial / On Demand / Enterprise Standard / Enterprise Premium. Which one are you using?

Regarding

Anyone seen this or noticed that their cloud processes at some point got very slow?

I am on Enterprise Premium and none of our processes take more than a reasonable time to execute.

Adam wrote: ↑Tue Dec 01, 2020 4:22 pm ..By PAoC, I assume you mean "IBM PA on IBM Cloud"? Within that, there's several products that IBM offers: Trial / On Demand / Enterprise Standard / Enterprise Premium. Which one are you using?

HI Adam,

Should have mentioned that - Enterprise Standard, Dev environment.

I don't think it's a hardware limitation then because the enterprise tier is multi core. Dev and prod are identical in the specs.

Sounds like it may be a glitch you're coming across.

Possible to change the version on your laptop / spin up VM to the same version as PAOC and see if you can recreate it?

Hi,

Given the view is all N level but you are not skipping Consolidations, could this somehow be the issue/bug?

Have you tried creating a view which includes a consolidated measure, applying your standard ViewExtractSkip settings and see if the timings are reasonable?

Maren

MarenC wrote: ↑Tue Dec 01, 2020 5:42 pm ...Have you tried creating a view which includes a consolidated measure, applying your standard ViewExtractSkip settings and see if the timings are reasonable?...

By creating the view with one dimension containing C: and N: levels and leaving ViewExtractSkipCalcsSet to 0, the process takes the same time as on a local 2.0.9.2 (11.8.100.13) server.
I guess there was definitely something in 2.0.9.1 that is causing havoc.

For now I may just need to remove the FilterByLevel from my subset and do an ItemSkip if ElLev>0 in data or set ViewExtractSkipCalcsSet to 1 and leave the ElLev check out - both options would work but ViewExtractSkipCalcsSet should be more optimal. Either way, looks like for now I will need to use ViewExtractSkipCalcsSet=1 as I only haev N: levels.

Did not see any mention of this kind of thing in the fix lists but could be there somewhere.

Thanks for the assistance Adam and Maren - appreciate it.

Edit: Having the same issue on views with C: levels where ViewExtractSkipCalcsSet and ViewExtractSkipRuleValuesSet are set to 0.
In this case I can set ViewExtractSkipRuleValuesSet to 1 and runs like lightning but there will be cases where I need C: levels and rule based values.
Will be asking IBM to upgrade server version on the Cloud instance.

So after an upgrade from 2.0.9.1 base (11.8.00000.33), no IFs applied, to 2.0.9.3 (11.8.00200.24) the issue seems to have been resolved.

Processes are back to a second or two to complete.