For instance, 50,000 workflows may contain 10 steps each, of which 1 to 2 steps may be activated at any time. Only active steps are being processed, other steps are at rest. If the active step is a manual piece of work, the workflow task is waiting for the manual task to be performed and at rest in the database. The workflow processing to determine the next task or action are processed in a very short timeframe. The throughput of the active tasks within your workflow requests upper limit is dependent on application server capacity (how many nodes in the cluster, how much memory is assigned to each JVM) etc.
Since all workpoint configuration is in the Workpoint (WPDS) database, it will also depend on your database efficiency (cluster / RAC, space and memory as well).
You would also want to go into Designer and for each process definition used, uncheck history, so all the WP_****_HIST tables will not get populated to decrease the amount of database space used for each workflow request.
From the standpoint of the IM / Workpoint integration please consider the following:
Every approval task is an additional IM task, that's recorded in tasksession12_5 table, and affects row count on all tables in Task Persistence (TP) database. You'll need to think of regularly running Cleanup Submitted Tasks to keep the TP db as trimmed as possible, for best performance.
Performance testing has been performed by CA, Workpoint and other customers. Workflow processing of tasks in a sub-second transaction and performance has many variables based on the environment and the actual workflow tasks and actions modeled. An overview of a performance test for peak and stability results showed the average response time for a test goal of .05 seconds had an actual test result of average response time from .024 to .028 seconds.