TM1 Forum

In practical (rather than theoretical) terms can anyone offer any advice based on experience as to the number of users we should expect to be able to have on a TM1 server before we start to hit performance issues caused by the number of users per se (rather than data volumes)? Thanks in advance for any suggestions.

More than with palo

John - it totally depends firstly on the application and design and what the users are doing, and then secondly on the hardware. I don't see how an answer to this question is possible without you providing more information.

Hello,

I agree. In working at different places, I have seen a huge dichotomy in this area. I can't say for sure, but I think that Hardware and rules dictate the overall user experience and scalability.

Thank you,
Steve

It also depends on the number threads your CPU's have. I know this is outside of model build but there you are. You might also want to look at the software version. Later versions liek 9.5.2 have improved locking models.

It also depends on the number threads your CPU's have. I know this is outside of model build but there you are. You might also want to look at the software version. Later versions liek 9.5.2 have improved locking models.

I know that you can set the threading to be multiple threads but only of you don't have conditional feeders. Does this change for the 9.5.2 version?

You might want to turn on cube dependency logging (if it's available in your version). We have had issues with Cube Dependency locks.

ellissj3 wrote:I know that you can set the threading to be multiple threads but only of you don't have conditional feeders.

That's only for server startup. I'm sure the OP is talking about the user experience AFTER the system is available. As previously mentioned, the number of users that can effectively function on one TM1 server is dependent on 1) how many cores the machine has and 2) how complicated AND large the models are. For an average system, assuming you have adequate RAM to hold everything, you can expect about 50 users on a quad-core machine. When I say 50 users I mean casual to moderate users. If they are super-users, running large views and/or active form reports, then that number is going to trend down and you'll bog down after about 15 or 20. It's really hard to pin down which is why TM1 is so hard to EFFECTIVELY develop in. It is more art than a science when it comes to performance tuning.

Tomok,

I appreciate your clarity, thank you!

Thanks for the feedback so far guys. I do realise (having been working with TM1 for 15 years) that it was a piece of string question but I wnted to leave it as an open question to see what the response was.

I am quite surprised that a client is having issues with just over 10 users with a model that is complex but not crazily complicated. I know that the old Applix documentation used to state that you needed a another server after about 100 users but we are so far short of that that I wanted to get some real world feedback.

Most of my clients have a relatively low number of users (<20) but one has about 70 working on a similar model with a couple fewer dimensions and the issues they face and have addressed are more data volume than user related.

At the moment my client faces having to divide the model into 10 to get past this issue so this is more than a theoretical problem!

So any feedback on how many users people allow before having to set up another server to accommodate them? (I realise , as I said that this CAN depend on model complexity and volume, but it is a pretty fundamental question given the way the product is priced and sold.)

The official IBM answer is 100 users for a quad core machine but I have found that to be a little unrealistic unless those are all READ users pulling minimal reports and views. If you have performance issues then IBM will recommend you get rid of all your rules and do things with TI processes, in effect turning your system into Essbase. That's just a cop out. Don't put the feature's in if you don't expect people to fully utilize them. The same thing with MDX subsets. Why have them if the answer is always not to use them. The bottom line is performance tuning is just a lot of trial and error. You find out what the users require, as far as response times, etc., and you fiddle with the rules and TI balance until you get it right. First step, IMO, is always to beef up the hardware so you know there is nothing left you can do there.

John Hobson wrote:I am quite surprised that a client is having issues with just over 10 users with a model that is complex but not crazily complicated. I know that the old Applix documentation used to state that you needed a another server after about 100 users but we are so far short of that that I wanted to get some real world feedback.

Most of my clients have a relatively low number of users (<20) but one has about 70 working on a similar model with a couple fewer dimensions and the issues they face and have addressed are more data volume than user related.

At the moment my client faces having to divide the model into 10 to get past this issue so this is more than a theoretical problem!

Sounds like a rule/feeders problem to me. What does tm1top show? Are people stuck in "waiting" or is TM1 actively working on everyone and that's just slow? Is this a read-only (mainly) or heavy writing model? Before doing anything architecturally, I'd try it on 9.5.2 and see if the new locking features help at all. You may need to enable some of it in the cfg, still getting up to speed on it myself.

We have some issues before forecast is due, mainly writers locking the P&L cube and/or waiting for a long readers to complete. I want to get onto 9.5.2 ASAP but haven't had the chance to fully shake it out on dev yet. I guess that's the problem with being 1/2 IT and 1/2 Finance.... (or is that 3/4 and 3/4?).

Matt

John Hobson wrote:I do realise (having been working with TM1 for 15 years) that it was a piece of string question but I wnted to leave it as an open question to see what the response was.

Thanks for that John. Next you'll be starting up old chestnuts like day light saving and time dimensions....

Next you'll be starting up old chestnuts like day light saving and time dimensions.

