Speed issues... strange, stranger and strangest

[glaurens]

Hi all,

We are running processes on a 913 (Update 2, I think) server on Windows 2003 x64 (64 GB) in our QA environment that basically populates assumptions, do calculations, populate results in a different cube and repeast the same steps 4 times. This whole process is repeated 5 times, and takes about 10-12 minutes to complete. The cube in which the results are populated has 6 dimensions with 2 rules without skipcheck.

When I run the same process on my laptop XP x86 (2GB) (subset of server) using 913 U2 it takes about 32 minutes to complete. What I found strange is that it takes approximately 12 minutes just to clear the target cube initially, adding skipcheck obviously changes this and then it takes about 20 minutes for the whole process.

What I found the strangest though, is the fact that when I run the process on my desktop (913) it completes in 2 and a half minutes. My desktop is running Vista Ultimate x64 (8GB) and I'm using the whole server. I also only ran the clearing to see how it behaves, and it was immediate as one would expect without having to add skipcheck to the target cube.

Does anybody know why this is happening since this is extremely weird to me.

Thanks

G

[glaurens]

OK, it is official 913 Update 2 hotfix 2 is slow. The process just ran for longer than 15 minutes on my desktop and the clear only has been running for longer than 6 minutes now.

Case closed.

[ScottW]

