AW: Workflow Performance

[Alon Raskin]

Thank you Stephan. As always your advice is invaluable.
 
Regards,
 
Alon
 
 
Quoting "Becker Stephan (extern)" <Stephan.Becker.ext at mchw.siemens.de>:
 
> Hi Alon,
>
> I have implemented several large scale workflow scenarios. It always
> seems
> to come down to two factors: If the workflow and the underlying
> business
> process are properly designed, and people are not flooded with
> workitems, it
> is the load of dialog and background tasks generated by the workflow
> engine,
> and the table growth in the runtime tables that makes things difficult
> in
> productive environments.
>
> Table growth can be countered by taking the sizes and growth factors
> into
> account when specifying the hardware (one of my clients had 1Gig growth
> per
> month just in the workflow tables, with just one big invoice
> verification
> workflow on line item level..), the figures you need for this sizing
> will
> need to come out of the stress test part of the integration test.
> Also,
> ensure you archive closed workflows often, that will keep tables sizes
> low.
>
> RFC load can be fought by giving workflow its own app server. If you
> have 49
> anyway, another one or two for workflow won't really matter greatly in
> terms
> of budget and such like, but they will make a world of difference for
> the
> users, as large number of events can bring app servers close to a
> standstill
> (sometimes beyond..), and users will go beserk.. The only thing you need
> to
> do for that is point the RFC destination used for the workflow to a
> different destination, that's it..
>
> Next to that, you can do all sorts of optimisations, but they mostly
> scratch
> the surface, and make little actual difference in terms of performance,
> but
> depending on the circumstances, it would not be wise to ignore this
> possibility. To alleviate peaks, for example, see which events you can
> trigger with a time delay, so that the system does not have to cope
> with
> dozends of events to be processed, when, say, a large invoice is entered
> and
> triggers off a workflow per line item..
>
> Hth,
> Stephan
>
> -----Urspr|ngliche Nachricht-----
> Von: Alon Raskin [mailto:araskin at 3i-consulting.com]
> Gesendet: Mittwoch, 7. August 2002 23:55
> An: SAP-WUG at MITVMA.MIT.EDU
> Betreff: Workflow Performance
>
>
> My current client is quite concerned about Workflow and its impact on
> system
> Performance. I would like to hear others who have had 'large' clients
> weigh
> in on this.
>
> I have tried to explain to my client that if we are kicking off many
> events
> per hour then that can have an impact on the system performance. I
> explained
> that this can be offset by using the Event Queue (I am not sure that
> that is
> its proper name).
>
> They are also concerned about having many workflows 'sitting around'
> and
> listening for events to be raised. I told them that this is not really
> a
> problem as the Workflow is not actually polling. In fact when the even
> occurs it triggers the workflow.
>
> I would love to hear from other people who have had experience with
> large
> workflow implementations.
>
> Just for your information, our site has just gone through a sizing
> exercise
> and it seems that they will be needing 49 app servers. So we are
> talking
> about some serious sized implementation.
>
> I look forward to your thoughts about any workflow-performance
> experience
> that you would like to share.
>
> Regards,
>
> Alon Raskin
> 3i Consulting Group
> e: araskin at 3i-consulting.com
> w: http://www.3i-consulting.com
>
 
 
 
Alon Raskin
3i Consulting Group
http://www.3i-consulting.com