One of the tricks that I have found to help is to look at the number of records that are in the table and how many are returned by your escalation. Then decide what is being done to them and does it need to be single threaded? If not, and you just need the escalation to schedule the work it might be something that you can turn multi-threaded in the way it runs by having an escalation for that has one record and performs a push to all the matching records.
I can go into this deeper if anyone prefers. But it can definitely improve the performance of escalations. Brian Goralczyk On Tue, Aug 19, 2014 at 1:15 PM, Doug Blair <[email protected]> wrote: > ** > Mahmoud, > > I have done quite a bit of fiddling with just this situation. > > Simply put, out-of-the-box the Escalation process is single threaded, > which means that with no further adjustments only one escalation can > operate at any given time. A long running escalation will delay the start > of others, and a very long running escalation can cause some cases of the > shorter ones to be skipped entirely. > > To fix this you can add threads to the escalation process (390603). This > will allow more than one escalation to run at the same time. This will > allow more of your escalations to complete without blocking each other, but > still might allow some to be delayed. > > There is also the chance that some escalations depend on other escalations > to be completed before they will do what is expected. The notification > engine has a couple cases like this. These sorts of escalations can be > grouped together using escalation pools. > > Please do not be tempted to add one thread or pool for every escalation! > That would work, but would waste a lot of resources and potentially slow > things down. You will need to turn on escalation logging and see how many > escalations are ready too fire each minute, then adjust the number of > threads so that more of them will fire and complete. Then group the ones > which should not be blocked into unique pools. You can experiment with all > of these pools and threads a bit, and remember that each thread, whether in > an escalation queue or any other queue will tax the system somewhat. You > want those threads to be mostly busy, and for there to be at least one > thread/pool combination to be available every minute for your essential one. > > One way to be certain this happens might be to isolate your critical > escalation in a pool by itself (let’s say pool 3), set your escalation > threads to 3, and set all the other escalations to either pool NULL (which > is the default) or pools 1-2. Anything in pool 1 or 2 will run on one of > the first two available threads, and your essential one will be the only > thing that runs in thread 3. > > You might have several escalations which need to fire every minute. As > long as those don’t take a long time to run they could be all in the same > pool. If you find that running all the escalations assigned to pool 3 takes > longer than a minute, you’ll need to look at more threads or more pools. > > You can also investigate scheduling of the escalations. It is very common > to find that a lot are scheduled to run at :00 in each hour (the default > value). Perhaps some of these can be mored to another time so they do not > all trigger at once. > > All that said, there is also the possibility that some of your escalations > might be poorly written and just be doing things very inefficiently. Look > closely at the RUNIF qualifications of those that seem to take a long time > to complete, and turn those just as you would an inefficient filter > qualification or search for a report or other lookup… > > Hope this helps! > > Doug Blair > > > On Aug 19, 2014, at 4:04 AM, Mahmoud Mahdy-Mohamed, Vodafone Egypt < > [email protected]> wrote: > > ** > Dears, > Kindly help as I’m facing a critical issue, the escalations are running > randomly regardless the execution time that it should execute in. For > example I have escalation that has to run every *minute* however it is > running after *30 min* which causes a delay in other related work flows. > Note:- I’m using 7.6.04 SP4 > > *Thanks,* > *Best Regards,* > > *Mahmoud Mahdy Mohammed,PMP* | Business Process Automation > *Technology | Products & Services Delivery* > *Phone:* +20(0)1004999638 > *Mail:* *[email protected] > <[email protected]>* > > > > ************************************************************************************************************************* > > The content of this document is classified as Vodafone Egypt S.A.E. > Confidential and Proprietary Information. > > The recipient hereby is committed to hold in strict confidence the > contents of this (e-mail, document, information) and not to disclose to any > third party without the prior written consent of Vodafone Egypt S.A.E. > Recipient will be held liable for any unauthorized disclosure. > > If you have received this message in error, please notify the sender by > return e-mail and delete the message in its entirety, including any > attachments. > > http://www.vodafone.com.eg > > > ************************************************************************************************************************* > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > Doug > > -- > Doug Blair > [email protected] > +1 224-558-5462 > > 1208 East Fremont Street > Arlington Heights, Illinois 60004 > > > > ITILv3 > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
