[
https://issues.apache.org/jira/browse/SLING-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-756:
--------------------------------------
Attachment: SLING-756-graph.sh
Thanks foir the info, will try that.
To be able to measure progress I have added a log of bundle startup time in
revision 723284.
With this, running the extensions/jcrinstall/testing test as follows:
export MAVEN_OPTS="-Xmx384M"
mvn clean install -D sling.test.scale.factor=20 -D
sling.test.bundles.wait.seconds=200
Produces the following results (bundle.start() duration) when filtering the
target/it/sling/logs/error.log with the attached script:
0...100 msec: 433 samples
100...200 msec: 216 samples
200...300 msec: 91 samples
300...400 msec: 38 samples
400...500 msec: 10 samples
500...600 msec: 5 samples
600...700 msec: 1 samples
Total 800 samples
800 samples seems double what we'd need (140 + 260), but that's another story -
about 50% of the bundle.start() calls take more than 100 msec, that's slow.
> Bundle startup becomes very slow with many bundles present
> ----------------------------------------------------------
>
> Key: SLING-756
> URL: https://issues.apache.org/jira/browse/SLING-756
> Project: Sling
> Issue Type: Bug
> Components: JCR Install
> Reporter: Bertrand Delacretaz
> Attachments: SLING-756-graph.sh
>
>
> When running the jcrinstall integration tests with a few hundreds of very
> simple bundles, the bundle.start call in the BundleResourceProcessor class
> becomes very slow. With a few bundles it takes only a few milliseconds, and
> goes up to the 500 msec range with about 500 installed bundles.
> Seems like most of that time is spent in the Felix
> R4SearchPolicyCore.resolve() method, but I haven't investigated that in
> detail yet.
> To reproduce, run "mvn clean install" in extensions/jcrinstall/testing, with
> these parameters:
> -D sling.test.scale.factor = 20
> -D sling.test.bundles.wait.seconds = 200
> With these values, the StopAndChangeBundlesTest installs 140 bundles by
> copying them into the repository, disables jcrinstall, replaces the bundles
> with 260 new ones and reactivates jcrinstall.
> When reactivated, jcrinstall uninistalls the 140 bundles and then installs
> and starts the 260 new ones - this is when the bundle.start becomes very slow.
> All bundles are clones of the extensions/jcrinstall/testbundles/observer
> bundle, same code but unique bundle symbolic name and name. This causes
> warnings from the Felix framework as all bundle clones contain a component
> with the same name. I don't think that's related to the long start time
> though.
> As it seems like the problem has to do with resolving the bundle, here are
> the package exports/imports of the test bundle:
> exports: none
> imports:
> javax.jcr,version=1.0.0 from org.apache.sling.jcr.api (16)
> javax.jcr.observation,version=1.0.0 from org.apache.sling.jcr.api (16)
> org.apache.sling.jcr.api,version=2.0.3.incubator-SNAPSHOT from
> org.apache.sling.jcr.api (16)
> org.osgi.framework,version=1.4.0 from System Bundle (0)
> org.osgi.service.component,version=1.0.0 from System Bundle (0)
> org.slf4j,version=1.5.2 from org.apache.sling.commons.log (19)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
