Производительность Windows Workflow Foundation 4

.NET Framework 4 включает основную редакцию Windows Workflow Foundation (WF) с большими инвестициями в производительность. Эта новая редакция содержит значительные изменения в проектировании предыдущих версий WF, которые были отправлены в составе .NET Framework 3.0 и .NET Framework 3.5. Он был перепроектирован из ядра модели программирования, среды выполнения и инструментов для повышения производительности и удобства использования. В этом разделе показаны важные характеристики производительности этих редакций и сравниваются с предыдущими версиями.

Производительность отдельных компонентов рабочего процесса увеличилась на порядки величин между WF3 и WF4. Это оставляет разрыв между вручную кодируемыми службами Windows Communication Foundation (WCF) и службами рабочих процессов WCF довольно небольшим. Задержка рабочего процесса значительно сократилась в WF4. Производительность сохраняемости увеличилась на коэффициент 2,5 – 3,0. Мониторинг работоспособности с помощью отслеживания рабочих процессов значительно снижает затраты. Это убедительные причины для перехода на WF4 или его внедрения в ваших приложениях.

Терминология

Версия WF, представленная в .NET Framework 4, будет называться WF4 для остальной части этого раздела. WF был введён в .NET Framework 3.0 и претерпел несколько незначительных изменений через .NET Framework 3.5 SP1. Версия .NET Framework 3.5 Workflow Foundation будет называться WF3 для остальной части этого раздела. WF3 поставляется в .NET Framework 4 параллельно с WF4. Дополнительные сведения о переносе артефактов WF3 в WF4 см. в руководстве по миграции Windows Workflow Foundation 4.

Windows Communication Foundation (WCF) — это единая модель программирования Майкрософт для создания приложений, ориентированных на обслуживание. Он впервые появился в составе .NET Framework 3.0 вместе с WF3 и теперь является одним из ключевых компонентов .NET Framework.

Windows Server AppFabric — это набор интегрированных технологий, которые упрощают создание, масштабирование и управление веб-приложениями и композитными приложениями, работающими в службах IIS. Он предоставляет средства для мониторинга и управления службами и рабочими процессами. Дополнительные сведения см. в разделе Windows Server AppFabric 1.0.

Цели

Цель этого раздела — показать характеристики производительности WF4 с данными, измеряемыми для различных сценариев. Он также предоставляет подробные сравнения между WF4 и WF3, и таким образом показывает большие улучшения, которые были сделаны в этой новой редакции. Сценарии и данные, представленные в этой статье, квалифицируют базовые затраты различных аспектов WF4 и WF3. Эти данные полезны для понимания характеристик производительности WF4 и могут быть полезны при планировании миграции с WF3 на WF4 или в использовании WF4 в разработке приложений. Однако при вынесении выводов из данных, представленных в этой статье, следует проявлять осторожность. Производительность составного приложения рабочего процесса сильно зависит от того, как реализуется рабочий процесс и как интегрированы различные компоненты. Необходимо измерять каждое приложение, чтобы определить характеристики производительности этого приложения.

Обзор улучшений производительности WF4

WF4 тщательно разработан и реализован с высокой производительностью и масштабируемостью, описанными в следующих разделах.

Среда выполнения WF

В основе среды выполнения WF является асинхронный планировщик, который управляет выполнением действий в рабочем процессе. Он предоставляет высокопроизводительную и прогнозируемую среду выполнения для операций. Среда имеет четко определенный контракт для выполнения, продолжения, завершения, отмены, исключений и прогнозируемой модели многопоточности.

По сравнению с WF3 среда выполнения WF4 имеет более эффективный планировщик. Он использует тот же пул потоков ввода-вывода, который используется для WCF, что очень эффективно при выполнении пакетных рабочих элементов. Очередь планировщика внутренних рабочих элементов оптимизирована для наиболее распространенных шаблонов использования. Среда выполнения WF4 также управляет состояниями выполнения очень легковесно с минимальной логикой для синхронизации и обработки событий, в то время как WF3 зависит от тяжеловесной регистрации и вызова событий для обеспечения сложной синхронизации при переходах состояний.

Хранилище данных и поток

В WF3 данные, связанные с действием, моделироваются с помощью свойств зависимостей, реализованных типом DependencyProperty. Шаблон свойства зависимостей появился в Windows Presentation Foundation (WPF). Как правило, этот шаблон очень гибкий для поддержки простой привязки данных и других функций пользовательского интерфейса. Однако шаблон требует, чтобы свойства были определены как статические поля в определении рабочего процесса. Всякий раз, когда WF runtime задает или получает значения свойств, это связано с тяжеловесной логикой поиска.

WF4 использует четкую логику области данных для значительного улучшения обработки данных в рабочем процессе. Он отделяет данные, хранящиеся в действии, от данных, которые распространяются через границы действия с помощью двух различных понятий: переменных и аргументов. С помощью четкой иерархической области для переменных и аргументов "In/Out/InOut" сложность использования данных для действий значительно уменьшается, а время существования данных также автоматически ограничивается. Действия имеют четкий образ, определяемый их аргументами. Просто изучив действие, можно определить, какие данные оно ожидает получать и какие данные будут создаваться в результате его выполнения.