Well I can't whinge about undo spread anymore Jimbo (apart from the fact that it makes the system fall over at this client every time they try it

So let me ask this a different way - how many of you have planning (as opposed to read only) apps that have more than about 20 users and no problems with crashing and response times?

John Hobson wrote:

Next you'll be starting up old chestnuts like day light saving and time dimensions.

Well I can't whinge about undo spread anymore Jimbo (apart from the fact that it makes the system fall over at this client every time they try it

So let me ask this a different way - how many of you have planning (as opposed to read only) apps that have more than about 20 users and no problems with crashing and response times?

{Raises hand} At the height of budget we often have between 20 and 40 users on concurrently, all read-write. Part of the application is calculation intensive but the current server handles it pretty well. However I doubt that there are more than 10 writing to those cubes at any one time; most will be read-writing to the PNL cube which has no rules in it at all, or the stats cube which has a few rules but nothing too onerous.

Have had some problems with users using old and badly designed reports, but judicious use of Stargate views and the View() function helped with that; in one case reducing calc time from 12 minutes to 15 seconds.

And for the record I was less fussed about DST now that I have an API app to bump my chores... until I found out that the GUI in 9.0 has a glitch which mis-calculates the local time by an hour when you're off DST (cheezes, if they can't even calculate time correctly...) meaning that I have to extend the API app to handle all chore display/scheduling. Not that that's necessarily a bad thing in the long run. All I need now is the time to do it.

Alan Kirk wrote:until I found out that the GUI in 9.0 has a glitch which mis-calculates the local time by an hour when you're off DST

Can you elaborate on this a little?

blackhawk wrote:

Alan Kirk wrote:until I found out that the GUI in 9.0 has a glitch which mis-calculates the local time by an hour when you're off DST

Can you elaborate on this a little?

Actually as I was typing the reply I just thought what it might be; it could be something that I've encountered before.

Since we left DST, whenever I entered 09:30 (say) as the start time the giant brain algorithm would convert that to UTC and somehow come up with a time that was actually 08:30 local. I'd have to set it to 10:30 to have it calculate the UTC equivalent of 09:30.

However I think it may have something to do with the start date of the chore as well which, as I've found previously, needs to be in the same DST season as you're currently on to avoid scheduling issues. (That is, if you're in summer and on DST, the start date also has to be in summer. If you're in winter and off DST, the start date also has to be in winter.) I'll have to double check that when I get back to work.

Of course none of this would be an issue had we been left with local time scheduling of chores which Applix arrogantly and obstinately took from us in the move from version 7 to 8 and which Iboglix still refuses to acknowledge as a problem.

I find this very interesting actually and your analysis seems to make sense. Seems like an easy fix for IBM to do, but I guess they feel it is not causing any revenue loss so it receives less attention.

I am going to keep an eye on this for our customers systems. Thanks for the insight.

John Hobson wrote:

Next you'll be starting up old chestnuts like day light saving and time dimensions.

Well I can't whinge about undo spread anymore Jimbo (apart from the fact that it makes the system fall over at this client every time they try it

So let me ask this a different way - how many of you have planning (as opposed to read only) apps that have more than about 20 users and no problems with crashing and response times?

Hi John,

I have a client that just started the budget for next year. There is 60 named users that have write acess, and I just looked at the numbers online now, and it counts 38. I have not seen any performance problems. We use a combination of the Contributor interface and the TM1 Web. (Powerusers use TM1 web views)

On the same server we have 20-30 read user also active

I thing the question You rais it of value to all, mainly because of the priceing of TM1, and theby what we sould advice oure customers to do.

Normaly I only see performance problems when the TM1 model becomes to complex or the "Skipcheck/Feeders" is not implemented.

Thanks for the feedack all

Interestingly my model works just fine at one very major client without skipcheck and feeders - it's a dense planning model and so most cells viewed have values or are consolidated from cells that have values. The trade-off of having to write, test and manage feeders wasn't really justified. (I have tested the model with and without feeders and they really don't make a signficant difference in the majority of views that would be used.)

John Hobson wrote:Thanks for the feedack all

Interestingly my model works just fine at one very major client without skipcheck and feeders - it's a dense planning model and so most cells viewed have values or are consolidated from cells that have values. The trade-off of having to write, test and manage feeders wasn't really justified. (I have tested the model with and without feeders and they really don't make a signficant difference in the majority of views that would be used.)

Was there any memory impact either way??

In a highly dense cube you are better off leaving out the SKIPCHECK statement. This way you don't have to worry about missing a feeder and no memory will be consumed by feeders. Granted a feeder only takes a single bit of RAM but it can add up. It's rather easy to test. Fire up your server with SKIPCHECK and FEEDERS and record the initial RAM usage. Then take those same statements out, start up again, and record initial RAM usage. There will be a difference. How much depends on the size of the cube and how many cells had to be fed.