User Performance issue

[cdhodge2002]

Has anybody experience performance issues that seems to be related to specific user. I have a user you is experiencing massive performance issues. I created a test user group that has the same security rights as this user and I do not experience even a fraction of the performance issues this person is experiencing. There is cell security associated with this application, but I would think that if this issue was system wide everyone would be seeing performance issues.

[jim wood]

This could be many things. They could be accessing a particular element that a rule is not right for it could be anything. You need to look at the logs and the likes of TM1 top.

[Alan Kirk]

Has anybody experience performance issues that seems to be related to specific user. I have a user you is experiencing massive performance issues. I created a test user group that has the same security rights as this user and I do not experience even a fraction of the performance issues this person is experiencing. There is cell security associated with this application, but I would think that if this issue was system wide everyone would be seeing performance issues.

I think you'd need to be more specific about "performance issues", especially in comparison to other users. (You haven't even indicated which environment this is in.) I've encountered cases where someone complained that their performance in Excel Client was extremely slow and it was nothing more complicated than them having calc mode in automatic.

[cdhodge2002]

OK, Let me be more specific. We are using TM1 contributor on 9.5.2. The client is having an issue where a tab is taking 4 + minutes to calculate and render. Then anytime they expand the hierarchy the tab takes 4 + minutes to recalculate. Now when I go in as my test user in the same environment I have none of these issue and the tab refreshes with no problem. This test user has the same credentials as the user who is experiencing these issues. I have eliminated as many cellsecurity rules as possible and am fine tuning feeders, but if it was something like that I would expect my test user to be experiencing issues as well.

[Martin Ryan]

When you say "tab" do you mean a worksheet? Or a cube view? Or a TM1 Web view?

To pick up on Jim's comment about TM1 Top, I found when my users were recently complaining of performance it (and Task Manager on the server) was very useful to find what was causing the problem - in your particular case I expect it will actually show that TM1 is doing very little during this calculation time and that the hold up is at the other end. From the way you describe the problem it sounds like it must be a user environment issue.

Martin

[cdhodge2002]

This is occurring in a cube view. I have monitored TM1top and task manager on both the web server and application server. When I open the tab with my test server I can see in tm1top that it calculates for a second, then renders for me. When this user logs on, I can see tm1top spin for 4 minutes and that 1 processor is being fully utilized. It is not an environment issue as I actually did the test while I was on the web server.

[tomok]

When I open the tab with my test server I can see in tm1top that it calculates for a second, then renders for me. When this user logs on, I can see tm1top spin for 4 minutes and that 1 processor is being fully utilized. It is not an environment issue as I actually did the test while I was on the web server.

So, you are logging in as Admin and no delay. They long in as regular user, same view, and there is a significant delay. It has to be security related. Take off all cell security and see if you get the same result.

[jstrygner]

This test user has the same credentials as the user who is experiencing these issues.

I understand by this you mean both users are assigned to exactly the same groups. Weird...

I know tm1top function column is not the best to figure out what is being done on the server, but while waiting for those 4 minutes is there a specific function (and which one) that lasts or it changes all the time and is hard to "catch"?

Also... is there a chance the TM1User function is used in rules of this or any other cubes on which this cube calculations depend on?

[mattgoff]

Has anybody experience performance issues that seems to be related to specific user. I have a user you is experiencing massive performance issues. I created a test user group that has the same security rights as this user and I do not experience even a fraction of the performance issues this person is experiencing. There is cell security associated with this application, but I would think that if this issue was system wide everyone would be seeing performance issues.

You say "web server" later in the thread. How is the user accessing TM1: via the Excel add-in or TM1 web? How is the user opening the cube view: a saved view or a customized one? If this is the "Default" view, are you sure the user has not saved his/her own Default view (which will supersede the global Default view)?

Two tests to isolate:

1. On production (mentioned since you said "test server" elsewhere in the thread), create another user and assign that user to the same security groups as the affected user. Open the affected view.
2. Have the user log into TM1 with his/her credentials but on another client machine owned by a user who does not have this issue (or, ideally, the system you used to test the above).

Matt

[cdhodge2002]

I wanted to add to this.

1. I have logged on as a user with the same security as the user in question, no issues, I hijacked the users credentials and log in as them and I get the issue.
2. People are logging in through TM1 Contributor into a cube view
3. We are using cell security, however I turned off that security and the situation did not go away.

Could individual performance be hampered if they have a large amount of uncommitted changes or if they are using a sandbox?

[mattgoff]

1. I have logged on as a user with the same security as the user in question, no issues, I hijacked the users credentials and log in as them and I get the issue.

You're leaving out some important details. Is the following correct? If you, on your machine (or any machine other that the affected user's), log in under a different user account which is a member of the same security groups as the affected user, you experience no slowness? And if, again on your machine, you log into the user's account with their credentials, you do experience slowness?

3. We are using cell security, however I turned off that security and the situation did not go away.

How did you turn it off? Did you literally delete the }CellSecurity cube and restart the server?

Could individual performance be hampered if they have a large amount of uncommitted changes or if they are using a sandbox?

Those are all stored locally. So if you were doing the test on your own machine and not the user's it should not affect your results. If you were on the user's machine, it could affect the results as the client has to do local processing on the data to merge committed and noncommitted data before it's presented.

Matt

[whitej_d]

Could individual performance be hampered if they have a large amount of uncommitted changes or if they are using a sandbox?

Those are all stored locally. So if you were doing the test on your own machine and not the user's it should not affect your results. If you were on the user's machine, it could affect the results as the client has to do local processing on the data to merge committed and noncommitted data before it's presented.

I don't think this is strictly true. Uncommitted sandbox changes are stored in .cub_delta files on the server, not the local user machine. Hence a sandbox is retained on all clients and machines after logging off. Sounds to me like the sandbox is the likely cause. Originally a sandbox did not store it's own calculation cache and was therefore slower on recalcs. In 9.5.2 I believe a sandbox retains it's own calculation cache, but I believe it can only be stored within the limits of of the MaximumUserSandboxSize parameter set in TM1s.cfg. by default on a 64 bit machine this is 500 meg, less on 32 bit. Try increasing this parameter within the limits of your server, otherwise try committing the sandbox and seeing if it helps.

Also worth considering that Contributor impliments it's own security layer, and copies users in and out of the groups it creates as they take ownership or submit a node. Could be worth looking into that side it if it's user related.

[mattgoff]

Could individual performance be hampered if they have a large amount of uncommitted changes or if they are using a sandbox?

Those are all stored locally. So if you were doing the test on your own machine and not the user's it should not affect your results. If you were on the user's machine, it could affect the results as the client has to do local processing on the data to merge committed and noncommitted data before it's presented.

I don't think this is strictly true. Uncommitted sandbox changes are stored in .cub_delta files on the server, not the local user machine. Hence a sandbox is retained on all clients and machines after logging off.

Fixed/clarified attribution-- it was me who made the incorrect statement. These files are indeed on the server, so it's unlikely that my original test of one machine vs. another would be indicative in this case.

Sounds to me like the sandbox is the likely cause. Originally a sandbox did not store it's own calculation cache and was therefore slower on recalcs. In 9.5.2 I believe a sandbox retains it's own calculation cache, but I believe it can only be stored within the limits of of the MaximumUserSandboxSize parameter set in TM1s.cfg. by default on a 64 bit machine this is 500 meg, less on 32 bit. Try increasing this parameter within the limits of your server, otherwise try committing the sandbox and seeing if it helps.

Definitely seems suspicious since it appears to be the only distinctive difference. Could a simpler test be just to de-select the sandbox and see if there's a slowdown when viewing base data?

Matt