You are viewing limited content. For full access, please sign in.

Question

Question

Multiple workflow servers to distribute Workflow Subscriber workload

Version 9 Workflow
Updated November 12, 2015
asked on November 11, 2015

Hello,

Now that we have a fair number of workflows and starting rules in place, we need to distribute the workload onto more than a single workflow server. In fact we need to dedicate a server to higher-priority workflows.

In presence of more than one workflow server, I expect that workflow subscription (evaluation of starting rules) is distributed as well as workflow execution. In other words if I add a workflow with 5 starting rules on workflow server A, workflow subscription workload on server B is not impacted whatsoever. Is that correct ?

Thanks in advance

0 0

Answers

APPROVED ANSWER
replied on November 12, 2015

The Subscriber can only connect to one Workflow Server. So if you want to have 2 servers, you will need 2 Subscribers as well. There is no way to have a single WF Subscriber direct work to multiple servers at this time.

Like Chris said, making sure that rules are not overlapping is very important in this setup since both subscribers would be reading the same activity log. Each would be checking against its own set of starting rules, but that doesn't mean an event can't satisfy a starting rule on both servers at the same time.

Troubleshooting may also be a bit complicated since you would have to double-check both servers to make sure there wasn't a conflict when one of your documents is not routed as expected.

Activity generated in the repository by Workflow Server A may still impact starting rule processing on Workflow Server B.

1 0
SELECTED ANSWER
replied on November 12, 2015

Thank you Miruna !

I will define two virtual machines dedicated to workflows, each one running its own set of services (Laserfiche Workflow and Laserfiche Workflow Subscriber) as well as its own SQL database.

Stéphane

0 0

Replies

replied on November 11, 2015

This page details setting up subscriber on another server. You can setup subscriber on a separate machine than workflow itself to separate the two.

 

Splitting these up can accelerate throughput if one of the machines are maxed out cpu wise. But this won't help you if workflow itself is what is causing the issue instead of subscriber. If the workflows are taking a long time to execute and that is what is causing the backlog separating the processes will not help. In that case a separate workflow server will help, but I'd strongly suggest looking to see if you can optimize any workflows that are running slowly first. There may be tweaks you can make to reduce the time it takes to run those individual workflows.  

 

You can monitor subscriber using the subscriber monitor trace log and live event viewer to gauge how fast it's processing changes in the system and triggering workflows by sending messages to the workflow server. And of course wants it's been queued up they should show up when you view active workflows in workflow designer.

 

 

2 0
replied on November 11, 2015 • Show version history

Thanks Chris for the information.

The issue here is not about execution performance, but 'divide and conquer' so higher-priority workflows are defined and executed onto a different server.

In presence of 2 (or more) workflow servers, does each server run its own «Laserfiche Workflow 9.x Subscriber» Windows service on behalf the starting rules for only (and only) its hosted workflows ?

0 0
View 2 previous replies
replied on November 11, 2015

Yes. You'll have some extra traffic by the WFUSER$ login for subscriber server two. Right now every single thing that happens on the server is monitored by the current WFUSER$ user, now you will have increased traffic because there's a second WFUSER$. I don't know how much traffic that actually is though. I don't think it's too awful bad as there is relatively little processing - if something happens that data is forwarded to subscriber, no analyzing what needs to be sent. 

 

I do know the big thing to watch out for is to make sure your starting rules do not step on each other. You don't want your servers fighting over the same document. 

 

It also obviously makes things a bit more difficult to track as there are now two sets of workflows to go through when something goes awry. 

0 0
replied on November 11, 2015

WFUser$ won't add much traffic since it's just reading the activity log.

The 2 WF Subscribers are not going to be completely independent of each other since they'll be reading the same activity log. So activity generated by the first WFServer will show up in the events read by both subscribers.

But I have to ask if you're really sure that rule processing is the bottleneck here.

0 0
replied on November 11, 2015 • Show version history

Hi Miruna,

Like I said in my initial post, the point is to have two workflow servers with a different (non overlapping) sets of workflows. One set would include high priority workflows in the sense their execution has to be dispatched without intefering (see below) with the other servers's lower priority workflows.

If the workflow subscriber remains centralized when there is more than one workflow server, there will be no time gain as far as workflow subscription (evaluating both low and high priority starting rules)  is concerned.

On the other side if each server runs its own subscriber (I mean evaluate only the starting rules of their workflow subset), that means that dispatching high priority workflows will not be affected (time wise) by lower priority workflows' starting rules.

Can you please tell me which (if any ;-) scenario prevails ? Or maybe I'm missing an architectural point ?

0 0
APPROVED ANSWER
replied on November 12, 2015

The Subscriber can only connect to one Workflow Server. So if you want to have 2 servers, you will need 2 Subscribers as well. There is no way to have a single WF Subscriber direct work to multiple servers at this time.

Like Chris said, making sure that rules are not overlapping is very important in this setup since both subscribers would be reading the same activity log. Each would be checking against its own set of starting rules, but that doesn't mean an event can't satisfy a starting rule on both servers at the same time.

Troubleshooting may also be a bit complicated since you would have to double-check both servers to make sure there wasn't a conflict when one of your documents is not routed as expected.

Activity generated in the repository by Workflow Server A may still impact starting rule processing on Workflow Server B.

1 0
SELECTED ANSWER
replied on November 12, 2015

Thank you Miruna !

I will define two virtual machines dedicated to workflows, each one running its own set of services (Laserfiche Workflow and Laserfiche Workflow Subscriber) as well as its own SQL database.

Stéphane

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...