При создании рабочего процесса в WF3 действия были инициализированы. В WF 4 активности инициализируются только во время выполнения соответствующих активностей. Это упрощает жизненный цикл действий путем устранения операций инициализации при создании каждого нового экземпляра рабочего процесса, что позволяет повысить эффективность работы.

Управление потоком

Как и в любом языке программирования, WF обеспечивает поддержку потоков управления для определений рабочих процессов, вводя набор действий потока управления для последовательности, циклов, ветвления и других шаблонов. В WF3, когда одно и то же действие необходимо выполнить повторно, создается новый ActivityExecutionContext, и действие клонируется с помощью тяжеловесной логики сериализации и десериализации, основанной на BinaryFormatter. Обычно производительность итеративных потоков управления значительно медленнее, чем выполнение последовательности действий.

WF4 обрабатывает это совершенно по-другому. Он принимает шаблон действия, создает новый объект ActivityInstance и добавляет его в очередь планировщика. Весь процесс включает только явное создание объектов и является очень легковесным.

Асинхронное программирование

Приложения обычно имеют более высокую производительность и масштабируемость с асинхронным программированием для длительных блокирующих операций, таких как операции ввода-вывода или распределенные вычислительные операции. WF4 обеспечивает поддержку асинхронных операций с помощью базовых типов действий AsyncCodeActivity, AsyncCodeActivity<TResult>. Среда выполнения изначально понимает асинхронные действия и, следовательно, может автоматически помещать экземпляр в зону без сохранения состояния, пока асинхронная работа выполняется. Пользовательские действия могут быть производными от этих типов для выполнения асинхронной работы, не удерживая поток планировщика рабочих процессов и не блокируя любые действия, которые могут выполняться параллельно.

Обмен сообщениями

Первоначально WF3 поддерживала очень ограниченную поддержку обмена сообщениями через внешние события или вызовы веб-служб. В .NET Framework 3.5 рабочие процессы могут быть реализованы как клиенты WCF или предоставляться как службы WCF через SendActivity и ReceiveActivity. В WF4 концепция программирования обмена сообщениями на основе рабочих процессов была усилена путем тесной интеграции логики обмена сообщениями WCF с WF.

Единый конвейер обработки сообщений, предоставляемый в WCF в .NET 4, помогает службам WF4 значительно повысить производительность и масштабируемость, чем WF3. WF4 также предоставляет более широкие возможности программирования для обмена сообщениями, которые могут моделировать сложные шаблоны Обмена сообщениями (MEPS). Разработчики могут использовать типизированные контракты служб для упрощения программирования или нетипизированного контракта службы для повышения производительности без оплаты затрат на сериализацию. Поддержка кэширования каналов на стороне клиента с использованием класса SendMessageChannelCache в WF4 помогает разработчикам создавать быстрые приложения с минимальными усилиями. В разделе "Изменение уровней общего доступа кэша для действий отправки" см. дополнительные сведения.

Декларативное программирование

WF4 предоставляет чистую и простую декларативную платформу программирования для моделирования бизнес-процессов и служб. Модель программирования поддерживает полностью декларативную композицию действий без кода рядом, что значительно упрощает разработку рабочих процессов. В .NET Framework 4 декларативная платформа программирования на основе XAML была унифицирована в единой сборке System.Xaml.dll для поддержки WPF и WF.

В WF4 XAML предоставляет действительно декларативный интерфейс и позволяет определить весь рабочий процесс в разметке XML, ссылаясь на действия и типы, созданные с помощью .NET. Это было сложно сделать в WF3 с форматом XOML без использования пользовательской логики программирования. Новый стек XAML в .NET 4 имеет гораздо более высокую производительность при сериализации и десериализации артефактов рабочих процессов и делает декларативное программирование более привлекательным и твердым.

Конструктор рабочих процессов

Полностью декларативная поддержка программирования для WF4 явно накладывает более высокие требования к производительности времени разработки для больших рабочих процессов. Конструктор рабочих процессов в WF4 имеет гораздо лучшую масштабируемость для больших рабочих процессов, чем для WF3. Благодаря поддержке виртуализации пользовательского интерфейса конструктор может легко загрузить большой рабочий процесс из 1000 действий за несколько секунд, в то время как практически невозможно загрузить рабочий процесс из нескольких сотен действий с помощью конструктора WF3.

Сравнение производительности на уровне компонентов

В этом разделе содержатся данные о прямых сравнениях отдельных действий в рабочих процессах WF3 и WF4. Ключевые области, такие как сохраняемость, оказывают более глубокое влияние на производительность, чем отдельные компоненты активности. Улучшения производительности отдельных компонентов в WF4 важны потому что компоненты теперь достаточно быстры, чтобы их можно было сравнить с логикой оркестрации, закодированной вручную. Пример будет рассмотрен в следующем разделе: "Сценарий составления сервиса".

Настройка среды

На приведенном выше рисунке показана конфигурация компьютера, используемая для измерения производительности на уровне компонентов. Один сервер и пять клиентов, подключенных через один сетевой интерфейс Ethernet с 1 Гбит/с. Для простых измерений сервер настроен на использование одного ядра двухпрокционного или четырехядерных сервера под управлением Windows Server 2008 x86. Использование ЦП системы поддерживается почти на уровне 100%.

