On 22 February 2013 14:13, Justin Edelson <[email protected]> wrote:
> On Thu, Feb 21, 2013 at 10:29 AM, Carsten Ziegeler
> <[email protected]>wrote:
>
>> 2013/2/21 Marcel Reutegger <[email protected]>:
>> > Hi,
>> >
>> > it means it will traverse the entire workspace to find nodes with
>> > a sling:vanityPath property.
>>
>> So this query we're using as well:
>>
>> SELECT sling:alias FROM nt:base WHERE sling:alias IS NOT NULL
>>
>> will already be slow as hell with a large repo, right?
>>
>
> IIUC, the performance would be improvable by defining an index on the
> sling:alias property (or sling:vanityPath property in the original case). I
> suspect that this is going to be a necessity regardless of what node type
> is used, at least for sling:vanityPath. At least in our commercial product,
> it's not uncommon to see tens or hundreds of thousands of nodes with the
> sling:VanityPath mixin (only a vast minority actually have the property
> set). If Oak is going to get the list of all nodes with that mixin type and
> then filter out based on property existence, that's better than iterating
> over EVERY node, but not as performant as it is in JR2.
>
> Back to the original question, it might be possible to get the timing
> information by using our existing vanity path related performance tests. As
> we've had lots of issues with performance and vanity paths, I'd really like
> to get some hard numbers before changing direction. I don't have any
> problems changing the semantics, even though it is non-backwards compatible.
I might be going off topic, apologies:
I am sure you know this, but I am going to say it anyway (perhaps for
others that don't).
The query is used to construct the mapping map (in MapEntries) used
by the resource resolver for forward and backward mapping of urls.
Once constructed the map remains static until something else triggers
a rebuild.
Unless you see a cpu spike when modifying a vanity path, I dont think
rebuilding the map will be a performance issue. (note the "think". I
dont have hard evidence :( )
repos with 1000s of vanity paths will generate a mapping structure
with 1000s of entries, and although in memory map lookups are super
fast, I am not convinced that the structure is used as a map see [1],
which looks suspiciously like iterating over all entries in the map.
Hence, if you add 1000s then this call
final Iterator<MapEntry> mapEntriesIterator =
this.factory.getMapEntries().getResolveMapsIterator(requestPath);
in resource resolver map is going to be a hot spot, as its called on
every resolution, and for every match that is found a remapping is
performed.
I could be reading the code wrong, but I think that if this is the
case, the way in which the path is mapped should be changed, so that
the map is used like a map or a hierarchical tree of maps is used in
the same way the resource resolver was converted from a list to that
some time ago.
I think all it would need is:
String[] pathElements = path.split("/");
Map<String, ? > m = rootMappingEntry;
for (String part : pathElements ) {
Map<String, ?> nm = m.get(part);
if ( nm == null ) break;
m = nm;
}
what ever is left in m is the closest match for the inbound path wrt
the mapping operation. I think that will scale ?
Ian
1
org.apache.sling.resourceresolver.impl.mapping.MapEntries.MapEntryIterator.seek()
>
> Regards,
> Justin
>
>
>
>>
>> Carsten
>>
>> >
>> > Regards
>> > Marcel
>> >
>> >> -----Original Message-----
>> >> From: Felix Meschberger [mailto:[email protected]]
>> >> Sent: Donnerstag, 21. Februar 2013 14:33
>> >> To: [email protected]
>> >> Subject: Re: Vanity Path query
>> >>
>> >> Hi
>> >>
>> >> You mean "property exists" querying will be slow out of the box ?
>> >>
>> >> What does slow mean compared to Jackrabbit 2.x ?
>> >>
>> >> Regards
>> >> Felix
>> >>
>> >> Am 21.02.2013 um 12:57 schrieb Marcel Reutegger:
>> >>
>> >> > one more thing to consider...
>> >> >
>> >> > while it probably won't have that much of an impact with Jackrabbit
>> 2.x
>> >> > the situation is different with Jackrabbit Oak. Oak currently comes
>> with
>> >> > default indexes for jcr:primaryType and jcr:mixinTypes. If you now
>> >> > turn your query into 'FROM nt:base' Oak won't be able to leverage
>> >> > those indexes and the query will be terribly inefficient. You will
>> have
>> >> > to add an index on sling:vanityPath to make if efficient again.
>> >> >
>> >> > regards
>> >> > marcel
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Marcel Reutegger [mailto:[email protected]]
>> >> >> Sent: Donnerstag, 21. Februar 2013 12:53
>> >> >> To: [email protected]
>> >> >> Subject: RE: Vanity Path query
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >>> Does changing "FROM sling:VanityPath" to "FROM nt:base" have any
>> >> >>> noticeable impact on performance or cost of the query ?
>> >> >>> Ian
>> >> >>
>> >> >> probably not. it might even be a bit faster because the query does
>> >> >> not have to filter by node type.
>> >> >>
>> >> >> regards
>> >> >> marcel
>> >>
>> >>
>> >> --
>> >> Felix Meschberger | Principal Scientist | Adobe
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Carsten Ziegeler
>> [email protected]
>>
