Event queue: Events per read access

Michael Pokraka workflow at quirky.me.uk
Wed Mar 23 04:43:48 EST 2005


Hi Kjetil, 
I've had the most fun with the event queue on a 4.6c system. This was where I
encountered the overlap problem - it was only the occasional duplicate event
which happened during the overlap times. I vaguely remember looking at the code
for the job and finding specific handling for multiple accesses. 

You can't really get proper numbers off any other system since it's all
hardware dependednt. Also make sure to use asynch access and server groups to
spread things across all available servers - especially if it's in the wee
hours of the morning. 

I don't know how strict your environment is, but a swifty abap to log job
runtimes in PRD might be an idea... 

Cheers
Mike

--- Kjetil Kilhavn <kjetilk at statoil.com> wrote:

> 
> Thanks. I could have phrased my question better, but you read very well
> between the lines :-)
> 
> The value currently used is finely tuned so that in our test system (for
> the most heavily loaded production system) the job takes around 55 seconds
> when there are enough events. I expect it to run much faster in production
> since the hardware there for application as well as DB servers are much
> better, but the program deletes it's own job logs so getting statistics
> isn't easy. On average the production system runs jobs in roughly one third
> of the time, but the variations are big. Guess I'll have to postpone the
> job that creates most events one morning (or be at work at 05:00 to watch
> it "live").
> 
> I'll reduce it to 60 events per read access for now and see if the delays
> are acceptable.
> 
> By the way: we are on 46C and here the program didn't care if two instances
> ran at the same time - so it is possible that it also delivered the events
> twice when that happened.
> --
> Kjetil Kilhavn
> 
> 
> 
> 
>                                                                              
>                                                                 
>                     Michael                                                  
>                                                                 
>                     Pokraka              To:     "SAP Workflow Users' Group"
> <sap-wug at mit.edu>                                                
>                     <workflow at qui        cc:     (bcc: Kjetil Kilhavn)       
>                                                                 
>                     rky.me.uk>           Subject:     Re: Event queue: Events
> per read access                                                 
>                     Sent by:                                                 
>                                                                 
>                     sap-wug-bounc                                            
>                                                                 
>                     es at mit.edu                                               
>                                                                 
>                                                                              
>                                                                 
>                                                                              
>                                                                 
>                     21.03.2005                                               
>                                                                 
>                     17:48                                                    
>                                                                 
>                     Please                                                   
>                                                                 
>                     respond to                                               
>                                                                 
>                     "SAP Workflow                                            
>                                                                 
>                     Users' Group"                                            
>                                                                 
>                                                                              
>                                                                 
>                                                                              
>                                                                 
> 
> 
> 
> 
> Hi Kjetil,
> My rather unscientific answer is "it depends".
> There's all the other stuff you can adjust about servers groups, load
> balancing
> etc. You could even run a dedicated WF server :-) Also depends on the types
> of
> flows and what they do.
> 
> If the processing takes longer than a minute, the jobs can overlap. I have
> had
> some fun with this on a 4.6something system, they get confused and can end
> up
> delivering the same event twice. SM37 is your friend here, my best guess is
> the
> maximum that keeps the queue job's runtime below a safe 30 seconds. However
> if
> it's all heavy dialog processing you may end up hogging all available
> dialog
> sessions, so watch out for that as well. 0.5 WPS sounds a reasonable
> starting
> point.
> 
> Cheers
> Mike
> 
> --- Kjetil Kilhavn <kjetilk at statoil.com> wrote:
> > After the tremendous success with my question about settings for SWWERRE
> (2
> > replies both recommending to keep my hands off the setting) it is time to
> > have another go at asking what values are used around the world.
> >
> > The event queue is a fine tool to distribute the load, but I find the
> > example value in the documentation a bit unrealistic. 5 events per read
> > access amounts to a maximum of 300 per hour if you run the dispatcher
> every
> > minute. That sounds a little low. The load on the server would be very
> low,
> > but on the other hand the wait time could be long if there are a lot of
> > events being created. Even if you scan a batch of invoices you would
> > perhaps have to wait 5 minutes for them to be available (assuming you
> used
> > the event queue for that).
> >
> > I have set it high enough to avoid any significant delays, but I think it
> > is higher than it should be. The current setting is 150 events per read
> > access, with the dispatcher running every minute, for a maximum of 9.000
> > events per hour. I think it is wise to run the dispatcher every minute,
> but
> > would like to have a much lower value for number of events per read
> access.
> > Something between 25 and 100  sounds better to me. A setting of 50 would
> > give nearly one WPS - workflow per second :-)
> >
> > Let's have a show of hands here! What is the value *your* company/client
> > uses?
> > --
> > Kjetil Kilhavn
> >
> > -------------------------------------------------------------------
> > The information contained in this message may be CONFIDENTIAL and is
> > intended for the addressee only. Any unauthorised use, dissemination of
> the
> > information or copying of this message is prohibited. If you are not the
> > addressee, please notify the sender immediately by return e-mail and
> delete
> > this message.
> > Thank you.
> >
> > _______________________________________________
> > 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
> 
> 
> 
> 
> -------------------------------------------------------------------
> The information contained in this message may be CONFIDENTIAL and is
> intended for the addressee only. Any unauthorised use, dissemination of the
> information or copying of this message is prohibited. If you are not the
> addressee, please notify the sender immediately by return e-mail and delete
> this message.
> Thank you.
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> 



More information about the SAP-WUG mailing list