Thread: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue
Open Java API for OLAP
Brought to you by:
jhyde,
lucboudreau
From: Alexander S. <asc...@pe...> - 2015-01-07 15:57:13
Attachments:
image001.png
|
Hello OLAP4j Team, I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app. BASIC INFO: Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. USE CASE: Send MDX queries and parse the result values. THE ISSUE: Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute. HOW TO REPRODUCE: Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is. THE CAUSE DETECTED: When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema: LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes()) Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it: Line 119: File: XmlaOlap4jCube.java // populate measures up front; a measure is needed in every query olap4jConnection.populateList( measures, context, XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES, new XmlaOlap4jConnection.MeasureHandler(), restrictions); for (XmlaOlap4jMeasure measure : measures) { measuresMap.put(measure.getUniqueName(), measure); } Which it is not deferred. I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.) POSSIBLE SOLUTIONS: I believe we have the following options: A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load B. We do not read ALL the cubes when we are doing an MDX to only 1 cube. C. Any other ideas are welcome Regards, alex Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748 Skype: aschurman |
From: Luc B. <luc...@gm...> - 2015-01-07 16:03:05
Attachments:
image001.png
|
I think the solution is a mix of A and B. A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes. B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions). On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <asc...@pe...> wrote: > Hello OLAP4j Team, > > > > I was on conversation with Luc Boudreau about a performance issue I was > getting for a large XMLA dependent app. > > > > *BASIC INFO:* > > Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) > > There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. > > > > *USE CASE:* > > Send MDX queries and parse the result values. > > > > *THE ISSUE:* > > Basically the Issue is that the FIRST MDX query is taking a long time > because it is LOADING all the Schema info for all the Cubes. The MDX query > it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” > takes like 1 minute. > > > > *HOW TO REPRODUCE:* > > Just take any SCHEMA use for testing on the SERVER side and copy one of > the CUBES many times just with different names. The more Cubes you add the > slower MDX 1 is. > > > > > > *THE CAUSE DETECTED:* > > When the *XmlaOlap4jCellSet* class is called to load the MDX data, it > calls a method called *lookupCube. *The issue is that this LOOKUPCUBE is > actually using internally a FOREACH cube in the Schema: > > LINE 576: *for (Cube cube : > databaseMetaData.olap4jConnection.getOlapSchema().getCubes())* > > > Reading a little more about what the *getCubes() * does I checked that > most of the Dimensions info is loaded with a deferred lazy method, which is > good, except Measures, with say in the code and I state it: > > Line 119: File: XmlaOlap4jCube.java > > * // populate measures up front; a measure is needed in every > query * > > * olap4jConnection.populateList(* > > * measures,* > > * context,* > > * XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES,* > > * new XmlaOlap4jConnection.MeasureHandler(),* > > * restrictions);* > > * for (XmlaOlap4jMeasure measure : measures) {* > > * measuresMap.put(measure.getUniqueName(), measure);* > > * }* > > > > Which it is not deferred. > > I Commented this PART to check if it had an impact on the RESULT time and > furthermore if the MDX result is affected by not having this info and the > First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all > the CUBES, but not loading the Metadata of the Measures that we are not > using or not requesting from the Metadata.) > > > > > > *POSSIBLE SOLUTIONS:* > > I believe we have the following options: > > A. We change the MEASURES to be also part of the Lazy loader like > other dimensions. But I do not know for what it is used the *measureMap* > loaded after load > > B. We do not read ALL the cubes when we are doing an MDX to only 1 > cube. > > C. Any other ideas are welcome > > > > > > Regards, alex > > > > > > > > > > Alexander Schurman > > Enterprise Architecture Team > > > > [image: cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] > > Direct: +34 627.294.748 > > Skype: aschurman > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > olap4j-devel mailing list > ola...@li... > https://lists.sourceforge.net/lists/listinfo/olap4j-devel > > |
From: Alexander S. <asc...@pe...> - 2015-01-07 16:45:16
Attachments:
image001.png
|
I agree with you that a combination is the best scenario. Just one additional comment Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue. Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748 Skype: aschurman From: Luc Boudreau [mailto:luc...@gm...] Sent: Wednesday, January 07, 2015 5:03 PM To: Alexander Schurman Cc: ola...@li... Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue I think the solution is a mix of A and B. A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes. B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions). On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <asc...@pe...<mailto:asc...@pe...>> wrote: Hello OLAP4j Team, I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app. BASIC INFO: Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. USE CASE: Send MDX queries and parse the result values. THE ISSUE: Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute. HOW TO REPRODUCE: Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is. THE CAUSE DETECTED: When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema: LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes()) Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it: Line 119: File: XmlaOlap4jCube.java // populate measures up front; a measure is needed in every query olap4jConnection.populateList( measures, context, XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES, new XmlaOlap4jConnection.MeasureHandler(), restrictions); for (XmlaOlap4jMeasure measure : measures) { measuresMap.put(measure.getUniqueName(), measure); } Which it is not deferred. I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.) POSSIBLE SOLUTIONS: I believe we have the following options: A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load B. We do not read ALL the cubes when we are doing an MDX to only 1 cube. C. Any other ideas are welcome Regards, alex Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748> Skype: aschurman ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ olap4j-devel mailing list ola...@li...<mailto:ola...@li...> https://lists.sourceforge.net/lists/listinfo/olap4j-devel |
From: Alexander S. <asc...@pe...> - 2015-01-15 16:19:39
Attachments:
olap4j.diff
image001.png
|
Hello Team, I did this code changes and looks like this solves the issue, please let me know if you like them Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748 Skype: aschurman From: Alexander Schurman [mailto:asc...@pe...] Sent: Wednesday, January 07, 2015 5:11 PM To: Luc Boudreau Cc: ola...@li... Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue I agree with you that a combination is the best scenario. Just one additional comment Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue. Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748 Skype: aschurman From: Luc Boudreau [mailto:luc...@gm...] Sent: Wednesday, January 07, 2015 5:03 PM To: Alexander Schurman Cc: ola...@li...<mailto:ola...@li...> Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue I think the solution is a mix of A and B. A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes. B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions). On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <asc...@pe...<mailto:asc...@pe...>> wrote: Hello OLAP4j Team, I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app. BASIC INFO: Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. USE CASE: Send MDX queries and parse the result values. THE ISSUE: Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute. HOW TO REPRODUCE: Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is. THE CAUSE DETECTED: When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema: LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes()) Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it: Line 119: File: XmlaOlap4jCube.java // populate measures up front; a measure is needed in every query olap4jConnection.populateList( measures, context, XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES, new XmlaOlap4jConnection.MeasureHandler(), restrictions); for (XmlaOlap4jMeasure measure : measures) { measuresMap.put(measure.getUniqueName(), measure); } Which it is not deferred. I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.) POSSIBLE SOLUTIONS: I believe we have the following options: A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load B. We do not read ALL the cubes when we are doing an MDX to only 1 cube. C. Any other ideas are welcome Regards, alex Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748> Skype: aschurman ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ olap4j-devel mailing list ola...@li...<mailto:ola...@li...> https://lists.sourceforge.net/lists/listinfo/olap4j-devel |
From: Paul S. <p.s...@gm...> - 2015-01-16 16:05:53
|
did you commit them or sent a pull request? > On 15.01.2015, at 17:19, Alexander Schurman <asc...@pe...> wrote: > > Hello Team, > > I did this code changes and looks like this solves the issue, please let me know if you like them > > > > Alexander Schurman > Enterprise Architecture Team > > <image001.png> > Direct: +34 627.294.748 > Skype: aschurman > > From: Alexander Schurman [mailto:asc...@pe...] > Sent: Wednesday, January 07, 2015 5:11 PM > To: Luc Boudreau > Cc: ola...@li... > Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue > > I agree with you that a combination is the best scenario. Just one additional comment > > Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue. > > Alexander Schurman > Enterprise Architecture Team > > <image001.png> > Direct: +34 627.294.748 > Skype: aschurman > > From: Luc Boudreau [mailto:luc...@gm...] > Sent: Wednesday, January 07, 2015 5:03 PM > To: Alexander Schurman > Cc: ola...@li... > Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue > > I think the solution is a mix of A and B. > > A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes. > > B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions). > > > > On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <asc...@pe...> wrote: > Hello OLAP4j Team, > > I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app. > > BASIC INFO: > Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) > There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. > > USE CASE: > Send MDX queries and parse the result values. > > THE ISSUE: > Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute. > > HOW TO REPRODUCE: > Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is. > > > THE CAUSE DETECTED: > When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema: > LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes()) > > Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it: > Line 119: File: XmlaOlap4jCube.java > // populate measures up front; a measure is needed in every query > olap4jConnection.populateList( > measures, > context, > XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES, > new XmlaOlap4jConnection.MeasureHandler(), > restrictions); > for (XmlaOlap4jMeasure measure : measures) { > measuresMap.put(measure.getUniqueName(), measure); > } > > Which it is not deferred. > I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.) > > > POSSIBLE SOLUTIONS: > I believe we have the following options: > A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load > > B. We do not read ALL the cubes when we are doing an MDX to only 1 cube. > > C. Any other ideas are welcome > > > > Regards, alex > > > > > Alexander Schurman > Enterprise Architecture Team > > <image001.png> > Direct: +34 627.294.748 > Skype: aschurman > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > olap4j-devel mailing list > ola...@li... > https://lists.sourceforge.net/lists/listinfo/olap4j-devel > > > <olap4j.diff> > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > olap4j-devel mailing list > ola...@li... > https://lists.sourceforge.net/lists/listinfo/olap4j-devel |
From: Alexander S. <asc...@pe...> - 2015-01-19 12:42:31
Attachments:
image001.png
|
I just now included a pull request When using XMLA, the Measures Metadata should be loaded in Deffered mode #33 Alexander Schurman Enterprise Architecture Team [cid:3bf163d0-be85-46b2-9b57-d4e3e33ad39f] Direct: +34 627.294.748 Skype: aschurman From: Paul Stoellberger [mailto:p.s...@gm...] Sent: Friday, January 16, 2015 4:38 PM To: Alexander Schurman Cc: ola...@li... Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue did you commit them or sent a pull request? On 15.01.2015, at 17:19, Alexander Schurman <asc...@pe...<mailto:asc...@pe...>> wrote: Hello Team, I did this code changes and looks like this solves the issue, please let me know if you like them Alexander Schurman Enterprise Architecture Team <image001.png> Direct: +34 627.294.748 Skype: aschurman From: Alexander Schurman [mailto:asc...@pe...] Sent: Wednesday, January 07, 2015 5:11 PM To: Luc Boudreau Cc: ola...@li...<mailto:ola...@li...> Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue I agree with you that a combination is the best scenario. Just one additional comment Currently if we have 20 cubes, that generates 21 XMLA request (1 for get list of cubes and 1 for each cube loading the measures), so fixing issue A, reduces 90% of the performance issue. Alexander Schurman Enterprise Architecture Team <image001.png> Direct: +34 627.294.748 Skype: aschurman From: Luc Boudreau [mailto:luc...@gm...] Sent: Wednesday, January 07, 2015 5:03 PM To: Alexander Schurman Cc: ola...@li...<mailto:ola...@li...> Subject: Re: [Olap4j-devel] Olap4j - XMLA Cube Metadata Loader causes performance issue I think the solution is a mix of A and B. A) It's a good idea to make this collection lazy, unless we know for certain that we will trigger it lower down. We'll look at the code and figure it out. But fixing this won't help much without B) because we would still ask for all cubes. B) We should pass the cube object to the CellSet in its constructor without iterating. If it's too early in the process and the cube object is not readily available, we should issue a single metadata request for that single cube. (MDSCHEMA_CUBES w/ restrictions). On Wed, Jan 7, 2015 at 10:24 AM, Alexander Schurman <asc...@pe...<mailto:asc...@pe...>> wrote: Hello OLAP4j Team, I was on conversation with Luc Boudreau about a performance issue I was getting for a large XMLA dependent app. BASIC INFO: Server is a Pentaho 5.2 XMLA provider (based on Mondrian 3.8.x) There is only 1 schema, but with 20 cubes, and 20-30 measures each cube. USE CASE: Send MDX queries and parse the result values. THE ISSUE: Basically the Issue is that the FIRST MDX query is taking a long time because it is LOADING all the Schema info for all the Cubes. The MDX query it-self only takes 1s, but the response from “”….executeOlapQuery(mdx1);” takes like 1 minute. HOW TO REPRODUCE: Just take any SCHEMA use for testing on the SERVER side and copy one of the CUBES many times just with different names. The more Cubes you add the slower MDX 1 is. THE CAUSE DETECTED: When the XmlaOlap4jCellSet class is called to load the MDX data, it calls a method called lookupCube. The issue is that this LOOKUPCUBE is actually using internally a FOREACH cube in the Schema: LINE 576: for (Cube cube : databaseMetaData.olap4jConnection.getOlapSchema().getCubes()) Reading a little more about what the getCubes() does I checked that most of the Dimensions info is loaded with a deferred lazy method, which is good, except Measures, with say in the code and I state it: Line 119: File: XmlaOlap4jCube.java // populate measures up front; a measure is needed in every query olap4jConnection.populateList( measures, context, XmlaOlap4jConnection.MetadataRequest.MDSCHEMA_MEASURES, new XmlaOlap4jConnection.MeasureHandler(), restrictions); for (XmlaOlap4jMeasure measure : measures) { measuresMap.put(measure.getUniqueName(), measure); } Which it is not deferred. I Commented this PART to check if it had an impact on the RESULT time and furthermore if the MDX result is affected by not having this info and the First MDX speed was reduced to 3 seconds aprox. (XMLA is still loading all the CUBES, but not loading the Metadata of the Measures that we are not using or not requesting from the Metadata.) POSSIBLE SOLUTIONS: I believe we have the following options: A. We change the MEASURES to be also part of the Lazy loader like other dimensions. But I do not know for what it is used the measureMap loaded after load B. We do not read ALL the cubes when we are doing an MDX to only 1 cube. C. Any other ideas are welcome Regards, alex Alexander Schurman Enterprise Architecture Team <image001.png> Direct: +34 627.294.748<tel:%2B34%C2%A0627.294.748> Skype: aschurman ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ olap4j-devel mailing list ola...@li...<mailto:ola...@li...> https://lists.sourceforge.net/lists/listinfo/olap4j-devel <olap4j.diff> ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ olap4j-devel mailing list ola...@li...<mailto:ola...@li...> https://lists.sourceforge.net/lists/listinfo/olap4j-devel |