0
votes

Our project is using MarkLogic XDBC server with a thread count of 32. Task server thread count is also 32. Update on few entities (from UI) fire CPF triggers (T1) on Task server on some linked documents in database in another collection. Linked documents count is not bound due to business rules. Some entities are linked to 0 documents while other can be linked with 100k or more.

When any entity is updated which is having a large number of linked documents, let say 20k, then system gets under load and any requests coming on XDBC server experiences latency. System works fine when this count is smaller, ranging from 0 to 2k.

Note: Update of linked document count over 2k or 3k is not very frequent in a day. It happens twice or thrice in a day.

Question:

Though, ~20k triggers on task server gets over in 15 minutes but user experience is bad on UI even for the lightest request (communicating through XDBC) during that time.

Is there any way in which we can set XDBC server to serve the requests ASAP and Task server requests can bear majority of the latency caused due to load. Basically, we want some kind of load partition approach reserved (breathing space) for App servers, irrespective of task server queue load. Utmost priorities should be given to XDBC requests.

Server config:

  • 128 GB RAM, Virtual processors 16

  • 1 TB Database size distributed among 8 forests.

  • Task server queue size - 1000k

1

1 Answers

0
votes

using xdbc eval, you can spawn the updates into the task server queue, offloading the xdbc threads for interactive low-latency use. You can then manage the task server queue and thread pools independently from the xdbc threads.