Changing Server Configuration Settings

 

Updated: October 5, 2012

Follow these steps to change a server configuration setting using PowerShell.

Changing Server Configuration Settings using Windows PowerShell

1. Open the Workflow PowerShell command window.

   Note

   For instructions on opening the Workflow PowerShell window, see Configuring Workflow Manager 1.0 using PowerShell.

2. Execute the T:Microsoft.Workflow.Commands.Set-WFServiceConfiguration cmdlet with the following parameters:

   1. For P:Microsoft.Workflow.Commands.Set-WFServiceConfiguration.ServiceUri, specify the URI of the workflow server. For example, https://myserver.mydomain.mycompany.com:12290.

   2. For P:Microsoft.Workflow.Commands.Set-WFServiceConfiguration.Name, specify a name of the configuration setting (See below for the list of valid settings.)

   3. For P:Microsoft.Workflow.Commands.Set-WFServiceConfiguration.Value, specify the new configuration value.

   Note

   Changing the default value of any configuration setting may impact the ability to run your solution in a shared hosting environment, or with a future version of the product delivered as a managed service.

Valid Server Configuration Settings

Configuration Setting Name	Default Value	Description
ServiceBusMaxTopicSizeInMegabytes	6144	The size of Service Bus topics created by Workflow Manager 1.0. You may want to reduce this setting if you want to limit the database storage used by each Scope. You may want to increase this setting if you want to have Scopes that contain very large number of workflow instances and/or very large workflow instances.This value should be significantly larger than the value of ServiceBusTopicSizeQuotaInBytes divided by 1,048,576.
ServiceBusTopicSizeQuotaInBytes	5368709120	Workflows in any given Scope may be unable to make progress if there is not enough space left in the underlying Service Bus topic. To help prevent this, Workflow Manager 1.0 uses a threshold defined by ServiceBusTopicSizeQuotaInBytes. When a given topic size exceeds this threshold, attempts to PublishNotification to the corresponding Scope may throw an exception. The value of ServiceBusTopicSizeQuotaInBytes should be significantly smaller than the value of ServiceBusTopicSizeQuotaInBytes multiplied by 1,048,576 to provide sufficient buffer.
WorkflowServiceAllowUnsafeTypes	False	See Defining and using custom code activities and types in a workflow.
WorkflowServiceMaxActivityXamlSizeInBytes	5242880	The size limit of a single declarative activity. You may want to increase this limit in order to publish an activity that is larger than 5MB. You may want to reduce this limit if you don’t want your users to publish large activities. This may reduce memory consumption and database disk usage.
WorkflowServiceMaxAllocationsPerBatchKB	102400	The limit of the memory allocated by a workflow instance. The quota resets each time the workflow is persisted, for example, if it waits for a message or waits on a timer. An InsufficentMemoryException will be thrown if a workflow instance attempts to allocate more memory than this limit. You may want to increase this limit if you want to allow any activity to allocate more memory. However, this will impact the memory available to other workflow instances executing at the same time. You may want to reduce this limit if you want to further limit the amount of memory that workflow instances can allocate. This may reduce memory pressure on the server.
WorkflowServiceMaxHttpResponseTime	0:01:00	The amount of time represented as hours:minutes:seconds that defines the response timeout when workflows make Http requests. You may want to increase this limit if workflows send requests to an endpoint that responds after more than 1 minute. Note:  Workflow Manager 1.0 can concurrently process a fixed number of workflow instances (see WorkflowServiceMaxLoadedInstances) on each server node. You can think about this as each server having a fixed number of workflow execution pipelines. Any workflow instance loaded in memory, including a workflow instance waiting for HTTP response within the configured timeout, uses one of these pipelines. Therefore, increasing WorkflowServiceMaxHttpResponseTime may reduce the cumulative throughput, especially if many workflow instances spend a lot of time waiting on HTTP response.
WorkflowServiceMaxHttpRetryDelay	5.00:00:00	Workflow Manager 1.0 uses an exponential back-off policy when retrying Http requests made from workflows instances. For example, the first retry may be delayed by additional 2 seconds (on top of the default delay), the second retry may be delayed by an additional 4 seconds; the third retry may be delayed by additional 8 seconds and so on. If this algorithm were unbound it would eventually lead to very long delays between retry attempts. Workflow Manager 1.0 allows you to control the maximum additional delay between retry attempts. This is represented by the WorkflowServiceMaxHttpRetryDelay configuration setting.
WorkflowServiceMaxHttpRetryTotalTime	10.00:00:00	This setting defines the total amount of time spent on retrying an unsuccessful HTTP request made from a workflow instance.
WorkflowServiceMaxInstanceSizeKB	5120	The maximum allowed size for a persisted workflow instance. You may want to reduce this setting if you want to limit the database storage used by workflow instances. You may want to increase this setting if you want to support very large workflow instances.
WorkflowServiceMaxLoadedInstances	50	The number of concurrent workflow instances that can be processed at the same time on a single server node. This setting may be adjusted depending on the available memory and computing power, as well as desired throughput and the characteristics of the workflows.
WorkflowServiceMaxPendingIOPerInstance	5	The quota of I/O operations that each instance gets before it is hydrated to give a chance for other pending workflow instances to execute. This setting may be adjusted depending on the characteristics of the workflows. For example, if workflow instances tend to be large and make many simple HTTP requests, then the overhead of loading the instances and then reloading them may be larger than the benefit of providing more fairness to other workflow instances. In such a case, this setting can be increased.
WorkflowServiceMaxWorkflowXamlSizeInBytes	52428800	The aggregate size limit of a full activity closure that includes all declarative activities used by a workflow. You may want to increase this limit in order to enable huge workflows, but this may have memory usage and performance implications. You may want to reduce this limit if you don’t want your users to publish huge workflows. Reducing this limit may help with reducing memory consumption and database disk usage.