Hi Danny,
We’re spinning up a cloud cluster right now to see if we can make it happen
outside Prod. If so, we’ll upgrade the test cluster to the latest release to
see if it fixes the problem. We can’t experiment on Prod, but if we can show
that upgrading will solve the problem then we
Hi Ron,
It is hard to say for sure, but there have been many bug fixes since 8.0-3.2
that can account for some or all of this.
Do you have an environment where you can try out the latest (8.0-5.4)?
-Danny
-Original Message-
From: general-boun...@developer.marklogic.com
We’re seeing a very odd phenomenon on a client project here in the UK.
Queries (as in read-only, no updates) slow down dramatically (from 1.2 seconds
to 30-40 seconds or longer) while “Jobs” are running that do relatively light
updates. But only on multi-node clusters (3 node in this
Thanks Geert for quick reply
As per current process also we are creating large xml by adding all related
fragment, but not committing this large xml into database , so we are
planning to create xml as below.
49d7116c24d541aea73328b761cdd89f
As per above xml
Hi Gary,
I think it will be tricky to translate read rates to qps based on doc
sizes. If I¹m correct, transfer between D and E is compressed tree data.
Reading from disk is even more complex, since the tree data is completely
dissected into strings and structural info. I¹m afraid you are best off
Hi Vikas,
Keep in mind you will be buffering all related fragments in memory while
building this large XML. It might work out, but it won’t scale well. To allow
keeping memory usage small, and streaming through the results, you are better
off returning all xml chunks without wrapping them in a
Hi All,
As per current design in our project we are creating large xml by adding all
small xml chunks for a final outcome .For achieving this we are using
cts:search and this search will work recursively .
Example: We have one xml which contains metadata and all references of it .Now
when we
