SWEQADM x System Performance

[glauco]

Hi people,

As you could see by my questions I'm testing a lot of things about performance...

Now, the question is the following: How can the queue be a good way to manage the events that are about thousands per day ?

I know some people have answered to me that using it is the best way to improve system performance.

But I want to know how does it work. Because thinking about it initially, a queue is only a way to put events on sequence and time to time those are triggered. But in the end, the same quantity of events will be triggered as without queue.

What a plus of SWEQADM to really improve the system performance ?

Here we have (only counting the events marked to use queue) from 55 per minute up to 195 events per minute depending what time of the day.

Does anybody know ?

[former_member186746 · Accepted solution]

Hi,

As you rightly say, the number of events plus the performance needed won't lessen when you use the event queue, in fact it will go up.

The event queue is used to even out the performance, this means, in theory, that users will have less inconvenience about response times when all of a sudden thousands of events get triggered.

If it is important for the system to balance the performance, the event queue is definately a solution worth considering.

I have seen cases where the event queue was switched off because it used too much resources, instead we came up with various solution in which most of the events were triggered at nighttimes, or in the weekend.

Kind regards, Rob Dielemans

[glauco · Accepted solution]

Friends,

I don't understand why people always suggest others to use event queue.

I think that is interesting using for example the redelivering functionality on SWEQADM but not the queue for heavy systems that is my case that are triggered more than 60000 events per day and it has the maximum of 195 events per minute.

So I think it isn't my case to use event queue. Is it ?

[former_member186746 · Accepted solution]

The use of the event queue comes into consideration when you have a lot of events happening all at once and you have a production system with a lot of users.

Suppose that once in a while a mass update of something causes 100.000 events all at once on a production system with a hundred users. In that case all of the users won't be able to work normally untill the strain on the system goes away.

For scenarios like that an event queue works, so the users won't notice it

I doubt if in your scenario it will work, I don't think that the users on your system complain about sudden loss of performance.

If I were you I would look for other solutions, like cleaning up obsolete workflows, and workitems and of course archiving.

Kind regards, Rob Dielemans

[glauco · Accepted solution]

Hi Rob, thanks for you quick answer.

Talking about the amounts of events triggered, here the BASIS always tell me about deadlocks in the database (Oracle) and these events. A lot of times he asks for any solution about the amounts of RFC's calls showed by some report that he runs.

Some times we can see a lot of events been triggered in the same time (in the

same second) !!!

Sure, I'm studying about archiving too.

And talking about the things that Mike have said...It's a choose that the manager here won't make I think. But it was interesting to know about that.

Another thinhg I want to talk about is to deactivating event trace on SWELS. I've heard that in some place that somebody had deactivated event trace to improve the performance of the system. But making it, do we stay without the workflows log ?

Message was edited by:

Glauco Kubrusly

[former_member186746 · Accepted solution]

Workflow log and event trace are two different things.

Only activate the event trace on production when you can't reproduce an error on development, or acceptation.

Kind regards, Rob Dielemans

[glauco · Accepted solution]

But how can I watch the workflow logs ?

By using swi2_freq or swi1 ? Will this work even I had deactivated the trace by swels ?

[former_member186746 · Accepted solution]

Yes, ofcourse you can still view the workflow log via swi1, or swi2_freq, as I said they are 2 different things.

If you don;t believe me, why not try it out on development?

Kind regards, Rob Dielemans.

PS If your question is answered, you can change the status of your questions to answered in the top left of your screen.

[glauco · Accepted solution]

Hi Rob,

I've just tested the deactivation of SWEL by SWELS and now I can see that we can "live" very well without SWEL - event trace.

I could see that we can make analysis of the workflow log yet by swi2_freq.

I want to see the result about system performance.

Thank you very much.

Message was edited by:

Glauco Kubrusly

[former_member186746 · Accepted solution]

You're welcome

since you're having lots of overall system performance. check this link as well.

<a href="http://www.sapsuperusers.com/forums/showthread.php?t=4436">http://www.sapsuperusers.com/forums/showthread.php?t=4436</a>

You may have to register first. This is a link about finding the largest database and growth in your system, this is a must have tool for finding databases which are in dire need of archiving.

Kind regards, Rob Dielemans

[glauco · Accepted solution]

Ok Ro, I'm going to read this material.

Thanks again.

[pokrakam]

Hi Glauco,

From the help:

<i>You can use the event queue to delay the starting of receivers reacting to a triggering event. To achieve this, the receivers are stored in a temporary memory.</i>

and

<i>This means that the system load caused by a large number of events being created can be spread over a longer time period (which can be set by the workflow system administrator). This combats the threat of system overload</i>

A perfect answer to your question, if there's something you don't understand we're glad to help.

Another tip: Also look at the help for the latest versions. Sure, things may work differently but often some of the basics are also explained better.

Cheers,

Mike