Производительность WF с новыми 20 000 сохраненных экземпляров рабочих процессов каждый месяц

Question

В Windows Workflow Foundation есть проблема, которая медленно работает при сохранении экземпляров WF. Я планирую сделать проект, бизнес-уровень которого будет основан на предоставляемых WF сервисах WCF. Проект будет иметь 20000 новых экземпляров рабочего процесса, создаваемых каждый месяц, каждый экземпляр может занять до 2 месяцев. То, что меня заставило поверить, это то, что если WF замедляется, когда я выполняю персианс, то моя проблема будет недостижима из-за соображений производительности. У меня есть следующие вопросы:

1. Это правда? Будет ли моя производительность дерьмом с этой нагрузкой (учитывая ограничения скорости WF)
2. Как мне решить проблему?

В настоящее время у нас есть два возможных решения: 1. Каждый новый запрос бизнес-процесса (например, дайте мне новую водительскую лицензию) будет новым экземпляром WF, и количество операций персистентности будет ограничено путем пересылки всех операций запроса статуса в сохраненные значения состояния в отдельной базе данных. 2. Имейте только небольшое количество Экземпляров Рабочего процесса в любой момент времени, без какого-либо постоянного присутствия (только в случае сбоев системы и т. Д.), Разбивая каждый этап рабочего процесса на отдельное рабочее пространство, и этот рабочий процесс обрабатывает каждый запрос бизнес-процесса. экземпляр в системе на текущем этапе (например, я отправляю форму запроса водительских прав, которая является первым этапом ... у нас есть 100 таких случаев, и мой рабочий процесс первого шага будет обрабатывать каждый случай одновременно).

Я очень заинтересован в решении этой проблемы. Если вы хотите обсудить эту проблему, пожалуйста, напишите мне по адресу nstjelja@gmail.com

Answer 1

В моем текущем проекте мы также используем WF с постоянством. У нас не совсем одинаковый объем (возможно, ~ 2000 экземпляров / месяц), и они обычно не так долго, чтобы закончить (они обычно делаются в течение 5 минут, в некоторых случаях несколько дней). Мы решили разделить основной рабочий процесс на две части, где будет нормальное состояние ожидания. Я не могу сказать, что из-за этого я заметил какую-либо разницу в производительности системы, но она упростила ее, поскольку в нашей системе иногда возникали проблемы с сопоставлением входящих сигналов с правильным экземпляром рабочего процесса (это было проблемой в нашем коде; WF).

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

Answer 2

Если честно, я все еще исследую рабочие характеристики основания рабочего процесса.

Однако, если это поможет, я слышал, что команда WF сделала много улучшений производительности с новым выпуском WF 4.

Вот несколько ссылок, которые могут помочь (если вы их еще не видели)

Введение разработчика в Windows Workflow Foundation (WF) в .NET 4 (обсуждается повышение производительности)

Характеристики производительности Windows Workflow Foundation (применимо к WF 3.0)

Answer 3

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

Answer 4

WF на 3.5 была проблема с производительностью. WF4 нет - 20000 экземпляров WF в месяц - ничто. Если бы вы говорили в минуту, я бы волновался.