Performances WF avec les 20 000 instances de flux de travail persistantes chaque mois

Question

Windows Workflow Foundation présente un problème lent lors de la persistance des instances WF. Je prévois de faire un projet dont la couche bussiness sera basée sur les services WCF exposés WF. Le projet aura 20 000 nouvelles instances de flux de travail créées chaque mois, chaque instance pouvant prendre jusqu'à deux mois pour se terminer. Ce que j'ai été amené à croire que, étant donné les slownes WF lors de la peristance, mon problème donné serait inaccessible pour des raisons de performance. J'ai les questions suivantes:

1. Est-ce vrai? Est-ce que ma performance sera merdique avec cette charge (étant donné les limitations de vitesse de persistance WF)
2. Comment puis-je résoudre le problème?

Nous avons actuellement deux solutions possibles: 1. Chaque nouvelle demande de processus de buisiness (par exemple: Donne-moi une nouvelle licence de pilotes) sera une nouvelle instance WF, et le nombre d'opérations de Persistance sera limité en transmettant tout état demande des opérations aux valeurs d'état sauvegardées dans une base de données séparée. 2. Ne disposez que d'une petite quantité d'instances de workflow à tout moment, sans aucune persistance (uniquement en cas de panne du système, etc.), en séparant chaque workflow en un worklof distinct et ce workflow traitant chaque processus métier demande une instance dans le système qui est à cette étape actuelle (par exemple, je soumets mon formulaire de demande de permis de conduire, qui est la première étape ... nous en avons 100 cas, et mon flux de travail traitera chaque cas simultanément).

Je suis très intéressé par la solution à ce problème. Si vous voulez discuter de ce problème, n'hésitez pas à m'envoyer un mail à nstjelja@gmail.com

Answer 1

Le nombre de wokflows hydratés en cours d'exécution sera déterminé par des facteurs environnementaux, par exemple le serveur de mémoire, etc. La question de la persistance ne joue vraiment que si vous les workflows de chargement et de déchargement tout le temps alias vrai (ish) temps dans ce cas, le workflow n'est peut-être pas la meilleure solution.

Answer 2

Dans mon projet actuel, nous utilisons également WF avec persistance. Nous n'avons pas tout à fait le même volume (peut-être ~ 2000 instances/mois), et ils ne sont généralement pas aussi longs à terminer (ils sont normalement effectués dans les 5 minutes, dans certains cas quelques jours). Nous avons décidé de diviser le flux de travail principal en deux parties, où l'état d'attente normal serait. Je ne peux pas dire que j'ai remarqué une différence de performance dans le système, mais cela l'a simplifié, car notre système avait parfois des problèmes pour faire correspondre les signaux entrants à l'instance de workflow correcte (c'était un problème dans notre code; WF).

Je pense que si je devais démarrer un nouveau projet basé sur WF, je préfèrerais opter pour des workflows plus petits qui sont invoqués en séquence, plutôt que d'avoir de gros workflows pour gérer le processus complet.

Answer 3

Pour être honnête, j'étudie toujours les caractéristiques de performance de la fondation de flux de travail.

Toutefois, si elle aide, je l'ai entendu l'équipe WF ont apporté de nombreuses améliorations de performance avec la nouvelle version de WF 4.

Voici quelques liens qui pourraient aider (si vous havn't semblent déjà les)

A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4 (discusses performance improvements)

Performance Characteristics of Windows Workflow Foundation (applies to WF 3.0)

Answer 4

WF sur 3.5 avait un problème de performance. WF4 ne fait pas - 20000 instances WF par mois n'est rien.Si vous parliez par minute, je serais inquiet.