Process running on PAoC takes significantly longer than local

[gtonkin]

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.

[Adam]

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.

[gtonkin]

..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.

[Adam]

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?

[MarenC]

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

[gtonkin]

...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.

[gtonkin]

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.