Сведения о тестировании

WF3 CodeActivity скорее всего, является самым простым действием, которое можно использовать в рабочем процессе WF3. Действие вызывает метод в коде программной части, в которую программист рабочего процесса может поместить пользовательский код. В WF4 нет прямого аналога WF3 CodeActivity , который предоставляет те же функции. Обратите внимание, что в WF4 существует базовый CodeActivity класс, который не связан с WF3 CodeActivity. Авторам рабочих процессов рекомендуется создавать настраиваемые действия и разрабатывать рабочие процессы исключительно на XAML. В приведенных ниже тестах в рабочих процессах WF4 используется действие Comment вместо пустого действия CodeActivity. Код в Comment действии выглядит следующим образом:

[ContentProperty("Body")]
    public sealed class Comment : CodeActivity
    {
        public Comment()
            : base()
        {
        }

        [DefaultValue(null)]
        public Activity Body
        {
            get;
            set;
        }

        protected override void Execute(CodeActivityContext context)
        {
        }
    }

Пустой рабочий процесс

Этот тест использует рабочий процесс последовательности без дочерних активностей.

Одно действие

Рабочий процесс — это рабочий процесс последовательности, содержащий одно дочернее действие. Деятельность — это CodeActivity без кода в случае WF3 и активность Comment в случае WF4.

При 1000 итерациях

Рабочий процесс последовательности содержит одно While действие с одной дочерней активностью в цикле, которая не выполняет никакой работы.

Репликатор по сравнению с ParallelForEach

ReplicatorActivity в WF3 имеет последовательные и параллельные режимы выполнения. В последовательном режиме производительность действия аналогична WhileActivity. ReplicatorActivity наиболее полезен для параллельного выполнения. Аналогом WF4 для этого является действие ParallelForEach<T>.

На следующей схеме показаны рабочие процессы, используемые для этого теста. Рабочий процесс WF3 находится слева, а рабочий процесс WF4 находится справа.

Последовательный рабочий процесс с пятью действиями

Этот тест предназначен для отображения эффекта выполнения нескольких действий в последовательности. В последовательности есть пять действий.

Область транзакций

Тест области транзакций отличается от других тестов немного в том, что новый экземпляр рабочего процесса не создается для каждой итерации. Вместо этого рабочий процесс структурирован с циклом времени, содержащим TransactionScope действие, содержащее одно действие, которое не работает. Каждое выполнение серии из 50 итераций в цикле while считается одной операцией.

Компенсация

Рабочий процесс WF3 имеет одно компенсируемое действие с именем WorkScope. Действие просто реализует ICompensatableActivity интерфейс:

class WorkScope :
        CompositeActivity, ICompensatableActivity
    {
        public WorkScope() : base() { }

        public WorkScope(string name)
        {
            this.Name = name;
        }

        public ActivityExecutionStatus Compensate(
            ActivityExecutionContext executionContext)
        {
            return ActivityExecutionStatus.Closed;
        }
    }

Обработчик сбоя предназначен для WorkScope действия. Рабочий процесс WF4 также упрощен. CompensableActivity имеет тело и обработчик компенсации. Явная компенсация будет следующей в последовательности. Активность тела и активность обработчика компенсации являются пустыми реализациями.

public sealed class CompensableActivityEmptyCompensation : CodeActivity
    {
        public CompensableActivityEmptyCompensation()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }
    public sealed class CompensableActivityEmptyBody : CodeActivity
    {
        public CompensableActivityEmptyBody()
            : base() { }

        public Activity Body { get; set; }

        protected override void Execute(CodeActivityContext context) { }
    }

На следующей схеме показан базовый рабочий процесс компенсации. Рабочий процесс WF3 находится слева, а рабочий процесс WF4 находится справа.

Результаты теста производительности

Все тесты измеряются в рабочих процессах в секунду за исключением теста области транзакций. Как видно выше, производительность среды выполнения WF улучшилась в целом, особенно в областях, требующих многократного выполнения одного и того же действия, как оператор цикла while.

Сценарий композиции сервисов

Как показано в предыдущем разделе "Сравнение производительности на уровне компонентов", в WF3 и WF4 произошло значительное сокращение затрат. Службы рабочих процессов WCF теперь почти соответствуют производительности закодированных служб WCF, но по-прежнему имеют все преимущества среды выполнения WF. Этот тестовый сценарий сравнивает службу WCF с службой рабочего процесса WCF в WF4.

Служба Интернет-магазина

Одним из преимуществ Windows Workflow Foundation является возможность создания процессов с помощью нескольких служб. В этом примере существует служба интернет-магазина, которая управляет двумя вызовами служб для покупки заказа. Первым шагом является проверка заказа с помощью службы проверки заказа. Второй шаг — заполнить заказ с помощью службы хранилища.

Две службы на стороне сервера, служба проверки заказов и служба складского учёта, остаются неизменными для обоих тестов. Изменяющаяся часть — это служба интернет-магазина, выполняющая оркестрацию. В одном случае служба написана вручную как WCF-сервис. В другом случае служба записывается как служба рабочего процесса WCF в WF4. Функции WF, такие как отслеживание и сохраняемость, для данного теста отключены.

