TM1web data writeback is slow!

[Niko]

I don't know why after input data in the view's cell and click refresh on the tm1web toolbar, i should wait for about 10 minutes, and th result is that some of the cells data input faild , it's very strange.
Because the number of cells is about 8000 , it supposed to be very quickly to write to tm1 db.
I don't know if there is any parameters configation to speed up ,
any advice will be appreciated.

[Elessar]

Hi,

There can be 2 reasons of slow data entry:

1. Somebody locked something, and you are in queue
2. The cell you are writing data in overfeeds something (most probably, a large consolidation)

Use tm1top (or PAW administration) to determine this.

But, is it really data entry? You say that you wait 10 minutes after clicking a Refresh button, so the data entry can be quick, but the calculation is slow. Anyway, tm1top is to be used here also.

[Niko]

Hi,

There can be 2 reasons of slow data entry:

1. Somebody locked something, and you are in queue
2. The cell you are writing data in overfeeds something (most probably, a large consolidation)

Use tm1top (or PAW administration) to determine this.

But, is it really data entry? You say that you wait 10 minutes after clicking a Refresh button, so the data entry can be quick, but the calculation is slow. Anyway, tm1top is to be used here also.

thx for your reply , the cube has no any rule scripts and alse has no other users login in the server.
so it's strange, i don't know if the cells are too much( about 3140 cells will be commited after i click refresh).
How i can konw the details about using "tm1top " to debug the issue?

[Elessar]

These are basic things, and BIM documentation and Google will help you more at this stage than tm1forum
https://www.ibm.com/docs/en/planning-an ... d-activity

[declanr]

Hi,

As Elessar has pointed out it could be locking that causes this, but I assume this wait happens every time? If so it is unlikely that you are in a wait state every time... unless it's a high user concurrency system and/or there are TIs scheduled to constantly run against the view in question.

the cube has no any rule script

Do you mean there is no rule file at all? Or that there are no rules on those cells? It would still be possible that those cells trigger a lot of feeders to other calculations.
One of the first things to check is that making the same sort of changes directly in a cube view in architect on the server causes a delay or not.
> If it causes a delay there, then it would point to a problem with either being put in a wait state (which Elessar highlighted the tools to check for) OR poorly performing feeders/overfeeding.

Is this occurring on a websheet that you have built via excel or in a TM1Web cubeview?
> I ask this as it is very possible to create a websheet that is slow (10 minutes is extreme but not impossible)
> If it is a websheet, I would check an equivalent (as much as possible) cube view and if its much quicker then it points towards rebuilding the websheet.

If it's a TM1 Web cubeview, does this occur only for that one cube or other cubes also?
> Its unlikely - but if this happens for everything - then it is possible that either the TM1 Web server has been positioned with a poor network connection to the TM1 Server itself... or potentially the TM1 Web server has been extremely under specced - I've not seen problems this extreme before and expect that TM1 Web would be slow even navigating rather than just on data entry.

Since you have only mentioned a problem with data entry - I am assuming that when initially opening the view it is quick?

And to your original question there are not really any config options for TM1 Web that should cause significant enough changes in performance to fix a 10 minute delay.
It very much points towards a problem with either the cube design (excessive feeders), websheet design (there are a million things that can go wrong here), model design (e.g. a TI process running every 60 seconds with that cube view as a source - which takes 58 seconds to complete) or least likely but possible - an infrastructure problem (TM1Web server in New Zealand and TM1 Data Server in Portugal)

[Niko]

Hi,

As Elessar has pointed out it could be locking that causes this, but I assume this wait happens every time? If so it is unlikely that you are in a wait state every time... unless it's a high user concurrency system and/or there are TIs scheduled to constantly run against the view in question.

the cube has no any rule script

Do you mean there is no rule file at all? Or that there are no rules on those cells? It would still be possible that those cells trigger a lot of feeders to other calculations.
One of the first things to check is that making the same sort of changes directly in a cube view in architect on the server causes a delay or not.
> If it causes a delay there, then it would point to a problem with either being put in a wait state (which Elessar highlighted the tools to check for) OR poorly performing feeders/overfeeding.

Is this occurring on a websheet that you have built via excel or in a TM1Web cubeview?
> I ask this as it is very possible to create a websheet that is slow (10 minutes is extreme but not impossible)
> If it is a websheet, I would check an equivalent (as much as possible) cube view and if its much quicker then it points towards rebuilding the websheet.





If it's a TM1 Web cubeview, does this occur only for that one cube or other cubes also?
> Its unlikely - but if this happens for everything - then it is possible that either the TM1 Web server has been positioned with a poor network connection to the TM1 Server itself... or potentially the TM1 Web server has been extremely under specced - I've not seen problems this extreme before and expect that TM1 Web would be slow even navigating rather than just on data entry.

Since you have only mentioned a problem with data entry - I am assuming that when initially opening the view it is quick?

And to your original question there are not really any config options for TM1 Web that should cause significant enough changes in performance to fix a 10 minute delay.
It very much points towards a problem with either the cube design (excessive feeders), websheet design (there are a million things that can go wrong here), model design (e.g. a TI process running every 60 seconds with that cube view as a source - which takes 58 seconds to complete) or least likely but possible - an infrastructure problem (TM1Web server in New Zealand and TM1 Data Server in Portugal)

thank u first.
I input data in localhost, because this is my training server, the cube has rule before, but after I put my comment out the inside of the rule, data entry is still very slow, I tested the other cubes in my server, others is also same very slow, I don't know if it's a server level problem, I think maybe I can use TM1TOP to see what's going on.

[declanr]

If it’s just a small training server I would hazard a potential guess that the physical server it’s sat on doesn’t have much RAM - and if you hit that limit it will start paging to disk instead which could cause it to be very slow.
So to add to things to check - RDP to the physical server and check resource monitor for RAM utilisation.