Poor background steps performance

[george_caramaliu@yahoo.com]

Hi Mike,
The problem seems to be solved now by increasing the Max Conn. parameter in SMQS for for RFC destination WORKFLOW_LOCAL_0XX from 10 to 20. Of course that depending on the system load some delays may still occur, but for now this configuration seems to work fine.
Thank you for your support! George
      From: Mike Pokraka <wug at workflowconnections.com>
 To: SAP Workflow Users' Group <sap-wug at mit.edu> 
 Sent: Tuesday, March 17, 2015 11:30 PM
 Subject: Re: Poor background steps performance
   
Hi George,

Unfortunately it's not as simple as "a basis performance task". Yes there
can be a resource shortage, but even with double the servers it will grind
to a halt if you do a batch load that tries to grab 1000 dialog processes
via RFC at once. So you need to look at basis and application sides.
That's why it is important to find out what was running at the time. Some
clues to look for: does it happen at certain times of day? What are your
event queue settings - do they point all workflows to a specific
server/group?

Regards,
Mike


On Mon, March 16, 2015 9:41 am, george_caramaliu at yahoo.com wrote:
> Thank you Mike for the detailed answer.My problem is that I do not know
> how to solve it, for me it is a basis performance task. What resources
> should be added in order to avoid such delays in TRFC processing? Dialog
> work processes, background work processes, database buffer?My only concern
> is that this delay seems to happen only in this particular workflow, I did
> not found such delays in background steps for other workflow templates.
> Could it be related to the fact that the background step has "Advance with
> dialog" checked and the job is initially started by the dialog user that
> completed the previous step? I do not know why it was set up like this, I
> did not developed the workflow.
> Thank you,George
>      From: Mike Pokraka <wug at workflowconnections.com>
>  To: SAP Workflow Users' Group <sap-wug at mit.edu>
>  Sent: Sunday, March 15, 2015 10:16 PM
>  Subject: Re: Poor background steps performance
>
> Hello George,
>
> Bit of a late reply, but in case you're still facing this issue, here
> goes:
>
> This delay has nothing to do with the Workflow system itself. As you
> already observed, once execution starts, it's pretty quick. It is doing
> exactly what it is supposed to. When it creates the tRFC, it says to the
> SAP system "Please execute this FM with these parameters". If resources
> are available, SAP will do it. Else it goes into it's internal queue and
> gets processed whenever it has time.(This incidentally is one of the
> reasons why one should never rely on things happening in a certain time or
> even sequence).
>
> Enough resources assigned is meaningless without knowing what was going on
> in the system at that particular time. You could look at the job log for
> some clues. If a large batch of <whaterver> happens at the time your
> workflow wants to do it's thing, there may be contention for 15 minutes
> and then the system is fine again.
>
> In other words, this looks perfectly normal from a workflow perspective.
>
> Regarding event queue, it's main function is to spread peak loads. It's
> only really relevant if you have more workflows than the system can handle
> (e.g. if you have a process kicking off 100+ workflows). The event queue
> stores them and the job will start n of them every time it runs, thus
> spreading sudden spikes. If your processes are manual or not subject to
> spikes then they do not need to be in the queue.
> A secondary function of the event queue is to be able to channel all the
> workflow starts to a specific server group if it is so configured. You can
> check this out for yourself in SWEQADM, there is some good doco in the
> transaction and the F1 help.
>
> Hope that helps,
> Mike
>
>
> On Thu, March 5, 2015 9:47 am, george_caramaliu at yahoo.com wrote:
>> Hello everyone,
>> I need an advice because I am out of options.I have a complex workflow
> where from time to time some background steps are executed by the system
> with delay. There is no delay coded inside or set up on the step, as
> long
>> as it happens only when the system is overloaded.The problem is that the
> workflow is creating the background step successfully, in the technical
> log I see the messages "Background work item created" and "Background
> processing started" immediately after the previous step was completed,
> but
>> the next entry in the log for the background step with "Execution
> started"
>> is created with 5 to 60 minutes delay, varying randomly (as attached).
> Once the execution is started the step is completed very fast, so it is
> not a problem of the code inside.
>> The basis consultants checked and it seems that the system has enough
> TRFC
>> resources assigned in SMQS and recommended to change the settings in
> SWEQADM regarding event queue administration, more specific the
> parameters
>> (no of events per read access) for background job execution for event
> delivery.In my system I have the event queue enabled for 9 events and in
> this specific workflow one of this queue enabled event is used, but I
> cannot imagine how the background job execution for event delivery could
> influence the processing of a background task that is already created
> but
>> not processed by TRFC.
>> Any suggestion is welcomed, I am considering also to remove the event
> from
>> the event queue, as I never had any issues with non queued events, or to
> increase further the no of events per read access. By the way, does
> anyone knows what exactly this background job for event queue processing
> does? It is executed each 2 minutes for a predefined no of events but in
> the test system the events are triggered and processed immediately, I
> expected that the events would be processed only by this job, but is
> seems
>> it is not the case.
>>
>> Thank you,George CaramaliuSAP Workflow/ABAP consultant 
>>   _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug


>
>  _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20150320/8d974063/attachment.htm