Окружающая среда

Клиентские запросы отправляются в Интернет-магазин через HTTP с нескольких компьютеров. На одном компьютере размещаются все три службы. Транспортный уровень между службой Интернет-магазина и внутренними службами — TCP или HTTP. Измерение операций в секунду основано на количестве завершенных PurchaseOrder вызовов, выполненных в службу Интернет-магазина. Пул каналов — это новая функция, доступная в WF4. В части WCF этого теста пул каналов не предоставляется по умолчанию, поэтому в службе Интернет-магазина использовалась вручную закодированная реализация простого метода пуллинга.

Производительность

Служба WF при подключении к серверным службам TCP без пула каналов оказывает 17.2% влияние на пропускную способность. С пулом каналов штраф составляет около 23,8%. Для HTTP влияние гораздо меньше: 4.3% без пула и 8.1% с пулом. Важно также отметить, что пул каналов обеспечивает очень мало преимуществ при использовании HTTP.

Несмотря на то, что в этом тесте есть издержки от среды выполнения WF4 по сравнению со службой WCF, закодируемой вручную, это может считаться худшим сценарием. Две внутренние службы в этом тесте выполняют очень мало работы. В реальном комплексном сценарии эти службы будут выполнять более дорогие операции, такие как вызовы баз данных, что делает влияние на производительность транспортного слоя менее важным. Это плюс преимущества функций, доступных в WF4, делает Workflow Foundation жизнеспособным выбором для создания служб оркестрации.

Основные рекомендации по производительности

Области возможностей в этом разделе, за исключением взаимодействия, резко изменились в версиях WF3 и WF4. Это влияет на проектирование приложений рабочих процессов, а также производительность.

Задержка активации рабочего процесса

В приложении службы рабочих процессов WCF задержка запуска нового рабочего процесса или загрузки существующего рабочего процесса важна, так как она может быть заблокирована. Этот тестовый случай сравнивает хост WF3 XOML с хостом WF4 XAMLX в типичном сценарии.

Настройка среды

Испытательная установка

В сценарии клиентский компьютер обращается к службе рабочего процесса WCF с помощью корреляции на основе контекста. Корреляция контекста требует специальной привязки контекста и использует заголовок контекста или файл cookie для связи сообщений с правильным экземпляром рабочего процесса. Он имеет преимущество производительности, что идентификатор корреляции находится в заголовке сообщения, поэтому текст сообщения не должен быть проанализирован.

Служба создаст рабочий процесс с запросом и отправит немедленный ответ, чтобы измерение задержки не включало время, затраченное на выполнение рабочего процесса. Рабочий процесс WF3 — это XOML с отдельным кодом, а рабочий процесс WF4 полностью выполнен на XAML. Рабочий процесс WF4 выглядит следующим образом:

Действие Receive создает экземпляр рабочего процесса. Значение, переданное в полученном сообщении, передается в ответном сообщении. Последовательность после ответа содержит остальную часть рабочего процесса. В приведенном выше случае отображается только одно действие комментария. Количество активности комментариев изменено для имитации сложности рабочего процесса. Комментарий эквивалентен WF3 CodeActivity, которое не выполняет никакой работы. Дополнительные сведения о действии комментариев см. в разделе "Сравнение производительности на уровне компонентов" ранее в этой статье.

Результаты теста

Холодная и теплая задержка для служб рабочих процессов WCF:

На предыдущей диаграмме термин "пустой" используется для обозначения ситуации, когда для данного рабочего процесса отсутствует существующий WorkflowServiceHost. Другими словами, холодная задержка заключается в том, что рабочий процесс используется в первый раз, а XOML или XAML необходимо скомпилировать. Теплая задержка — это время создания нового экземпляра рабочего процесса, когда тип рабочего процесса уже скомпилирован. Сложность рабочего процесса имеет очень мало различий в случае WF4, но имеет линейную прогрессию в случае WF3.

Пропускная способность корреляции

WF4 представляет новую функцию корреляции на основе содержимого. WF3 предоставляет только корреляцию на основе контекста. Корреляция на основе контекста может выполняться только через определенные привязки каналов WCF. Идентификатор рабочего процесса вставляется в заголовок сообщения при использовании этих привязок. Среда выполнения WF3 может определить рабочий процесс только по идентификатору. С помощью корреляции на основе содержимого автор рабочего процесса может создать ключ корреляции из соответствующего фрагмента данных, таких как номер учетной записи или идентификатор клиента.

Корреляция на основе контекста имеет преимущество производительности в том, что ключ корреляции расположен в заголовке сообщения. Ключ можно считывать из сообщения без десериализации или копирования сообщений. В корреляции на основе содержимого ключ корреляции хранится в тексте сообщения. Выражение XPath используется для поиска ключа. Стоимость этой дополнительной обработки зависит от размера сообщения, глубины ключа в тексте и количества ключей. Этот тест сравнивает корреляцию на основе контекста и содержимого, а также показывает снижение производительности при использовании нескольких ключей.

Настройка среды

Испытательная установка

