6

We have issue where our database transactions get locked during mass publishing on live. We are running broker db in mssql. We have following configuration in cd_deployer_conf.xml file:

<Queue> 
    <Location Path="/opt/deployer/work" WindowSize="80" Workers="40" Cleanup="true" Interval="2s"/>
</Queue>

We also do publishing on 2 destinations. What we observe is that our transactions get locked in database during mass publishing on both destinations, and transactions just stop changing states. What we need to do then is remote to DB server and manually kill db transactions.

We contacted SDL support and they suggest decreasing number of workers, which is unacceptable to us because of performance. Has anyone observed similar issue and how they fixed it?

Thanks in advance.

8
  • Are you seeing 'deadlock' issue similar to tridion.stackexchange.com/questions/11909/… or a 'race' condition to the broker database? Can you add relevant logs too?
    – Shiva
    Feb 9 '17 at 14:49
  • This statement has me a bit confused "which is unacceptable to us because of performance" - wouldn't a stable environment with stronger and reliable throughput provide better performance than one that breaks? I've seen recommendations for not using more than 4 deployer workers, so insisting on using 40 doesn't seem to be helping...
    – Nuno Linhares
    Feb 9 '17 at 15:42
  • We used to have big problems with publishing too, but the publishing power tool has alleviated some of those problems (github.com/TridionCommunity/tridion-powertools) as it allows you to send pages through to the queue individually if you're publishing a component or a structure group. Feb 9 '17 at 16:15
  • @Nuno, yes, i agree with your conclusion, but again, it was all depending on a clients requirement. We needed to have initial publish for more than 230 website, where publishing of one took between 10 and 12 hours (that is with 40 workers). As you can observe, entire initial publish should take more than 3 months. Decreasing workers no. will increase time tenfold. Also, we were under the impression that system is scalable, but it being not able to deliver, is big design flaw. Now the publish time is decreased with web8, but we are still on 20133 sp1. Feb 9 '17 at 17:49
  • @Harald, we created our own custom tool that excludes all related items during publishing. We send items to publish via core service, so that way we decreased publish time. But even now, almost 8 months later, we are still having publish queue full 24/7. :( Feb 9 '17 at 17:52
3

We face the similar challenge at our PROD environment and want to share a bit thoughts here.

Each time when we publish mass files, if each file need time to rendering, then depends on the files number, the rendering process will be slower and slower until totally idled. If we are publishing resource, like image, which doesn't need too much time for render, the deployment action will be just idled if too many files under the waiting for deployment status.

For sure it is reasonable the publish performance depends on the environment limitation, but it is also a signal the Tridion publish queue design is not stable.

First, it is a queue system. A queue system should be able to receive as many task as possible, but only process the limited tasks with a stable speed without crash the entire queue. At our first test case, too many tasks in the waiting list actually will totally block the queue, which will made no task can be start. At second case, Tridion queue should auto detect if too many files be move to next stage, it should auto slow down the previous step to avoid overload the next step.

Second, there is no clear guideline or reference to show us, at which CPU and Memory configuration, it can support how many deployer work parallelize. In an ideal situation, it should even auto detect the current environment setting, and give us an number which can secure the stability. If we want to take the risk to add a bigger number, it is our business. But right now even we want to secure it, it is still unclear how configure the number. The answer we get from SDL support side is there is no guideline for this topic.

It is more like a half-finished product, which need client a lot of try / test/ guess to stable the publish queue.

1
  • 1
    I agree. Our bottleneck was deploying phase, because we decreased rendering time by excluding all related items. That way we ensured that only sent items will be rendered and in package. This is ok option for initial publish, but not after that, because all related items SHOULD be republished (we observed that they can take up to 1500 resolved items in our case). Then we have rendering phase that lasts more than 2 hours, which is indeed not ok. One side note is that we have 2 out-scaled publishers each with 8 treads. Feb 9 '17 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.