Scaling out Workflow Manager 1.0

  • Article

 

Updated: August 15, 2012

Workflow Manager 1.0 supports scale-out architecture. Scaling from a single machine to a multimachine configuration can be used to create High Availability (HA) and to achieve increased performance and throughput.

Scaling out Workflow Manager 1.0

Scaling out Workflow Manager 1.0 can be as simple as installing Workflow Manager 1.0 or an additional server and then joining the server to an existing farm. See Installing and Configuring.

You don’t need to change your workflows to take advantage of Workflow Manager 1.0 scale-out topology. You also don’t need to worry about how the execution of workflows is distributed between servers in the farm. All Workflow Manager 1.0 servers that joined the farm use efficient algorithms to process workflow instances with pending work.

Similarly, Workflow Manager Client 1.0 API and REST API can be used to interact with each server in the farm. The servers should be configured with a software or hardware load balancer for proper load balancing, or can be accessed directly.

Depending on the usage and load characteristics, the performance of Workflow Manager 1.0 can be bound by various factors, including the following.

  • CPU use by Workflow Manager Client 1.0 or Service Bus services.

  • CPU use by SQL Server.

  • SQL Server I/O.

  • Network characteristics.

If Workflow Manager Client 1.0 performance is bound by CPU consumed by Workflow or Service Bus services, then adding additional nodes to the farm can address the bottleneck.

If Workflow Manager 1.0 performance is bound by SQL Server, then you should consider optimizing your SQL Server deployment first. This process may include specifying larger file sizes for the databases, allocating separate disks to various databases and database log files used by Workflow Manager 1.0 and Service Bus, and using a separate SQL Server for Workflow databases and Service Bus databases.