<font size=2 face="sans-serif">Hi Mike,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the response - I think your
answer pinpoints the real consideration, which is the amount of events
being generated vs. the size/ability of the system to cope with it. Of
course, you don't know the true impact until it's happening for real in
production, which then explains the default recommendation of leaving it
turned off unless strictly necessary.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">Best Regards,<br>
James Johnson<br>
<br>
E-mail:JJohnson@uk.ibm.com<br>
Mobile: 07908715224 or 07920870270</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Mike Pokraka"
<wug@workflowconnections.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"SAP Workflow
Users' Group" <sap-wug@mit.edu>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/03/2014 14:03</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: Workflow
Event Trace Leave On or Turn Off</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">sap-wug-bounces@mit.edu</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi,<br>
<br>
> My question would be - why is it bad for performance?<br>
><br>
> You certainly introduce a large number of writes to the event log
table,<br>
<br>
Isn't that considered answering your own question? :-)<br>
<br>
On a serious note, yes you certainly introduce a large number of writes.<br>
Of course it all depends on the size of the system. Remmeber that ALL<br>
events are processed by the logger, not just those with linked workflows.<br>
That means everything that's happening in the system - HR, Finance,<br>
whatever - is pumping events into the same table. On a big system this
can<br>
easily achieve a rate of millions per hour.<br>
<br>
Regards,<br>
Mike<br>
<br>
<br>
On Fri, March 7, 2014 11:37 am, James Johnson wrote:<br>
> Hi WUGgers,<br>
><br>
> This might sound like a stupid question (apologies in advance), but
I keep<br>
> reading (on SCN, and in Practical Workflow for SAP) that the event
trace<br>
> is bad for performance (as noted/discussed below). My question
would be -<br>
> why is it bad for performance?<br>
><br>
> You certainly introduce a large number of writes to the event log
table,<br>
> but I wouldn't think that it would really have an on performance unless<br>
> you were to also read from the table on a regular basis. As
long as the<br>
> space consideration of the event log table is dealt with by running
the<br>
> job to clear it down every once in a while, then it seems feasible
to<br>
> leave it running.<br>
><br>
> Best Regards,<br>
> James Johnson<br>
><br>
> E-mail:JJohnson@uk.ibm.com<br>
> Mobile: 07908715224 or 07920870270<br>
><br>
><br>
><br>
> From: Rick Bakker <rbakker@gmail.com><br>
> To: "SAP Workflow Users' Group" <sap-wug@mit.edu>,<br>
> Date: 06/03/2014 22:55<br>
> Subject: Re: Workflow Event Trace Leave
On or Turn Off<br>
> Sent by: sap-wug-bounces@mit.edu<br>
><br>
><br>
><br>
> Hi Eddie,<br>
><br>
> Thanks for sharing your (formidable) experience. Could you tell us
more<br>
> about the situations where this brought the system down?<br>
> Luckily I haven't encountered such a problem yet but I sure would
like to<br>
> know about it.<br>
><br>
> I have found the event trace to be extremely useful in many cases.
In the<br>
> most trivial case it's good for convincing a user that yes, they did<br>
> indeed press the Cancel button.<br>
><br>
> regards<br>
> Rick Bakker<br>
><br>
><br>
><br>
> On Thu, Mar 6, 2014 at 11:33 PM, Morris, Eddie <eddie.morris@sap.com><br>
> wrote:<br>
> Hi Rick,<br>
><br>
> Speaking from experience I have seen this take systems down on quite
a few<br>
> occasions so it can go horribly wrong. If you have someone who can
monitor<br>
> it and delete trace data when needed then I guess it is workable.
Also use<br>
> the trace restrictions when switching it on so only monitor a select<br>
> number of events.<br>
><br>
> Also with note 1905199 a syslog entry (SM21) is written when an event<br>
> linkage is deactivated so this can be used to check when the event
linkage<br>
> deactivation occurs. Then use the event trace to get specific information<br>
> about the deactivation itself.<br>
><br>
> Regards,<br>
> Eddie<br>
><br>
> From: sap-wug-bounces@mit.edu [</font></tt><a href="mailto:sap-wug-bounces@mit.edu"><tt><font size=2>mailto:sap-wug-bounces@mit.edu</font></tt></a><tt><font size=2>]
On Behalf<br>
> Of Rick Bakker<br>
> Sent: 05 March 2014 22:17<br>
> To: SAP Workflow Users' Group<br>
> Subject: Re: Workflow Event Trace Leave On or Turn Off<br>
><br>
> Hi David,<br>
><br>
> I like to leave the event trace turned on. I have found this to be
the<br>
> case at most sites. Also, most workflow people I have worked with
agree<br>
> with this approach. The overhead is minuscule compared to the information<br>
> it adds.<br>
><br>
> regards<br>
> Rick Bakker<br>
><br>
> On Thu, Mar 6, 2014 at 3:29 AM, Edward Diehl <edwarddiehl@hotmail.com><br>
> wrote:<br>
> It's not whether or not the trace is running, it's how often you delete<br>
> "old" entries and reorg it. Having said that, we have
stopped using it to<br>
> test for duplicate events and now check for duplicate workflows in
a check<br>
> function.<br>
><br>
><br>
> Ed Diehl<br>
> "Success consists of going from failure to failure without loss
of<br>
> enthusiasm."<br>
><br>
><br>
><br>
> To: sap-wug@mit.edu<br>
> From: davidcooper06@icloud.com<br>
> Subject: Workflow Event Trace Leave On or Turn Off<br>
> Date: Wed, 5 Mar 2014 06:55:50 +0000<br>
><br>
> Hi All,<br>
><br>
> The following is more a discussion item!<br>
><br>
> I have read in various texts and heard from several workflow<br>
> administrators that it is recommended to turn the workflow trace off
in<br>
> production.<br>
><br>
> Reasons:<br>
> 1) The trace adds an overhead to the application and database servers,
and<br>
> 2) The trace fills up the event table(s) with data that is not needed
over<br>
> time.<br>
><br>
> My argument for leaving the trace running, is more for diagnostic
reasons<br>
> when problems occur in production. It becomes another source
for tracking<br>
> down what happened. Yes the overhead is a given, but I feel
this is<br>
> justified to capture the diagnostic information. As for the
database<br>
> table being filled, implement a deletion strategy which purges the
data<br>
> from the table after a period of say 3 ,6, 9, or 12 months.<br>
> Kind Regards<br>
> David Cooper<br>
> Linked-In: </font></tt><a href="http://www.linkedin.com/pub/david-cooper/47/616/36a"><tt><font size=2>http://www.linkedin.com/pub/david-cooper/47/616/36a</font></tt></a><tt><font size=2><br>
><br>
><br>
> _______________________________________________ SAP-WUG mailing list<br>
> SAP-WUG@mit.edu </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
><br>
> Unless stated otherwise above:<br>
> IBM United Kingdom Limited - Registered in England and Wales with
number<br>
> 741598.<br>
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU<br>
> _______________________________________________<br>
> SAP-WUG mailing list<br>
> SAP-WUG@mit.edu<br>
> </font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
><br>
<br>
<br>
_______________________________________________<br>
SAP-WUG mailing list<br>
SAP-WUG@mit.edu<br>
</font></tt><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug"><tt><font size=2>http://mailman.mit.edu/mailman/listinfo/sap-wug</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>