Предыдущий рабочий процесс используется в разделе сохраняемости . Для тестов корреляции без сохраняемости в среде выполнения нет поставщика сохраняемости. Корреляция происходит в двух местах: CreateOrder и CompleteOrder.

Результаты теста

На этом графике показано снижение производительности по мере увеличения числа ключей, используемых в корреляции на основе содержимого. Сходство кривых между TCP и HTTP указывает на затраты, связанные с этими протоколами.

Корреляция с сохраняемостью

При сохранении рабочего процесса нагрузка ЦП от корреляции на основе содержимого перемещается из среды выполнения рабочего процесса в базу данных SQL. Хранимые процедуры в поставщике сохраняемости SQL выполняют работу сопоставления ключей, чтобы найти соответствующий рабочий процесс.

Корреляция на основе контекста по-прежнему быстрее, чем корреляция на основе содержимого. Однако разница менее выражена, так как сохраняемость оказывает больше влияния на производительность, чем корреляция.

Сложная пропускная способность рабочего процесса

Сложность рабочего процесса измеряется не только по количеству действий. Составные действия могут содержать множество дочерних элементов, а эти дочерние элементы также могут быть составными действиями. По мере увеличения числа уровней вложенности увеличивается и количество действий, которые могут находиться в состоянии выполнения, и количество переменных, которые могут находиться в состоянии. Этот тест сравнивает пропускную способность между WF3 и WF4 при выполнении сложных рабочих процессов.

Испытательная установка

Эти тесты были выполнены на компьютере Intel Xeon X5355 @ 2,66GГц 4-путь с 4 ГБ ОЗУ под управлением Windows Server 2008 x64. Тестовый код выполняется в одном процессе с одним потоком на ядро, чтобы достичь 100% использования ЦП по%.

Рабочие процессы, созданные для этого теста, имеют две основные переменные: глубину и количество действий в каждой последовательности. Каждый уровень глубины включает параллельное действие, цикл с условием, решения, назначения и последовательности. На рисунке ниже в конструкторе WF4 показана блок-схема верхнего уровня. Каждое действие блок-схемы напоминает основную блок-схему. При воображении этого рабочего процесса может быть полезно подумать о фрактале, где глубина ограничена параметрами теста.

Количество действий в заданном тесте определяется глубиной и количеством действий на последовательность. Следующее уравнение вычисляет количество действий в тесте WF4:

Количество действий теста WF3 можно вычислить с помощью немного другого уравнения из-за дополнительной последовательности:

Где d — глубина, а a — количество действий в последовательности. Логика этих уравнений заключается в том, что первая константа, умноженная на a, является числом последовательностей, а вторая константой является статическое число действий в текущем уровне. В каждой блок-схеме есть три дочерних действия блок-схемы. На нижнем уровне глубины эти блок-схемы пусты, но на других уровнях они являются копиями основной блок-схемы. Количество действий в определении рабочего процесса каждого варианта теста указывается в следующей таблице:

Количество действий в определении рабочего процесса резко увеличивается с каждым уровнем глубины. Тем не менее, в каждом экземпляре рабочего процесса выполняется только один путь на каждом пункте принятия решений, поэтому выполняется только небольшое подмножество фактических действий.

Для WF3 был создан эквивалентный рабочий процесс. Конструктор WF3 отображает весь рабочий процесс в области проектирования вместо вложенных элементов, поэтому его нельзя показать в этом разделе из-за размера. Ниже показан фрагмент рабочего процесса.

Для тестирования вложения в экстремальном случае другой рабочий процесс, являющийся частью этого теста, применяет 100 вложенных последовательностей. Во внутренней последовательности находится одиночный Comment или CodeActivity.

Отслеживание и сохраняемость не используются в рамках этого теста.

Результаты теста

Даже при наличии сложных рабочих процессов с большим количеством глубин и большим количеством действий результаты производительности соответствуют другим числам пропускной способности, показанным ранее в этой статье. Пропускная способность WF4 на порядки выше и должна сравниваться по логарифмической шкале.

Память

Затраты на память Windows Workflow Foundation измеряются двумя ключевыми областями: сложность рабочего процесса и количество определений рабочих процессов. Измерения памяти были приняты на 64-разрядной рабочей станции Windows 7. Существует множество способов получить измерение размера рабочего набора, таких как мониторинг счетчиков производительности, опрос данных из Environment.WorkingSet или использование такого средства, как VMMap, доступного из VMMap. Сочетание методов использовалось для получения и проверки результатов каждого теста.

Тест сложности рабочего процесса

Тест сложности рабочего процесса измеряет разницу рабочего набора на основе сложности рабочего процесса. Помимо сложных рабочих процессов, рассмотренных в предыдущем разделе, добавлены новые варианты для двух основных случаев: рабочий процесс с одной активностью и последовательность из 1000 действий. Для этих тестов рабочие процессы инициализированы и выполняются для завершения в одном последовательном цикле в течение одной минуты. Каждый вариант теста выполняется три раза, а записанные данные — среднее значение этих трех запусков.

Два новых основных теста имеют рабочие процессы, которые выглядят следующим образом:

