Event queue: Events per read access

Tue Mar 22 02:32:58 EST 2005

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.