Hi
I am testing this with CX 10.2
Can anyone pls confirm that MTQ should work with BI workspace advanced? If any experience, I would be happy to hear about
We have 4 cores, MTQ =2, and when running a long BI query, the CPU usage is constantly at 25% only, instead of 50%. We use DQM.
Thanks
Matyas
MTQ and Cognos BI 10.2
-
- MVP
- Posts: 1831
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: MTQ and Cognos BI 10.2
As far as TM1 is concerned a cube query from BI should be no different to you querying via a cube viewer in perspectives etc.
Have you used the ops console to monitor the query?
Have you used the ops console to monitor the query?
Declan Rodger
-
- Community Contributor
- Posts: 341
- Joined: Wed Nov 03, 2010 9:16 pm
- OLAP Product: tm1
- Version: 10 2 2 - 2.0.5
- Excel Version: From 2007 to 2013
- Location: Earth
Re: MTQ and Cognos BI 10.2
yes, I would also expect it
No, I monitored from task manager
No, I monitored from task manager
-
- Community Contributor
- Posts: 341
- Joined: Wed Nov 03, 2010 9:16 pm
- OLAP Product: tm1
- Version: 10 2 2 - 2.0.5
- Excel Version: From 2007 to 2013
- Location: Earth
Re: MTQ and Cognos BI 10.2
Just an update after I monitored this in Architect:
it seems that BI and Architect works the same way, so this is as expected. In the first part of the query, it uses all available cores, and in the second part it uses a single core only; at the moment I cannot decide what exactly the "first part" consists of and what the "second part" consists of. It seemed in Cube Viewer that as long as the server was "calculating", it utilized multiple cores while during "rendering" it used a single core (also as expected); when I have put thousands of lines into the cube viewer to the rows, the "second part" could take more time than thee "first part". So at the moment I think this is why MTQ does not always result in linear speed increase together with the increase of the nr of cores.
Anyway, it would be good to hear other experiences as well
it seems that BI and Architect works the same way, so this is as expected. In the first part of the query, it uses all available cores, and in the second part it uses a single core only; at the moment I cannot decide what exactly the "first part" consists of and what the "second part" consists of. It seemed in Cube Viewer that as long as the server was "calculating", it utilized multiple cores while during "rendering" it used a single core (also as expected); when I have put thousands of lines into the cube viewer to the rows, the "second part" could take more time than thee "first part". So at the moment I think this is why MTQ does not always result in linear speed increase together with the increase of the nr of cores.
Anyway, it would be good to hear other experiences as well
-
- MVP
- Posts: 1831
- Joined: Mon Dec 05, 2011 11:51 am
- OLAP Product: Cognos TM1
- Version: PA2.0 and most of the old ones
- Excel Version: All of em
- Location: Manchester, United Kingdom
- Contact:
Re: MTQ and Cognos BI 10.2
MTQ will NEVER result in a linear increase in query time due to the very fact you have mentioned of the actual "rendering" of the view only being executed in 1 core, in addition to this the initial request and decision by TM1 on how to slice the query into different work streams for each core can also only be executed in 1 core; so although these 2 parts of the process may only take a negligible time to execute (quite often milliseconds) it still happens meaning that it is impossible to see a linear return based on your number of cores available.
You will also find that cubes with rules will possibly cause an impact also due to the fact that the different work streams can't interact with each other; for example:
If you have your MTQ=2 and you query a 2 cell view. Cell A and Cell B.
Cell A is rule derived.
Cell B is rules derived (Cell A * Cell Z)
Query is split across 2 cores, 1 calculates Cell A and 1 calculates Cell B. Cell A is calculated in both work streams since the stream trying to find the value of Cell B also needs to know what the value of Cell A is... but it can't find out from the other stream which has also calculated Cell A.
That being said MTQ is extremely beneficial, your setup with 4 cores and MTQ=2 will notice a small improvement but I would say in the modern day that for TM1 I would want more cores than that, even before MTQ it was advisable to have a good handful of cores on any model with significant concurrency so that you could get the most benefit out of PI.
You will also find that cubes with rules will possibly cause an impact also due to the fact that the different work streams can't interact with each other; for example:
If you have your MTQ=2 and you query a 2 cell view. Cell A and Cell B.
Cell A is rule derived.
Cell B is rules derived (Cell A * Cell Z)
Query is split across 2 cores, 1 calculates Cell A and 1 calculates Cell B. Cell A is calculated in both work streams since the stream trying to find the value of Cell B also needs to know what the value of Cell A is... but it can't find out from the other stream which has also calculated Cell A.
That being said MTQ is extremely beneficial, your setup with 4 cores and MTQ=2 will notice a small improvement but I would say in the modern day that for TM1 I would want more cores than that, even before MTQ it was advisable to have a good handful of cores on any model with significant concurrency so that you could get the most benefit out of PI.
Declan Rodger
-
- Community Contributor
- Posts: 341
- Joined: Wed Nov 03, 2010 9:16 pm
- OLAP Product: tm1
- Version: 10 2 2 - 2.0.5
- Excel Version: From 2007 to 2013
- Location: Earth
Re: MTQ and Cognos BI 10.2
Hi
Thanks for this, I agree with you. MTQ = 2 was just a test, we may increase it later.
"I would say in the modern day that for TM1 I would want more cores than that, even before MTQ it was advisable to have a good handful of cores"
Well, keeping the nice pricing model of enterprise TM1 in mind whereas they charge for both users and CPUs this is not so easy; however, it is fine in a CX environment, especially if BI is also enabled.
Thanks for this, I agree with you. MTQ = 2 was just a test, we may increase it later.
"I would say in the modern day that for TM1 I would want more cores than that, even before MTQ it was advisable to have a good handful of cores"
Well, keeping the nice pricing model of enterprise TM1 in mind whereas they charge for both users and CPUs this is not so easy; however, it is fine in a CX environment, especially if BI is also enabled.