Windows workflow foundation version 3.0.4

A snippet of the workflow is shown below. To exercise nesting in an extreme case, another workflow that is part of this test uses nested sequences. In the innermost sequence is a single Comment or CodeActivity. Even with complex workflows with lots of depth and a high number of activities, the performance results are consistent with other throughput numbers shown earlier in this article.

The memory overhead of Windows Workflow Foundation is measured in two key areas: workflow complexity and number of workflow definitions. Memory measurements were taken on a Windows 7 bit workstation. There are many ways to obtain the measurement of working set size such as monitoring performance counters, polling Environment.

A combination of methods was used to obtain and verify the results of each test. The workflow complexity test measures the working set difference based on the complexity of the workflow.

In addition to the complex workflows used in the previous section, new variations are added to cover two basic cases: a single activity workflow and a sequence with activities. For these tests the workflows are initialized and executed to completion in a single serial loop for a period of one minute. Each test variation is run three times and the data recorded is the average of those three runs.

In the WF3 workflow shown above, empty CodeActivity activities are used. The WF4 workflow above uses Comment activities. The Comment activity was described in the Component-level Performance Comparisons section earlier in this article. One of the clear trends to notice in this graph is that nesting has relatively minimal impact on memory usage in both WF3 and WF4.

The most significant memory impact comes from the number of activities in a given workflow. Given the data from the sequence , complex depth 5 sequence 5, and complex depth 7 sequence 1 variations, it is clear that as the number of activities enters the thousands, the memory usage increase becomes more noticeable.

Measuring memory per workflow definition is divided into two different tests because of the available options for hosting workflows in WF3 and WF4. The tests are run in a different manner than the workflow complexity test in that a given workflow is instanced and executed only once per definition.

This is because the workflow definition and its host remain in memory for the lifetime of the AppDomain. The memory used by running a given workflow instance should be cleaned up during garbage collection. The migration guidance for WF4 contains more detailed information on the hosting options. Creating many workflow definitions for a workflow definition test can be done in several ways.

For instance, one could use code generation to create a set of workflows that are identical except in name and save each of those workflows into separate files. This approach was taken for the console-hosted test. In WF3, the WorkflowRuntime class was used to run the workflow definitions. WF4 can either use WorkflowApplication to create a single workflow instance or directly use WorkflowInvoker to run the activity as if it were a method call. WorkflowApplication is a host of a single workflow instance and has closer feature parity to WorkflowRuntime so that was used in this test.

The VirtualPathProvider handles the incoming request and responds with a "virtual file" that can be loaded from a database or, in this case, generated on the fly. It is therefore unnecessary to create physical files. The workflow definitions used in the console test were simple sequential workflows with a single activity.

The IIS-hosted case used workflows that start on receiving a message and end on sending a reply:. The following table shows the delta in working set between a single workflow definition and definitions:. Hosting workflow definitions in IIS consumes much more memory due to the WorkflowServiceHost , detailed WCF service artifacts, and the message processing logic associated with the host.

The XAML is stored as an embedded resource in the assembly and compiled during runtime to provide the implementation of the workflow. There is some overhead associated with this process. An example of one of the WF4 workflows is shown below:. There are many other factors that can affect memory consumption.

The same advice for all managed programs still applies. In IIS-hosted environments, the WorkflowServiceHost object created for a workflow definition stays in memory until the application pool is recycled.

This should be kept in mind when writing extensions. Also, it is best to avoid "global" variables variables scoped to the whole workflow and limit the scope of variables wherever possible. The WF3 SQL persistence provider is a simple implementation that serializes the workflow instance and stores it in a blob. For this reason, the performance of this provider depends heavily on the size of the workflow instance.

In WF3, the instance size could increase for many reasons, as is discussed previously in this paper. Many customers choose not to use the default SQL persistence provider because storing a serialized instance in a database gives no visibility into the state of the workflow.

In order to find a particular workflow without knowing the workflow id, one would have to deserialize each persisted instance and examine the contents. Many developers prefer to write their own persistence providers to overcome this obstacle. The persistence tables expose certain information such as the active bookmarks and promotable properties. The new content-based correlation feature in WF4 would not perform well using the WF3 SQL persistence approach, which has driven some change in the organization of the persisted workflow instance.

