For reference, here's what I tried. I only created 100,000 documents and they
are very small.
(: setup :)
(1 to 100 * 1000) ! (
xdmp:document-insert(
'/test/'||.,
element test {
attribute id { . },
element a { xdmp:integer-to-hex(xdmp:random()) } },
('read', 'update') ! xdmp:permission('test', .))),
xdmp:elapsed-time()
That takes about 30-sec on my laptop.
(: test - admin :)
(for $i in 1 to 1000
return cts:element-value-match(xs:QName("a"), "e*", "limit=1"))[last()],
xdmp:elapsed-time()
=>
e0003170ed3130a4
PT0.084827S
(: test - user :)
xdmp:eval('
(for $i in 1 to 1000
return cts:element-value-match(
xs:QName("a"), "e*", "limit=1"))[last()]',
(),
<options xmlns="xdmp:eval">
<user-id>test</user-id>
</options>),
xdmp:elapsed-time()
=>
e0003170ed3130a4
PT0.07878S
In this particular run the non-admin user was faster - but that is probably a
caching effect, and anyway the difference was not significant. I'm using
6.0-2.1 on OS X, running the queries in cq.
There are about 6700 values that match 'e*'. According to the profiler, about
50% of the elapsed time is spent in the cts:element-value-match call. The rest
is split between the FLWOR and the predicate on last().
-- Mike
On 25 Mar 2013, at 15:15 , Will Thompson <[email protected]> wrote:
> I've tested this on on 6.0-2 (OSX) and 6.0-2.2 (Windows), and both have
> the same issue. The xdmp:plan output is the same under both users. Maybe I
> should try creating a more isolated test case...
>
> -Will
>
>
> On 3/25/13 2:53 PM, "Michael Blakeley" <[email protected]> wrote:
>
>> An amp shouldn't really be necessary, but it's puzzling that you see such
>> a large difference. I tried to set up a similar test with some data I had
>> handy, and saw a difference of less than 5% between admin and non-admin
>> users.
>>
>> Which release are you using?
>>
>> -- Mike
>>
>> On 25 Mar 2013, at 14:20 , Will Thompson <[email protected]>
>> wrote:
>>
>>> Mike - It seems to ignore the query-trace (inside or outside eval), but
>>> I
>>> suspect you're right. Unfortunately this is dramatic enough to be the
>>> difference between a usable and unusable autocomplete solution, in which
>>> we're squeezing as much as we can into a limited time budget. We will
>>> need
>>> to run the query as case- and diacritic-insensitive.
>>>
>>> Will I need to amp this operation to run under the admin role to be be
>>> performant?
>>>
>>> -W
>>>
>>>
>>> On 3/25/13 1:54 PM, "Michael Blakeley" <[email protected]> wrote:
>>>
>>>> The non-admin user should be checking extra query terms, to enforce the
>>>> read permissions it has through its roles. That might be enough to
>>>> explain the difference. I think the extra terms will show up in an
>>>> xdmp:query-trace, if you want to verify that.
>>>>
>>>> You might also try the 'diacritic-sensitive' and 'case-sensitive'
>>>> options. That should speed up the value-matching a bit.
>>>>
>>>> -- Mike
>>>>
>>>> On 25 Mar 2013, at 13:40 , Will Thompson <[email protected]>
>>>> wrote:
>>>>
>>>>> I ran this in a loop 100 times for the limited user and for admin, and
>>>>> the limited user was roughly 50X slower than admin:
>>>>>
>>>>> xdmp:eval(concat(
>>>>> 'xquery version "1.0-ml";',
>>>>> 'cts:element-value-match(xs:QName("element"), "value*", "limit=1")'),
>>>>> (),
>>>>> <options xmlns="xdmp:eval">
>>>>> <user-id>{ xdmp:user("limited") }</user-id>
>>>>> </options>)
>>>>>
>>>>> The limited user has a role with read permissions on the documents
>>>>> containing those values (obviously, since it returns non-empty
>>>>> results),
>>>>> and also has the app-user role. Otherwise, this user has no other
>>>>> roles.
>>>>> With log level = debug, nothing really jumps out at me. I only see
>>>>> occasional "InMemoryStand", "OnDiskStand", and "Saving" messages, and
>>>>> they appear regardless of the user running the query.
>>>>>
>>>>> -Will
>>>>> _______________________________________________
>>>>> General mailing list
>>>>> [email protected]
>>>>> http://developer.marklogic.com/mailman/listinfo/general
>>>>
>>>> _______________________________________________
>>>> General mailing list
>>>> [email protected]
>>>> http://developer.marklogic.com/mailman/listinfo/general
>>>
>>> _______________________________________________
>>> General mailing list
>>> [email protected]
>>> http://developer.marklogic.com/mailman/listinfo/general
>>>
>>
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://developer.marklogic.com/mailman/listinfo/general
>
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
>
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
