Mary, NM stands for Network Management, but in truth, it is any external system that is generating high volume in a single form, be it Network Management, Web Services, scripts, anything that creates records. I've even blocked myself with multiple escalation threads creating records in the same forms.
I would agree with Rick that in 'standard' situations, where you have low volume, and or no automation that creates high volumes of records, you are at little risk of needing this setting. If however you are needing high concurrency of simultaneous submits with some integration, then you may come up against this problem. In your example below you said that you had 10 instances of the script running simultaneously, but were only using 2 threads. I don't know if you realize it or not, but the net effect of your testing was actually only running 2 scripts simultaneously, while the other 8 sat in queue until one of the threads was available, then the next was processed. If you want to truly run them simultaneously, you will need to increase your thread counts to values that allow all instances to run at the same time. With that said, if 10 concurrent is not an actual expected value that NEEDS concurrent processing, then 2 threads should generally be able to handle 10 requests within the specified timeframe without error, but don't confuse yourself into thinking that they are running simultaneously :) To answer your last question, yes, you can change the setting per form in the Form Properties. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mary Dollus Sent: Tuesday, September 11, 2012 8:17 AM To: arslist@ARSLIST.ORG Subject: Re: Changing Next ID Block Size - anything to be aware of? Rick, Thanks so much Rick! And yes that is our issue... we send out enormous amounts of email, so the AR System Email Message form gets hit pretty hard and the system was tied up creating the New ID's and yes, caused performance issues... Were you able to do any testing in 7.6.04? And yes, we are considering this based on a recommendation from BMC.... Here are the results of our testing so far: ["No gaps were created under the test conditions which involved running 10 instances of the script simultaneously. Tricia used the xxxx application on the 7.6 system, and there were only 2 fast/2 list threads. One thing observed was that when Tricia changed the next id block size from 25 down to 1, a gap of several IDs occurred. The Remedy documentation says that a restart of ARS can result in gaps. This appears to be caused because the reserved block of IDs is in memory and this is lost when restarting ARS, or in this case also when the AR configuration change occurred. So, we can expect gaps if arserverd crashes or is restarted, but perhaps it is unlikely otherwise."] Sorry if this is a dumb question,,, but in your comment below, what does "MULTIPLE NM" mean... and are you saying it is possible to add the next ID increase to ONLY that form? and not a global change for all forms? "[Your comment from below] So if you have MULTIPLE NM apps feeding the SAME form at the SAME time with LOTS of records (thousands/day), then yes, you should increase the setting for THAT form to a higher number. " Thanks!! Mary ******************** Mary, I did some extensive research on the Next-ID-Block size setting in 7.5 a couple years ago. That research involved formal performance testing and conversations with BMC Engineers about the results I found. The results were that it didn't help. In fact, performance was actually diminished in over half of the cases. Maybe that was due to unrelated traffic, but at very least I can say that there was no noticeable improvement with the settings at anything above 1. The word from BMC when this feature was released was that it was in response to multiple Network Management applications (i.e. Patrol, Netcool, HP, Tivoli, etc.) feeding large number of records into the same form on the same AR Server at the same time. This caused contention for SQL pulls of the Entry ID, which was causing performance issues. The problem is that BMC, for some reason, is recommending increasing that number to something above 1 as a default setting, without apparent justification for that recommendation. I have seen nothing that has changed the justification for the setting beyond the initial requirement. I have seen nothing to indicate that either the function or the rationale have changed in 7.6x. So if you have MULTIPLE NM apps feeding the SAME form at the SAME time with LOTS of records (thousands/day), then yes, you should increase the setting for THAT form to a higher number. If you are not, then you shouldn't. The cost is far greater than any benefit you might see. Rick On Tue, Sep 11, 2012 at 9:27 AM, Mary Dollus <mary.t.dol...@saic.com> wrote: Hi Everyone, We are going to set our Next ID Block size from 1 to 25 due to some issues we had last week with our AR System Email Messages form tying up the system. We did some initial testing and it seems like there shouldn't be any issues. Is there in anything particular we need to look out for? Has anyone noticed any gaps in the Request ID sequencing and if so, to what extent? What is your environment if you noticed issues? Do you use a server group? and what was the value of your Next ID Block size? Thanks so much in advance!! Mary Dollus ARS 7.6.04 Oracle/UNIX _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"