TM1 Forum

Hello everybody,

We're currently running a system with Windows Server 2003 and TM1 9.0 SP3.
I'm not sure about the number of CPUs on the server because I'm not on the technical side of the project, but I'm pretty sure we have at least 2 CPUs.

My question is, I heard that 9.4 is able to use different CPUs to avoid server locking during for example TI processes : is that true?

In fact, we have several performance issues with our current situation : apart from the fact that TI processes block everybody when they run, we also have users that block everybody else when then refresh huge views / Excel reports linked to TM1.
Furthermore, we also have an issue that we never managed to analyze correctly : some queries from users never seem to reach the server. I think it is more a network problem, but the thing is that they lock everybody else until we "terminate" them using TM1 Top.

Do you think 9.4 could help resolve or reduce these kinds of problems?
From your past experience, and I know that lots of old timers in this forum have installed and tested many TM1 versions, would you say that 9.4 is more stable than 9.0?

Thanks in advance for your feedback.

Regards,

Greg

I'll add more to this tomorrow, but the short answer is "maybe." 9.0 was multi-threaded, but the locking scheme meant that any write had to lock the entire model. 9.1 introduced more granular cube locking, so in theory only the cube being written (and cubes linked via rules) is locked during writes, including TI load processes. At daemon launch time, loading and rule calc is multi-threaded, but any rule re-save while a server is up is single threaded. Any user processing on any model (including 9.4 AFAIK) is single-threaded.

Matt

DevGreg wrote:... would you say that 9.4 is more stable than 9.0?

Tricky question, what do you mean by "more stable"? From a pure server perspective, period of uptime between restarts, application does not crash, etc. I would have to say that 9.0 is still the more stable version. However, from the point of view of the end user in a multi-user environment the relative uptime and responsiveness of 9.4 is likely to be much better than 9.0. This is because most (not all just yet) of the "application hangs" traditionally experienced by users due to the old server locking model have now been eliminated. There are concurrent write locks but they are at cube level, there are no concurrent read locks. The same goes for TI processes, they should only lock the cubes been written to, not the whole server.

So I think that a general response to your question would be that 9.4 should reduce the issues you are describing and lead to general better per user performance due to less server locking.

But there are caveats:
- to take advantage of cube level locking you might need to eliminate some inter-cube rules (otherwise the write lock spreads to other cubes). You might also need to look at splitting up data entry over multiple cubes if you have lots of users writing back (very "non TM1" thing to do but have to move with the times)
- view processes can impose a server wide lock. Although it adds more steps and moving parts you can often get better performance from exporting a view to a flat file and then using the text file as a data source in a subsequent process

These things might change as the locking gets more refined, we will have to wait and see!

Thank you for your answers guys.

I'll submit the idea of export to a flat file then load it for TI processes, but I think that even then, the whole server is locked.

By the way, I know there are TI functions called "LockOn" and "LockOff" but it seems there are not compatible with lots of other simple functions like "CellPutN" so it's hard to use them in any operational process. Anyone got experience on this?

I think another reason why we didn't migrate to 9.4 is because all our clients have Windows 2000 workstations, and I think 9.4 doesn't support officially this OS anymore.

Anyway, if we decide to take the step, I'll keep you posted about the possible improvements we encounter.

Regards,

Greg