good to know Tks, have a good week end Lanz
On Thu, Jun 25, 2015 at 12:32 PM, Stephane Toussaint < [email protected]> wrote: > Hi, > > Because it could help (even if nobody seems to use this feature ;-)), here > is how I finally solved my performance issue. > > I was using a timestamp computed from the client side (javascript). And > the first time I query with this timestamp it made up to 40 seconds to > return the results. > > Now, if the timestamp is not set (non paginated query), I return the > timestamp using the xdmp:request-timestamp() function along with the > result. Subsequent query then use this timestamp and now, even with the > first « pagination » call, the result is returned as fast as expected. > > Regards, > Stéphane > > > Le 17 juin 2015 à 14:38, Stephane Toussaint < > [email protected]> a écrit : > > Hi, > > I recently try to use Point In Time Queries as a workaround for « Safe > pagination searching in updatable environnement », but encounter some > performance issues. Short explanation of what I’ve done so far : > > - I initiate a search without a particular timestamp which returns the > first n results. > - Now if I want to navigate in pages but because content may be created or > updated, and because it may change the result sequence, I switch to « Point > in Time search query ». To do this, I simply use the timestamp at which the > new search was initiated (and keep that timestamp for page navigation. It > will be reset if search changed). > > It works as expected except that, the first time a query is triggered > using the timestamp (see code behind), the query is « abnormally » long; 10 > up to 40 seconds instead of a few milliseconds. > > *xdmp:invoke-function*( > *function*() {*search:search*("", *$options*, *$offset*, *$pageSize*)}, > <options *xmlns*=*"xdmp:eval"*> > <timestamp>{*$timestamp*}</timestamp> > </options> > ) > > The query itself is quiet simple in my reproductible case, it’s only a > cts:collection-query. > > Is there some known performance issue with point in time queries ? > Extra question, is this a feature you judge appropriate for this use case ? > > Thanks for help, > Stéphane > > PS : I use ML 8.0, I do understant that fragments are now kept for 1 hour > even if no timestamp merge is set, it's enough for my use case and works as > expected > > > > _______________________________________________ > 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
