Brian, I think I would take a different tactic if you are really concerned about speed. (And for the record 4500 records being updated in 12 minutes does not sound that slow to me.)
I would have the Escalation match on one record, but instead of doing a Push action have it do a Run process. The Run process can be an ARS API client that can be multi-threaded and even use a private RPC number so that you can limit the number of threads of the ARS server it uses (to not over kill the ARS server, nor prevent access to the rest of the users during the processing) and also to free up the Escalation thread as quickly as possible. However, it is worth noting that in v7.1 the Escalations can be separated into individual threads so the later concern is greatly diminished. HTH. However, to fully answer your performance question.... Turn on API and SQL and Filter logs. A careful review of those should tell you the differences between the two paths and where the time is being spent. Sometimes performance differences have more to do with transient conditions than we want them to. So you may need to try both orders of the operations in the testing too. "A then B" vs "B then A" to really be able to make a real decision too. As little as one bad search that does not use an index can really throw off the results. Or having the RDMBS swap the index out of RAM in the middle of the operation can also make things unexpectedly variable too. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Thu, Mar 20, 2008 at 6:01 PM, Brian Goralczyk <[EMAIL PROTECTED]> wrote: > ** > It is my understanding that the first process would happen quicker because > the escalation is only running on one record. It does however require one > aditional step. > > The reason for the display only field is so that the form will record an > update and start the filters firing. It is running unqualified because I > want it to fire on every record. So you are correct in that assumption. > > Am I wrong in my assumption that having the escalation run on one record > that then fires a filter to every record in another form would cause the > second action to become multi-threaded? The intention here is to cause the > server to fire on as many LDAP records as possible as quickly as possible. > The LDAP form is the slowest piece of the process. By FAR!! > > Brian Goralczyk > > > > On Thu, Mar 20, 2008 at 4:46 PM, Thomas Bean <[EMAIL PROTECTED]> wrote: > > > ** > > > > Since both scenarios are triggered initially by an escalation, I'm > thinking they are both running on the escalation thread. I could be wrong, > but I don't think it matters that the second scenario is doing the push > fields action to form A with a filter, as the initial trigger was an > escalation on form C. If this is indeed the case, it would make sense to me > that it takes longer for process 2 to complete, given the additional layers > of workflow. > > > > One thing I'm curious about in process 2 -- what is the qualification for > the push fields action in the filter that pushes the update to the > display-only field on the ARDBC LDAP form? Is it running unqualified, > pushing the update to every record in the form (which then triggers the > filter that pushes to form A)? > > > > --Thomas > > > > > > > > ----- Original Message ----- > > From: Brian Goralczyk > > Newsgroups: gmane.comp.crm.arsystem.general > > To: [email protected] > > > > > > > > Sent: Thursday, March 20, 2008 3:08 PM > > Subject: Re: Efficiency question > > > > ** > > Thomas, > > > > It is quite possible that having run over it so many times in my head I > was not as thurough as I should have been. > > > > Let me clarrify. There are two possible processes. > > > > Process 1: > > Escalation on the ARDBC LDAP form pushes a copy of every record to form A, > where all the work is performed on the data. This process causes the > escalation to run on ~4500 records and takes ~7 minutes. > > > > Process 2: > > Escalation run on form C. This updates the one record, which causes a > filter to fire that pushes an update to a display only field on the ARDBC > LDAP form. This in turn causes each record to be pushed to form A, again > where all the work is performed on the data. This process causes the > escalation to run on one record and still process the same ~4500 records. > This process takes ~12 minutes. > > > > > > It doesn't take a brain surgeon (which I am not) or a rocket scientist > (which I am also not) to see that option one is the better way to go > performance wise, however; this seems to go against what I have understood > to be one of the advantages of using option 2. > > > > I hope that helps. > > > > Still, > > > > Brian Goralczyk > > > > > > On Thu, Mar 20, 2008 at 1:49 PM, Thomas Bean <[EMAIL PROTECTED]> wrote: > > > > > ** > > > > > > Brian, > > > Perhaps I am having a slow day, but I'm not quite clear on the scenario > you are describing. > > > > > > > > > "I have 4500 records on an LDAP form that need to be updated." > > > Is this an ARDBC LDAP form? Are you wishing to update the original data > from your LDAP data source, or are you attempting to update/transform the > LDAP data as it is imported into another regular form in Remedy? > > > > > > "One [option] is to use an escalation that pushes all the records, or > the other option, to use a form that initiates a push on ALL the LDAP > records to push over to the second form." > > > I'm sure I'm missing something here. These two options sound more or > less identical. > > > With the first option, is this an escalation on the ARDBC LDAP form? > Where is the escalation pushing the records to (if not to the second form > you mentioned)? > > > With the second option, you mention using a "form" to initiate a push... > Is this the aforementioned "second form"? What workflow object is > initiating the push fields action (if not an escalation)? If it is a > filter, which form is the filter attached to, and what are the execution > criteria (execute on, Run If, Push Fields If)? > > > > > > --Thomas > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: Brian Goralczyk > > > Newsgroups: gmane.comp.crm.arsystem.general > > > To: [email protected] > > > Sent: Thursday, March 20, 2008 1:08 PM > > > Subject: Efficiency question > > > > > > ** > > > This is more of a "looking for a consensus or opinions" type email. > > > > > > Running ARS 7.0.01 Patch 2 on a shared windows box that connected to an > Oracle database that is on a different shared box. > > > Using the User Tool but I don't think that matters. > > > > > > The situation: > > > I have 4500 records on an LDAP form that need to be updated. I am > pushing them to another form to perform the work. I have two options. One > of them is to use an escalation that pushes all the records, or the other > option, to use a form that initiates a push on ALL the LDAP records to push > over to the second form. > > > > > > I state that it is an LDAP form to indicate that I am using an external > data source, however; I don't believe that makes a difference. > > > > > > I would believe that option 2 would be quicker as it doesn't use the > single threaded escalation process, however; this is not what I have found > to be the case. There is a discrepancy of 6 minutes with the escalation > taking 7 minutes to run. As you can see, this could be quite worrisome. > > > > > > Any ideas or suggestions or even just straighten me out. > > > > > > Thanks all, > > > > > > Brian Goralczyk__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the > Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where > the Answers Are" html___ > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