В рабочем процессе WF3, показанном выше, используются пустые CodeActivity действия. Приведенный выше рабочий процесс WF4 использует Comment активности. Действие Comment описано в разделе "Сравнение производительности на уровне компонентов" ранее в этой статье.

Одна из четких тенденций, которые следует заметить на этом графе, заключается в том, что вложение имеет относительно минимальное влияние на использование памяти в WF3 и WF4. Наиболее значительное влияние на память происходит из числа действий в данном рабочем процессе. Учитывая данные из последовательности 1000, вариации последовательности со сложной глубиной 5 и 5, а также со сложной глубиной 7 и 1, становится ясно, что когда количество действий достигает нескольких тысяч, рост использования памяти становится заметнее. В крайнем случае (глубина 7, шаг последовательности 1), где имеется около 29K операций, WF4 использует почти на 79% меньше памяти, чем WF3.

Тестирование нескольких определений рабочих процессов

Измерение памяти на определение рабочего процесса делится на два разных теста из-за доступных вариантов размещения рабочих процессов в WF3 и WF4. Тесты выполняются по-другому, чем тест сложности рабочего процесса в том, что данный рабочий процесс экземплярируется и выполняется только один раз на определение. Это связано с тем, что определение рабочего процесса и его хост остаются в памяти в течение всего времени существования домена приложения. Память, используемая при запуске данного экземпляра рабочего процесса, должна быть удалена во время сборки мусора. Руководство по миграции WF4 содержит более подробные сведения о вариантах размещения. Дополнительные сведения см. в WF Migration Cookbook: Workflow Hosting.

Создание множества определений рабочих процессов для теста определения рабочего процесса может выполняться несколькими способами. Например, можно использовать создание кода для создания набора 1000 рабочих процессов, идентичных за исключением имени и сохранения каждого из этих рабочих процессов в отдельные файлы. Этот подход был применён для теста, проводимого в консольной среде. В WF3 WorkflowRuntime класс использовался для выполнения определений рабочих процессов. WF4 может использовать WorkflowApplication для создания одного экземпляра рабочего процесса или непосредственного запуска WorkflowInvoker действия, как если бы это был вызов метода. WorkflowApplication — это хост одного экземпляра рабочего процесса и имеет более близкое соответствие функций с WorkflowRuntime, поэтому был использован в этом тесте.

При размещении рабочих процессов в IIS можно использовать VirtualPathProvider для создания нового WorkflowServiceHost вместо создания всех файлов XAMLX или XOML. Обрабатывает VirtualPathProvider входящий запрос и отвечает с помощью виртуального файла, который может быть загружен из базы данных или, в данном случае, создается на лету. Поэтому не требуется создавать 1000 физических файлов.

Определения рабочих процессов, используемые в тесте консоли, были простыми последовательными рабочими процессами с одним действием. Одно действие было пустым CodeActivity для случая WF3 и Comment действием для дела WF4. В случае, размещенном в IIS, используются рабочие процессы, начинающиеся при получении сообщения и заканчивающиеся отправкой ответа:

На следующем рисунке показан рабочий процесс WF3 с ReceiveActivity и рабочий процесс WF4 с шаблоном запроса и ответа:

В следующей таблице показана разница в рабочем наборе между одним определением рабочего процесса и 1001 определением.

Размещение определений рабочих процессов в IIS использует гораздо больше памяти из-за WorkflowServiceHost подробных артефактов службы WCF и логики обработки сообщений, связанной с хостом.

Для размещения консоли в WF3 рабочие процессы были реализованы в коде вместо XOML. В WF4 по умолчанию используется XAML. XAML хранится в виде внедренного ресурса в сборку и компилируется во время выполнения, чтобы обеспечить реализацию рабочего процесса. С этим процессом связана некоторая нагрузка. Чтобы сделать справедливое сравнение между WF3 и WF4, кодированные рабочие процессы использовались вместо XAML. Ниже показан пример одного из рабочих процессов WF4:

public class Workflow1 : Activity
{
    protected override Func<Activity> Implementation
    {
        get
        {
            return new Func<Activity>(() =>
            {
                return new Sequence
                {
                    Activities = {
                        new Comment()
                    }
                };
            });
        }
        set
        {
            base.Implementation = value;
        }
    }
}

Существует множество других факторов, которые могут повлиять на потребление памяти. Те же советы для всех управляемых программ по-прежнему применяются. В средах, размещенных в IIS, объект, созданный для определения рабочего процесса, WorkflowServiceHost остается в памяти, пока пул приложений не будет переработан. Это следует учитывать при написании расширений. Кроме того, рекомендуется избежать "глобальных" переменных (переменных, ограниченных всем рабочим процессом) и ограничить область переменных, где это возможно.

Службы среды выполнения рабочих процессов

Сохраняемость

WF3 и WF4 поставляются с поставщиком сохраняемости SQL. Поставщик устойчивости данных WF3 SQL — это простая реализация, которая сериализует экземпляр рабочего процесса и сохраняет его в BLOB. По этой причине производительность этого поставщика сильно зависит от размера экземпляра рабочего процесса. В WF3 размер экземпляра может увеличиться по многим причинам, как описано ранее в этом документе. Многие клиенты предпочитают не использовать поставщик сохраняемости SQL по умолчанию, так как хранение сериализованного экземпляра в базе данных не дает видимости состояния рабочего процесса. Чтобы найти конкретный рабочий процесс, не зная идентификатор рабочего процесса, необходимо десериализировать каждый сохраненный экземпляр и проверить его содержимое. Многие разработчики предпочитают писать собственные поставщики сохраняемости, чтобы преодолеть это препятствие.

