[
https://jira.jboss.org/jira/browse/DNA-466?page=com.atlassian.jira.plugin...
]
Randall Hauch commented on DNA-466:
-----------------------------------
My laptop is back to running at normal speed, and I have some new numbers. Here they are
for a depth value of 1, with the measurements including a read of each node (not just
computing the path):
42 samples: min=00:00:00.000; avg=00:00:00.000,408; median=00:00:00.000,001;
stddev=2609310.3454792313; max=00:00:00.017,116 -> 42
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=1958.7584572574413; max=00:00:00.000,013 -> 0
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=843.8116736509215; max=00:00:00.000,005 -> 0
Note that these are quite a bit better than the previous best (in previous comment). Also
note that when loaded, the only activity being measured is the retrieval of the path.
Here are numbers with a depth value of 2:
42 samples: min=00:00:00.000; avg=00:00:00.000,1; median=00:00:00.000,001;
stddev=637613.0071907062; max=00:00:00.004,183 -> 33
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=1644.7539084924329; max=00:00:00.000,011 -> 0
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=1372.0980508784678; max=00:00:00.000,009 -> 0
And with a depth value of 6:
42 samples: min=00:00:00.000; avg=00:00:00.001,794; median=00:00:00.000,001;
stddev=1.1486364528995695E7; max=00:00:00.075,343 -> 1
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=1958.758457257441; max=00:00:00.000,013 -> 0
42 samples: min=00:00:00.000; avg=00:00:00.000,001; median=00:00:00.000,001;
stddev=2385.353075972644; max=00:00:00.000,016 -> 0
Short summary is this: the new design was optimized to maintain a cache of the node
paths, and this shows in these metrics (which are very specific to this use case).
Basically, getting a path for a node is negligible. This is very important if the JCR
implementation is put over a federated connector, since the federated connector relies on
the paths for many of its optimizations.
JCR requires connectors to expose UUID as identifier property
-------------------------------------------------------------
Key: DNA-466
URL:
https://jira.jboss.org/jira/browse/DNA-466
Project: DNA
Issue Type: Bug
Components: JCR
Affects Versions: 0.5
Reporter: Randall Hauch
Assignee: Randall Hauch
Priority: Blocker
Fix For: 0.6
The JCR implementation currently expects connectors to return a UUID as the identifier
property. This is obviously incorrect, as it goes against several of the connectors
we've already implemented. In particular, the SessionCache is expecting to find the
UUID, and submits requests to the source with only the UUID (not the path).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira