Home » Archived » Buckminster » Kepler Resolve & Materialize Performance-Issue(Kepler Resolve & Materialize Performance-Issue)
Kepler Resolve & Materialize Performance-Issue [message #1235013] |
Thu, 23 January 2014 10:53  |
Eclipse User |
|
|
|
hi,
when we update our environment from juno (eclipse project sdk 4.2.2/buckminster 1.5.0) to kepler (eclipse project sdk 4.3.1/buckminster 1.6.0)
our resolve & materialize process will take much longer than before.
juno: 1 minute 12 seconds
kepler: 8 minute 46 seconds
this resolve job contacts 300 p2 repositories via http.
does anyone notice similar behaviour?
thanks, adrian
[Updated on: Thu, 23 January 2014 11:35] by Moderator Report message to a moderator
|
|
| |
Re: Kepler Resolve & Materialize Performace-Issue [message #1239044 is a reply to message #1236516] |
Mon, 03 February 2014 07:40   |
Eclipse User |
|
|
|
hi lorenzo,
thanks for your help. but unfortunately this can't be the problem because there is no juno or kepler p2-repository involved.
in those p2 repositories are only our "own" artifacts stored and for both "resolve and materialize" actions, exactly the same p2 repositories are contacted and the same artifacts are downloaded.
cheers, adrian
|
|
|
Re: Kepler Resolve & Materialize Performace-Issue [message #1246015 is a reply to message #1239044] |
Fri, 14 February 2014 15:54   |
Eclipse User |
|
|
|
dear bucky development team,
did anyone notice similar behavior?
first I had the suspicion, that the change in the ecf-project from org.apche.commons.httpclient to org.apache.httpcomponents is responsible for this behavior,
but then I made some measurements inside the HttpClientRetrieveFileTransfer class of the ecf-framework and there was no difference between Juno and Kepler.
so I guess the leak must be inside buckminster where the information of the downloaded content.jar from a p2-repository is analyzed and processed...
regards, adrian
[Updated on: Fri, 14 February 2014 15:55] by Moderator Report message to a moderator
|
|
| |
Re: Kepler Resolve & Materialize Performace-Issue [message #1259546 is a reply to message #1248777] |
Fri, 28 February 2014 14:12   |
Eclipse User |
|
|
|
hi,
i think it isn't enough to just share the cquery/rmap... therefore i made an example cquery with an example p2-repository.
to test this example, just install the p2 repository in apache and run the cqery against it.
for repeatable tests, i set up an local apache in a vm, set the maximum number of resolver threads to 1 and the network settings to direct.
before every testrun i cleaned the .metadata and .buckminster directory in the workspace because of caching stuff.
the example is simple: there is a bundle named com.test.resolve, this bundle has a dependency to bundle com.test.bundle9, this bundle is located in p2 repository com.test.feature9.
the bundle com.test.bundle9 has a dependency to bundle com.test.bundle8 witch is located in p2 repository com.test.feature8... and so on until bundle1 in feature1.
test results (seconds):
juno
resolve to wizard:
test1: 2,3
test2: 1,7
resolve and materialize:
test1: 10,3
test2: 10,5
kepler:
resolve to wizard:
test1: 5,8
test2: 5,8
resolve and materialize:
test1: 26,5
test2: 26,4
regards, adrian
|
|
|
Re: Kepler Resolve & Materialize Performace-Issue [message #1268598 is a reply to message #1259546] |
Mon, 10 March 2014 18:17   |
Eclipse User |
|
|
|
Hi Adrian
I cannot test it right now, but I see that your cquery contains
useMaterialization="false"
useRemoteResolution="false"
useTargetPlatform="false"
this might cause it to check the repositories each time over and over...
could you please try to remove them and see if something changes? If I
understand correctly the meaning of those flags from the documentation...
cheers
Lorenzo
On 28/02/2014 15:12, Adrian Gaberell wrote:
> hi,
>
> i think it isn't enough to just share the cquery/rmap... therefore i made an example cquery with an example p2-repository.
> to test this example, just install the p2 repository in apache and run the cqery against it.
> for repeatable tests, i set up an local apache in a vm, set the maximum number of resolver threads to 1 and the network settings to direct.
> before every testrun i cleaned the .metadata and .buckminster directory in the workspace because of caching stuff.
>
> the example is simple: there is a bundle named com.test.resolve, this bundle has a dependency to bundle com.test.bundle9, this bundle is located in p2 repository com.test.feature9.
> the bundle com.test.bundle9 has a dependency to bundle com.test.bundle8 witch is located in p2 repository com.test.feature8... and so on until bundle1 in feature1.
>
> test results (seconds):
> juno
> resolve to wizard:
> test1: 2,3
> test2: 1,7
>
> resolve and materialize:
> test1: 10,3
> test2: 10,5
>
> kepler:
> resolve to wizard:
> test1: 5,8
> test2: 5,8
>
> resolve and materialize:
> test1: 26,5
> test2: 26,4
>
> regards, adrian
>
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
|
|
|
Re: Kepler Resolve & Materialize Performace-Issue [message #1269175 is a reply to message #1268598] |
Tue, 11 March 2014 13:35   |
Eclipse User |
|
|
|
hi lorenzo,
those flags are only used for the bundle witch is desired as source:
<cq:advisorNode namePattern="com.test.resolve" mutableLevel="REQUIRE" sourceLevel="REQUIRE" useMaterialization="false" useRemoteResolution="false" useTargetPlatform="false"/>
not for the ones desired as binary (com.test.(bundle|feature):
<cq:advisorNode namePattern=".*" mutableLevel="REJECT" sourceLevel="REJECT" useWorkspace="false"/>
I have chosen this pattern, because I don't want to install a source-repository for this simple sample where I had to expand the rmap with unnecessary stuff.
the problem is, if the resolve & materialize task need to download the information from a p2 repository I takes much longer with the new version.
if you have a product with a lot of different features and plugins, this will happens every time you run resolve & materialize, because the bundles in the p2 repository may change with every nightly-build.
regards, adrian
|
|
|
Re: Kepler Resolve &amp;amp;amp; Materialize Performace-Issue [message #1281708 is a reply to message #1269175] |
Tue, 01 April 2014 08:38  |
Eclipse User |
|
|
|
On 11/03/2014 14:35, Adrian Gaberell wrote:
> hi lorenzo,
>
> those flags are only used for the bundle witch is desired as source:
> <cq:advisorNode namePattern="com.test.resolve" mutableLevel="REQUIRE"
> sourceLevel="REQUIRE" useMaterialization="false"
> useRemoteResolution="false" useTargetPlatform="false"/>
> not for the ones desired as binary (com.test.(bundle|feature):
> <cq:advisorNode namePattern=".*" mutableLevel="REJECT"
> sourceLevel="REJECT" useWorkspace="false"/>
> I have chosen this pattern, because I don't want to install a
> source-repository for this simple sample where I had to expand the rmap
> with unnecessary stuff.
>
> the problem is, if the resolve & materialize task need to download the
> information from a p2 repository I takes much longer with the new version.
> if you have a product with a lot of different features and plugins, this
> will happens every time you run resolve & materialize, because the
> bundles in the p2 repository may change with every nightly-build.
>
> regards, adrian
Hi
in this case I wouldn't know... I guess only Thomas can say something
useful :)
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Xtext Book:
http://www.packtpub.com/implementing-domain-specific-languages-with-xtext-and-xtend/book
|
|
|
Goto Forum:
Current Time: Mon Feb 17 23:46:28 GMT 2025
Powered by FUDForum. Page generated in 0.04453 seconds
|