OK, I’ve done some more timing analysis and determined that, as expected, the reverse query takes the bulk of the time.
So it looks like 0.025 seconds for this reverse query is the time we can expect and that any performance improvement will come from improved and/or more hardware. Cheers, Eliot -- Eliot Kimber http://contrext.com On 5/16/17, 10:14 AM, "Eliot Kimber" <[email protected] on behalf of [email protected]> wrote: Apparently I’m an idiot—it was pointed out that the time for the cts:and-query() is just the query constructor, which of course takes no time, so the reported time is the time for the search itself. I can do more testing to see what time each part of the search. Cheers, E. -- Eliot Kimber http://contrext.com On 5/16/17, 9:33 AM, "Eliot Kimber" <[email protected] on behalf of [email protected]> wrote: Some more background: there are about 2.5 million MatchingQuery documents in the database I’m testing with. The reverse query index is of course turned on. Cheers, E. -- Eliot Kimber http://contrext.com On 5/15/17, 7:44 PM, "[email protected] on behalf of Eliot Kimber" <[email protected] on behalf of [email protected]> wrote: I’m getting a raw profiling report outside the context of CQ and trying to do some analysis on it (I’m running the same operation on several hundred input objects and collecting the profiling for each instance in order to try to get better trend data). I’ve identified one expression that takes the bulk of the processing time but the profiling details aren’t adding up so I’m wondering what I’m missing. Here’s the expression that is reported in the histogram: cts:search(fn:collection()/MatchingQuery, cts:and-query((func:func-returns-boolean($some-param), cts:collection-query("collection-name"), cts:reverse-query($node))), "unfiltered") The intent of this search is to find MatchingQuery documents that match the node in $node. The deep time for this is PT0.023642S and the shallow time is PT0.023289S, which is what I would expect (shallow and deep almost the same). So the question is, which of these terms is contributing to this time? If I search for histogram entries for the individual terms I get a deep time of “0.000342” for the cts:and-query, which is obviously a small fraction of total time of 0.023 seconds. Does that mean that the “fn:collection()/MatchingQuery” term accounts for the remaining time (the bulk of the 0.23 seconds)? If not, what accounts for the remaining time? I’m also capturing the query meters and the only cache misses I’m seeing are value cache misses (17 misses, 1 hit). I’m not sure what aspect of this query (if any) would hit the value cache. So my question: what are these times telling me about this particular search expression? Thanks, Eliot -- Eliot Kimber http://contrext.com _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
