-
1. Re: Performance problem
One thing I worked on in the past is https://jira.jboss.org/jira/browse/JBKERNEL-4 which does more work on undeploy, but it should not be that much.
Try commenting the call to uninstallUnusedOnDemandContexts() in AbstractController.uninstallContext() to see if it makes any difference. -
2. Re: Performance problem
The issue appears to be in the VFS.
If I comment out the reading of the manifest for the package information
(which uses the VFS) then the tests take about 16 seconds (i.e. less than half the time).
BaseClassLoader::definePackage- PackageInformation pi = policy.getClassPackageInformation(className, packageName); + PackageInformation pi = null;
This is using jboss-vfs 2.1.2.GA -
3. Re: Performance problem
I guess you're reading a lot of different manifest files.
Since all of the code in VFSCLPolicy is cached.
But to read a manifest, a lot of slow ops are present.
* find the root with class file
** read-in all jars
** navigate to class file
* read manifest.mf
** again navigate
** read manifest attributes
Which means a lot of PathTokenizer and StructuredVirtualFileHandler usage.
With VFS-performance issue already present in MC dev forum,
I'll have a look what can be improved, and then re-run this here. -
4. Re: Performance problem
The issue is that this has got a slower with 2.1.2.GA.
40 seconds vs 10 seconds
I can't tell which version I was using before since we now use the Maven plugin
to generate the classpath. This means there's no history in .classpath files.
I guess you could checkout the project from a week ago and see what it uses
(assuming the snapshots haven't changed)? -
5. Re: Performance problem
"adrian@jboss.org" wrote:
The issue is that this has got a slower with 2.1.2.GA.
Hmmm ... most of the recent VFS work was done on handling the temps.
(hence new 2.1 branch, since we changed api; TempInfo, ...)
And since I doubt we use any temps handling in this case, this shouldn't made such huge performance degradation. -
6. Re: Performance problem
"adrian@jboss.org" wrote:
I can't tell which version I was using before since we now use the Maven plugin
to generate the classpath. This means there's no history in .classpath files.
I guess you could checkout the project from a week ago and see what it uses
(assuming the snapshots haven't changed)?
Or use fisheye. :-)
- http://fisheye.jboss.org/browse/JBossAS/projects/jboss-osgi/projects/runtime/microcontainer/trunk/pom.xml?r=92424
It looks like you were on VFS 2.1.2.GA all the time,
as I'm pretty sure Kernel 2.0.6.GA and Deployers 2.0.8.GA use the latest one. -
7. Re: Performance problem
But its not coming from there. Its using a transient dependency on deployers-vfs-spi
which is currently at snapshot.$ mvn dependency:tree <snip/> [INFO] +- org.jboss.deployers:jboss-deployers-vfs-spi:jar:2.0.8-SNAPSHOT:compile [INFO] | +- org.jboss:jboss-vfs:jar:2.1.2.GA:compile
So who knows what it used before? ;-) -
8. Re: Performance problem
I should also mention that most of these tests are using the AssembledDirectory
so I can (re-)use the test support classes directly without having to do a packaging step.
Maybe the issue is there? -
9. Re: Performance problem
"adrian@jboss.org" wrote:
But its not coming from there. Its using a transient dependency on deployers-vfs-spi which is currently at snapshot.
Sure, that's why I'm saying:alesj wrote:
as I'm pretty sure Kernel 2.0.6.GA and Deployers 2.0.8.GA use the latest one."adrian@jboss.org" wrote:
So who knows what it used before? ;-)
I know. ;-)
Deployers' VFS update:
- http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/branches/Branch_2_0/pom.xml?r=88803
still being done on 2.0.7.
So, unless someone downgraded VFS in the meanwhile, 2.0.8. should have VFS 2.1.2.GA. -
10. Re: Performance problem
"adrian@jboss.org" wrote:
I should also mention that most of these tests are using the AssembledDirectory
so I can (re-)use the test support classes directly without having to do a packaging step.
Maybe the issue is there?
As you already know, Assembled stuff is pretty slow - I remember your comments when we first used it in Deployers tests.
If you just recently changed this (applying its usage), than this is definitely the culprit.
If you used this before, then I'm out of ideas. :-) -
11. Re: Performance problem
"alesj" wrote:
"adrian@jboss.org" wrote:
I should also mention that most of these tests are using the AssembledDirectory
so I can (re-)use the test support classes directly without having to do a packaging step.
Maybe the issue is there?
As you already know, Assembled stuff is pretty slow - I remember your comments when we first used it in Deployers tests.
If you just recently changed this (applying its usage), than this is definitely the culprit.
If you used this before, then I'm out of ideas. :-)
But that was building the stuff since the api required you to scan
the whole file system with a filter instead of being able to say exactly what you
wanted to include.
e.g. if I want to include classes in classes/org/foo/bar I has to pass "classes"
with a filter "org/foo/bar/*" which scans everything in classes.
The runtime stuff shouldn't be slow, i.e. just looking at the constructed tree
for the indirections.
P.S. The AssembledDirectory also needs some remove() or clear() methods.
There is one on AssembledDirectoryHandler but that is a private api. -
12. Re: Performance problem
"alesj" wrote:
"adrian@jboss.org" wrote:
But its not coming from there. Its using a transient dependency on deployers-vfs-spi which is currently at snapshot.
Sure, that's why I'm saying:alesj wrote:
as I'm pretty sure Kernel 2.0.6.GA and Deployers 2.0.8.GA use the latest one."adrian@jboss.org" wrote:
So who knows what it used before? ;-)
I know. ;-)
Deployers' VFS update:
- http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/branches/Branch_2_0/pom.xml?r=88803
still being done on 2.0.7.
So, unless someone downgraded VFS in the meanwhile, 2.0.8. should have VFS 2.1.2.GA.
Anyway, the real issue isn't trying to find out what Maven is/was doing,
that was just to try to locate what code changed and might have introduced the problem.
The issue is why is there x4 performance degradation.
In particular why is it taking 24 seconds to parse some manifests when
previously I could run the whole testsuite in less than half that time. -
13. Re: Performance problem
"adrian@jboss.org" wrote:
The issue is why is there x4 performance degradation.
I still don't know what you changed, if you changed anything at all? -
14. Re: Performance problem
"alesj" wrote:
"adrian@jboss.org" wrote:
The issue is why is there x4 performance degradation.
I still don't know what you changed, if you changed anything at all?
I'm saying if you can't work out what changed, try it from the other direction.
What is causing the 24 seconds delay with and without that one line patch above?
Once that is determined it should be obvious what changed? ;-)
I'll have a look at it later this week once I've finished working on my current stuff,
if you haven't already found it by then. :-)