Подходят ли машины состояний Windows Workflow Foundation для сценариев высокой производительности? - PullRequest
6 голосов
/ 19 августа 2009

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

В настоящее время я использую пользовательскую реализацию конечного автомата. однако, поскольку WF используется в других частях системы, мне интересно, могут ли автоматы WF подходить для такого сценария с несколькими (<5) состояниями. </p>

Боюсь, что накладные расходы могут быть слишком большими, когда речь идет о производительности. Поскольку документация MS на самом деле не охватывает темы, касающиеся производительности для конечных автоматов WF, мне интересно, есть ли у какого-либо члена SO информация или ресурсы, относящиеся к производительности конечного автомата WF?

С уважением к.

Ответы [ 4 ]

5 голосов
/ 27 января 2010

Если вы ищете высокопроизводительный конечный автомат на основе .Net, я бы порекомендовал Stateless . Вот выдержка из сайта проекта:

Поддерживаются большинство стандартных конструкций конечных автоматов:

  • Общая поддержка штатов и триггеры любого типа .NET (числа, строки, перечисления и т. д.)
  • Иерархические состояния Вход / выход события для штатов
  • Охранные пункты для поддержки условных переходы
  • Самоанализ

Также предоставляются некоторые полезные расширения:

  • Возможность хранить состояние внешне (например, в отслеживаемом свойстве Linq to SQL)
  • Параметризованные триггеры
  • Входящие штаты

Конфигурация выглядит следующим образом:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

И приятно то, что, поскольку он реализует Generics, вы можете использовать int или string для представления состояний и триггеров, что позволяет очень легко интегрироваться с вашей базой данных или ORM. Прелесть в том, что нет никакого дополнительного хоста времени выполнения, о котором вам нужно беспокоиться, просто загрузите конечный автомат с текущим состоянием из объекта или записи, и все готово.

5 голосов
/ 21 августа 2009

Конечные автоматы отлично подходят для высокопроизводительной системы. Если вам действительно нужна очень высокая производительность, использование Workflow Foundation добавляет много сложности и накладных расходов. Я обнаружил, что biztalk совершенно не подходит для очень высокой производительности.

1 голос
/ 21 августа 2009

Это не говорит непосредственно о производительности, но если вы планируете в конечном итоге перейти на WF 4.0, вы должны знать, что StateMachineActivity скорее всего не будет сокращать .

1 голос
/ 20 августа 2009

Microsoft в настоящее время использует WF в своих серверных продуктах, и они расширяют это. Так, например, механизм WF можно найти на сервере Share Point (MOSS) и в BizTalk Server. И то, и другое хорошо масштабируется и позволяет масштабировать сценарии - то есть вы добавляете больше (дешевого) оборудования в кластер с балансировкой нагрузки, если вам требуется больше вычислительной мощности.

НТН, Thomas

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...