Performance on Applications/Contributor on PAL 2.0.8

[MSidat]

HI All,

Just seeking some advice to see if I can improve performance on our TM1 Applications/Contributor

Just going through the upgrade alongside assistance from a Consultancy firm from 10.2.2 to PAL 2.0.8 and we now have our Dev Environment set up and working. The Architecture is the same as our previous set up with TM1 Server, Applications Server (IBM Websphere), Cognos Analytics (Just for Authentication) all on one server. We have installed PAW on a separate server although this in unlikely to be used in the near future. All secured by HTTPS. Office 2016 on the server.

The actual TM1 Server performance seems fine (Using Perspectives/Architect), nightly chores are a lot faster, cube opening up times and recalcs are about the same or faster. (Some of the performance increase will be due to faster cpu speeds)

We use TM1 Applications and it is painfully slow at times. I have trimmed it right down and republished the application with just one existing websheet which has around 350 cells of TM1 Pulled information (mainly dbrws) and has 1 action button which runs a Master process for a chain of processes.

Initial Load of the websheet takes nearly 30 seconds (compared to more or less instantly on 10.2.2)

On changing of some numbers and then clicking on the Action Button I can see the processes run as normal in a couple of seconds if that, dialogue pops comes up to say its run successfully, but I cant click on the OK button as its still showing the processing cursor. This seems to be in excess of 15 seconds. Looking at the logs at this time, I can see the processes finished a while ago but the TM1 process in task manager is still utilising a lot of cpu.

Commit takes quite a bit of time, Submit is relatively quick.

Also noticed a little issue that once submitted, I can still change numbers on the websheet, it doesn't appear to be locked down. Normal behaviour would be that you would have to reject it before you could change number again.

Would appreciate any feedback from anyone who has been in a similar situation.

[tiagoblauth]

Not sure if this will help, perhaps I had to understand a little better your problem.

We use TM1 Applications and it is painfully slow at times. I have trimmed it right down and republished the application with just one existing websheet which has around 350 cells of TM1 Pulled information (mainly dbrws) and has 1 action button which runs a Master process for a chain of processes.

If you have too many cubes, formulas linked based on this data, the commit process can be slow. With TM1 Applications you can remove formulas references to this data and update data changes only on submit by running TM1 TurboIntegrator process on submit.

Also noticed a little issue that once submitted, I can still change numbers on the websheet, it doesn't appear to be locked down. Normal behaviour would be that you would have to reject it before you could change number again.

It seems your user have administrative privileges.

[MSidat]

Thanks tiago.

I have managed to speed it up considerably, it turned out to be more of an underlying model issue, particularly around the use of a rule driven string cube which we use for mapping purposes.

The issue around submission still exists, but not sure if it is expected behaviour.

User 1 takes ownership, changes numbers and then commits and submits the node. This user remains in the application in this particular node and can still change numbers and click action buttons (commi/submit is no longer possible as greyed out).

If this user logs out and a test user goes in with access to that node (or even an admin user) he can view the node but cant change any data or click on action buttons. This part is definitely expected behaviour, but I would have expected that once you submit a node then the cells/action buttons should be all locked even for you as the owner until it has been rejected.