TM1 Forum

All,
I'm curious about how many simultaneous users are able to work off a read only cube without a drop off in performance?
I appreciate this is a how long is a piece of string type question….
A hypothetical example then.

Say the cube concerned is 8GB (in RAM) of raw data with some currency calcs and few other bits and pieces nothing massively draining.
At any given moment we expect 500 users to be querying the data at the same time.
The box has 12 cores.

In older versions of TM1 you would design your system so that your data was in multiple cubes or instances so that the load of the users and data were split up to allow cores and threads to be utilised efficiently.

In the current versions of TM1 9.5.2 + it seems that the argument for segmenting the data in this way is much weaker.

Anyone have a view on the number of simultaneous users a single cube can support before performance degrades?
What is the correct remedy to this? Cut the data into multiple cubes or separate instances on the same box or separate instances on a different box.
Is the TM1 architecture irrelevant and the real limit the hardware?

Cheers
(EDIT : Correct the bit about a different box which previously said the same box)

This isn't based on any hard data (in other words it's just my opinion) but I would not split into separate cubes OR separate instances unless those instances were to run on different hardware. You shouldn't be getting any locks with READ only so I don't see what is to be gained from splitting on the same service or instance on the same box. Instead, I would experiment with the VMM and VMT settings to find the best ones for the cube in question. I know it will be difficult to simulate 500 users at a time. Do you have access to LoadRunner or some other type of testing tool? Maybe you could write some sort of VBA-run app that could simulate a bunch of users. Good luck.

In testing our 9.5.2 FP1 model we were able to 375 users hitting the box fairly hard and saw very little in the way of slowdown and this was in a read write model. Partitioning does not have the benefits it used to. We actually just collapsed our model from a partitioned one and have seen better performance.

As long as you have your model set up so that there is no locking on the cube, if it is READ then you should only have to worry about some attribute or system cube based locking I dont see where 500 would not be a reasonable number. The newer version handle concurrency well and as long as you are vigilant about tracking down and eliminating locks you should should only have to worry about the hardware being the bottle neck.

I agree with the others in that there's no point splitting the cube. Splitting the cube would only make sense for performance optimization reasons due to really massive dimension or cube size or both where this affected speed of reporting due to volume of calculations to report at consolidated level - but that is a single user issue and separate from multi-user performance.

The number of concurrent users vs. the number of cores needed depends on how "heavy" the usage is which is a factor of what the users are doing and the complexity of calculations in the cube. It is a real how long is a piece of string question that can only be answered by first establishing a performance baseline then doing some load stress testing.

One thing I would recommend is that if the cube is truly read only then eliminate rules wherever possible (e.g. all N rules) and precalculate with TI and make the cube data entry only as this is the best thing you can do improve performance, both for single user and multi user in a read only scenario.