Processing cube views in 913 and 914 is extremely sensitive to cube optimisation (dimension ordering), much more so than 912 or 90x. The processing time can probably be improved greatly by optimising the dimension order (but still won't be as fast as 9.0)

[John Hobson]

Processing cube views in 913 and 914 is extremely sensitive to cube optimisation (dimension ordering), much more so than 912 or 90x. The processing time can probably be improved greatly by optimising the dimension order (but still won't be as fast as 9.0)

I'm glad we're so obviously making progress then.

[ScottW]

I'm glad we're so obviously making progress then.

En contraire Monsieur Obson, ... admittedly the backend engine may have lost some pure raw speed (in a single user environment) but what of the gains in multi-user performance, x64, granular object locks, user interface (action buttons, active forms) ...

TM1 is now more scalable, accessible and user friendly than previously. Cognos's development priorities may not be perfect from everyone's perspective but on the whole I think good "progress" is being made.

[glaurens]

Processing cube views in 913 and 914 is extremely sensitive to cube optimisation (dimension ordering), much more so than 912 or 90x. The processing time can probably be improved greatly by optimising the dimension order (but still won't be as fast as 9.0)

This could be true, but what is really strange, is that on 913 it runs 2.5 minutes but on 913 Update 2 Hotfix 2 it runs for more than 15 minutes. So there was actually no testing on 9.0?

G

[John Hobson]

Yeah well I was being flippant (What ME?)

granular object locks

I think that's "object level locks" isn't it - I wouldn't really call locking a whole cube "granular", unless you mean granular like a sugar lump is granular - although I grant you that it's a shed load better than the old server lock.

user interface (action buttons, active forms)

Rofl!

I suppose action buttons now work something like they need to, but it's a sad reflection on IBCoglix's approach and attention to UI design that you have to hold up a feature that is incapable of delivering a meaningful error message as a shining example of the best they can do.

The burning question there is why it took them over 5 years to deliver a viable means of kicking off a TI from Excel (and then evidently couldn't be bothered to do it properly). I am not just having a go for the sake of it here BTW - As a developer I have to site create systems that people can actually use n real life and I have been very frustrated by Applix and now Cognos's apparent inability to understand some very basic UI issues.

I'd lose a lot of their much vaunted "improvements" just to be able to resize a column width in server explorer, or not to see that b**** regression bug again (yes its back in 9.1.3) where the row headers don't move when you use a wheel mouse to scroll down the page.

[jim wood]

Has anybody considered the fact the laptop has less memory and therefore has to cache to hard drive more, hence slowing things down?

[glaurens]

I understand completely why my laptop would be slower than the server and my laptop, but running the process on the same machine (8GB) using 913 takes 2.5 minutes while if I use 913 Update 2 HF 2, takes 15.25 minutes.

That is where something seems a bit off...

[glaurens]

When running the process only once (instead of 5 times), it takes 2:34 on my laptop. After optimising all the cubes that are being used, I've only managed to bring it down to 2:18.

Does anybody else have other suggestions?

Tx

George

[Steve Vincent]

are there issues in 913 solved in the update that would stop you from using 913? It seems its an internal issue so there won't be much an end user could do to improve it.

[glaurens]

I'll have to find out whether there are any specific requirements for Update 2 since it is part of a bigger project which I am not involved in.

Tx

G

[David Usherwood]

I'm glad we're so obviously making progress then.

En contraire Monsieur Obson, ... admittedly the backend engine may have lost some pure raw speed (in a single user environment) but what of the gains in multi-user performance, x64, granular object locks, user interface (action buttons, active forms) ...

TM1 is now more scalable, accessible and user friendly than previously. Cognos's development priorities may not be perfect from everyone's perspective but on the whole I think good "progress" is being made.

Scott....
I know you and Cubewise are fans of 9.1+, partly because we share a client . You quote as improvements:
a multi-user performance,
b x64,
c granular object locks,
d user interface (action buttons, active forms) ...

d I will accept. b - well 9.0x64 is fine. a and c are probably related.
But I would like to ask - what tests have you done to confirm that multi user performance is better in 9.1+? And what kind of multi user activity is better? We built a testbed which we sent to Dave Corbett which seemed to show pretty conclusively that 9.1 was _much_ slower than 9.0 on multiple writers. 9.4 pulled back quite a bit, but not back to 9.0. I will admit we tested only 4 users, but we _did_ simulate the microcube architecture which 9.1+ is meant to work well with.

We have a multi read testbed (using around 250k of DBRWs) which I need to get ready for peer review/sending to Iboglix. Currently this shows a shallow decline over versions ie the newer versions are somewhat (not much) slower than older versions.

So I'm not currently convinced that 9.1+ is actually better. I will admit I am looking at the other enhancements in 9.1 onwards and feeling that we are missing out - but on the other hand, we get the stability of 9.0SP3U9. Think our clients place more weight on this than the whizzy bits.

If you have a testbed, it would be good to peer review it. What do you think?
(Runs back to the bunker and waits for the artillery barrage...)

[ScottW]

If there's to be any artillery barrage it will be offline. We have done large scale stress testing (200 - 300 concurrent write users) with load scripts. It's not in the public domain as it has been done with client data as part of projects. No argument that 9.1 loses out in raw speed compared with 9.0. Where it starts to come out ahead (and this is 9.1.3+ as the object locking model was not in place in earlier versions) is for true high concurrency (>100 simultaneous users), especially if there is "complex" or "heavy" data input, for example spreading. However to take advantage of this changes do need to be made to historical TM1 design principles - mainly separation of data cubes. TM1 is now a viable solution for large scale corporate budgeting applications with 1000s of users and 100s of concurrent logins, which wasn't the case in the past.

Also by "multi-user performance" I wasn't necessarily just referring to data entry speed in a multi-user environment. The fact that users no longer have to queue because someone else is writing back to an unrelated cube, or even that a process can run without locking the whole server, also leads to an improved user experience. We have to remember that the vast majority of users aren't as hung up on processing speed as we are, all they see is the "hang" when they want to run their report at the same time as everyone else.

[David Usherwood]

Scott, that's a very useful, considered response. I will admit hardly any of our clients use spreading so data input is quite granular, and we do encourage them to manage input via macros etc, or even macro generated flat files which are read in via TI. When I have time I will return to this area for further investigation.
It would be worth pulling in views from other forum participants on this area to fill out the overall assessment.

[bearlmax]

Hi Scott,

Which performance testing tool did you use to execute the performance tests you mention? Later this fall I will be responsible for performance testing a TM1 instance. I am curious which testing tool was able to integrate with TM1.

Thanks,
-Chris