This makes the job of the persistence provider more complex and puts extra stress on the database. Even with an improved feature set and better concurrency handling, the SQL persistence provider in WF4 is faster than the provider in WF3. To showcase this, two workflows that perform essentially the same operations in WF3 and WF4 are compared below.

The two workflows are both created by a received message. After sending an initial reply, the workflow is persisted. The same could be achieved in WF3 by marking an activity as "persist on close. The workflows are persisted but not unloaded. The TCP transport increases that factor to 3.

The reason that WF4 throughput is greater is due to the faster workflow runtime. The size of the serialized instance is low for both cases and is not a major contributing element in this situation.

Both the WF3 and WF4 workflows in this test use an activity to explicitly indicate when persistence should occur. This has the benefit of persisting the workflow without unloading it. In WF3, it is also possible to persist using the TimeToUnload feature, but this unloads the workflow instance from memory. If a developer using WF3 wants to make sure a workflow persists at certain points, they either have to alter the workflow definition or pay the cost for unloading and re-loading the workflow instance.

This feature allows the workflow instance to be persisted on idle but stay in memory until the TimeToUnload threshold is met or execution is resumed. Be sure to include the following performance counters from the SQL database when performance testing workflow applications:.

Workflow tracking can be used to track the progress of a workflow. The information that is included in the tracking events is determined by a tracking profile. The more complex the tracking profile, the more expensive tracking becomes. WF3 shipped with a SQL-based tracking service. This service could work in batched and non-batched modes. In non-batched mode, tracking events are written directly to the database.

In batched mode, tracking events are collected into the same batch as the workflow instance state. The batched mode has the best performance for the widest range of workflow designs. However, batching can have a negative performance impact if the workflow runs many activities without persisting and those activities are tracked.

This would commonly happen in loops and the best way to avoid this scenario is to design large loops to contain a persistence point. Introducing a persistence point into a loop can negatively affect performance as well so it is important to measure the costs of each and come up with a balance.

WF4 is not shipped with a SQL tracking service. Recording tracking information to a SQL database can be handled better from an application server rather than built into the. ETW is a kernel-level, low-latency event system built into Windows. In addition to kernel events such as processor, disk, memory, and network usage, many applications leverage ETW as well. ETW events are more powerful than performance counters in that events can be customized to the application. An event can contain text such as a workflow ID or an informational message.

Also, events are categorized with bitmasks so that consuming a certain subset of events will have less performance impact than capturing all events. Collection of tracking events can be separated to another process. This gives greater flexibility in how the events are recorded.

The performance benefits to ETW tracking come with a drawback. ETW events can be lost if the system is under intense resource pressure. The processing of events is not meant to block normal program execution and therefore it is not guaranteed that all ETW events will be broadcast to their subscribers.

This makes ETW tracking great for health monitoring but not suitable for auditing. A separate job drains the data from this table and reforms it into reporting tables that can be viewed on the AppFabric dashboard.

This means that a batch of tracking events is handled independent of the workflow it came from and therefore does not have to wait for a persistence point before being recorded. ETW events can be recorded with tools such as logman or xperf.

The compact ETL file can be viewed with a tool like xperfview or converted to a more readable format, such as XML, with tracerpt. In WF3, the only option for getting tracking events without a SQL database is to create a custom tracking service. Enabling workflow tracking will impact performance in varying degrees. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services. Privacy policy. Guide to the Windows Workflow Documentation A set of suggested topics to read, depending upon your familiarity novice to well-acquainted , and requirements.

What's New in Windows Workflow Foundation Discusses the changes in several development paradigms from previous versions. What's New in Windows Workflow Foundation in. NET Framework 4. Total Size: 0. Back Next. Microsoft recommends you install a download manager.

Microsoft Download Manager. Manage all your internet downloads with this easy-to-use manager. It features a simple interface with many customizable options:.

Download multiple files at one time Download large files quickly and reliably Suspend active downloads and resume downloads that have failed. Yes, install Microsoft Download Manager recommended No, thanks. What happens if I don't install a download manager? Why should I install the Microsoft Download Manager?

In this case, you will have to download the files individually. You would have the opportunity to download individual files on the "Thank you for downloading" page after completing your download.

Files larger than 1 GB may take much longer to download and might not download correctly. You might not be able to pause the active downloads or resume downloads that have failed. Includes Windows PowerShell 3.