Поставщик сохраняемости WF4 SQL пытался устранить некоторые из этих проблем. Таблицы сохраняемости предоставляют определенные сведения, такие как активные закладки и свойства промотируемых объектов. Новая функция корреляции на основе содержимого в WF4 не будет хорошо работать с использованием подхода сохраняемости WF3 SQL, что привело к некоторым изменениям в организации сохраняемого экземпляра рабочего процесса. Это делает работу поставщика сохраняемости более сложным и ставит дополнительную нагрузку на базу данных.

Настройка среды

Испытательная установка

Даже с улучшенным набором функций и более эффективной обработкой параллелизма поставщик сохраняемости SQL в WF4 быстрее, чем поставщик в WF3. Чтобы продемонстрировать это, ниже сравниваются два рабочих процесса, которые выполняют практически те же операции в WF3 и WF4.

Оба рабочего процесса создаются полученным сообщением. После отправки первоначального ответа рабочий процесс сохраняется. В случае WF3 пустое TransactionScopeActivity используется для начала сохранения. То же самое можно достичь в WF3, помечая действие как "сохраняемое при закрытии". Во-вторых, коррелированные сообщения завершают рабочий процесс. Рабочие процессы сохраняются, но не выгружаются.

Результаты теста

Когда транспорт между клиентом и средним уровнем — HTTP, сохраняемость в WF4 показывает улучшение в 2,6 раза. Транспорт TCP увеличивает этот коэффициент до 3,0 раза. Во всех случаях загрузка ЦП на среднем уровне составляет 98% или выше. Причина, по которой пропускная способность WF4 больше, обусловлена более быстрой средой выполнения рабочего процесса. Размер сериализованного экземпляра мал в обоих случаях и не является существенным фактором в этой ситуации.

Рабочие процессы WF3 и WF4 в этом тесте используют активность, чтобы явно указать момент выполнения сохранения. Преимущество заключается в том, что рабочий процесс сохраняется без выгрузки. В WF3 также можно персистировать с помощью функции TimeToUnload, но это выгрузит экземпляр процесса из памяти. Если разработчик, использующий WF3, хочет убедиться, что рабочий процесс сохраняется в определенных точках, необходимо изменить определение рабочего процесса или оплатить затраты на выгрузку и повторное загрузку экземпляра рабочего процесса. Новая функция в WF4 позволяет сохраняться без выгрузки: TimeToPersist Эта функция позволяет экземпляру рабочего процесса сохраняться в неактивном режиме, но оставаться в памяти до тех пор, пока TimeToUnload не будет выполнено пороговое значение или выполнение будет возобновлено.

Обратите внимание, что поставщик сохраняемости WF4 SQL выполняет большую работу на уровне базы данных. База данных SQL может стать узким местом, поэтому важно отслеживать использование ЦП и дисков. Не забудьте включить следующие счетчики производительности из базы данных SQL при тестировании производительности в приложениях рабочих процессов.

• PhysicalDisk\%Disk время чтения

• Физический диск\% время диска

• PhysicalDisk\% время записи на диск

• PhysicalDisk\% Средняя длина очереди диска

• PhysicalDisk\Avg. Длина очереди чтения диска

• PhysicalDisk\Avg. Средняя длина очереди на запись на диск

• PhysicalDisk\Текущая длина очереди диска

• Сведения о процессоре\ время% процессора

• SQLServer:Latches\Среднее Время Ожидания Защёлки (мс)

• SQLServer:Latches\Ожидания фиксации/сек

Отслеживание

Отслеживание рабочих процессов можно использовать для отслеживания хода выполнения рабочего процесса. Сведения, включенные в события отслеживания, определяются профилем отслеживания. Чем сложнее профиль отслеживания, тем дороже отслеживание становится.

WF3 поставляется со службой отслеживания на основе SQL. Эта служба может работать в пакетных и не пакетных режимах. В не пакетном режиме события отслеживания записываются непосредственно в базу данных. В пакетном режиме события отслеживания собираются в тот же пакет, что и состояние экземпляра рабочего процесса. Пакетный режим обеспечивает лучшую производительность для самого широкого спектра проектов рабочих процессов. Однако пакетная обработка может негативно повлиять на производительность, если рабочий процесс выполняет множество действий без сохранения и отслеживания этих действий. Это обычно происходит в циклах, и лучший способ избежать этого сценария заключается в разработке больших циклов для хранения точки сохраняемости. Введение точки сохраняемости в цикл может отрицательно повлиять на производительность, так что важно измерять затраты каждого и придумать баланс.

WF4 не поставляется со службой отслеживания SQL. Запись информации отслеживания в базу данных SQL лучше обрабатывать с сервера приложений, чем встраивать в .NET Framework. Поэтому мониторинг SQL теперь обрабатывается AppFabric. Поставщик отслеживания, готовый к использованию в WF4, основан на Трассировке событий Windows (ETW).

ETW — это система событий с низкой задержкой ядра, встроенная в Windows. Он использует модель поставщика/потребителя, которая позволяет нести штраф за трассировку событий только тогда, когда на самом деле есть потребитель. Помимо событий ядра, таких как процессор, диск, память и использование сети, многие приложения также используют ETW. События ETW являются более мощными, чем счетчики производительности, которые можно настроить для приложения. Событие может содержать текст, например идентификатор рабочего процесса или информационное сообщение. Кроме того, события классифицируются по битовой маске, поэтому использование определенного подмножества событий будет иметь меньше влияния на производительность, чем запись всех событий.

Преимущества использования etw для отслеживания вместо SQL:

• Коллекция событий отслеживания может быть разделена на другой процесс. Это обеспечивает большую гибкость в том, как записываются события.

• События отслеживания ETW легко объединяются с событиями WCF ETW или другими поставщиками ETW, такими как SQL Server или поставщик ядра.

• Авторам рабочих процессов не нужно изменять рабочий процесс, чтобы лучше работать с определенной реализацией отслеживания, например пакетным режимом службы отслеживания WF3 SQL.

• Администратор может включить или отключить отслеживание без перезапуска процесса узла.

Преимущества производительности ETW-трассировки имеют недостаток. События ETW могут быть потеряны, если система находится в условиях сильной нагрузки на ресурсы. Обработка событий не предназначена для блокировки нормального выполнения программы, поэтому не гарантируется, что все события ETW будут транслироваться своим подписчикам. Это делает отслеживание ETW отличным для мониторинга состояния системы, но не подходит для проверки.

Хотя у WF4 нет поставщика отслеживания SQL, в AppFabric он имеется. Подход SQL-трекинга в AppFabric заключается в подписке на события ETW с помощью службы Windows, которая пакетирует события и записывает их в таблицу SQL, предназначенную для быстрой вставки. Отдельное задание очищает данные из этой таблицы и преобразует их в таблицы отчетов, которые можно просмотреть на панели мониторинга AppFabric. Это означает, что пакет событий отслеживания обрабатывается независимо от рабочего процесса, из который он был получен, и поэтому не нужно ждать точки сохраняемости перед записью.

События ETW можно записывать с помощью таких средств, как logman или xperf. Компактный файл ETL можно просмотреть с помощью таких средств, как xperfview, или преобразовать в более читаемый формат, например XML, используя tracerpt. В WF3 единственным вариантом получения событий отслеживания без базы данных SQL является создание пользовательской службы отслеживания. Дополнительные сведения об ETW см. в службах WCF и трассировке событий для Windows и трассировке событий в приложениях Windows.

Включение отслеживания рабочих процессов влияет на производительность в разных уровнях. Ниже приведенный эталон применяет инструмент logman для использования событий отслеживания ETW и записи их в ETL-файл. Стоимость отслеживания SQL в AppFabric не входит в эту статью. Базовый профиль отслеживания, который также используется в AppFabric, показан в этом тесте. Также включена стоимость отслеживания исключительно событий мониторинга состояния здоровья. Эти события полезны для устранения неполадок и определения средней пропускной способности системы.

Настройка среды

Результаты теста

Мониторинг работоспособности имеет примерно 3% влияние на пропускную способность. Стоимость базового профиля составляет около 8%.

Взаимодействие

WF4 почти полностью перезаписывает WF, поэтому рабочие процессы и действия WF3 не совместимы напрямую с WF4. Многие клиенты, которые приняли Windows Workflow Foundation раньше, будут иметь внутренние или сторонние определения рабочих процессов и пользовательские действия для WF3. Одним из способов упрощения перехода на WF4 является использование Interop-активности, которая может исполнять активности WF3 из рабочего процесса WF4. Рекомендуется использовать действие Interop только при необходимости. Дополнительные сведения о миграции в WF4 см. в руководстве по миграции WF4.

Настройка среды

Результаты теста

В следующей таблице показаны результаты выполнения рабочего процесса, содержащего пять действий в последовательности в различных конфигурациях.

Отмечается значительное увеличение производительности при использовании интероперируемости по сравнению с прямым использованием WF3. Однако при сравнении с активностями WF4 увеличение незначительно.

Сводка

Значительные инвестиции в производительность WF4 окупились во многих важных областях. Производительность отдельных компонентов рабочего процесса в некоторых случаях в сотни раз выше в WF4 по сравнению с WF3 благодаря более упрощенной выполняющей среде WF. Кроме того, показатели задержки значительно улучшились. Это означает, что потери производительности при использовании WF вместо ручного кодирования служб оркестрации WCF очень малы, учитывая добавленные преимущества использования WF. Производительность сохраняемости увеличилась на коэффициент 2,5 – 3,0. Мониторинг здоровья с помощью отслеживания рабочих процессов теперь не требует значительных накладных расходов. Полный набор руководств по миграции доступен для тех, кто рассматривает возможность перехода с WF3 на WF4. Все это должно сделать WF4 привлекательным вариантом для написания сложных приложений.