Here's the skinny on that. I got this from the engineer who built that feature, btw.
The problem was that system performance was being constricted around the action of getting the NextId for a record when multiple sources (say, Netcool and HPOV) were throwing tons of requests at the (Incident) form at the same time. The process of getting each Next Entry ID in individual DB calls was bottlenecking the process of creating the records. So that's why BMC came up with a way to pre-allocate those in bulk, so that only every N times (whatever the number is set to) would an actual call to the DB to get Next IDs be necessary. The transaction time to retrieve 1 or 100 wasn't much different, and those customers with multiple programs requiring many simultaneous record creations saw a marked performance increase. It was, and is, a good feature add. So (then a miracle occurs) and BMC announces that this particular corner case had a solution that everyone should benefit from, and announced that the number should be 100 for *all* customers. I tested this back in 7.6.04 against a RH server, with settings at 1, 10, 100, and 1000, and found that performance was actually NEGATIVELY affected the higher the number was set. It wasn't a huge difference (10%~), but it was a clear, repeatable one for which BMC's engineer had no explanation. It is why I have always advocated that unless a customer has the specific set of circumstances that caused the feature to be beneficial, there is no real benefit to setting the number larger than 1. And there are minor drawbacks to doing so, the current subject being one of them. Every time I ask someone from BMC to justify a larger number to the average customer, they repeat the party line, unaware of the history behind the feature. I will continue to tilt at this windmill until someone at BMC shows me some performance testing numbers that justify this setting for the entire customer base. Rick On Oct 12, 2017 13:30, "Thomas Miskiewicz" <[email protected]> wrote: > ** > i.e. there is no hack to find out the nextID before it actually gets > submitted? > > Apart from that, I really don’t understand why BMC makes such a fuss > around the nextID. Why can’t they just provide a special command GET-NEXTID? > > > Thomas > > > On Oct 12, 2017, at 10:26 PM, LJ LongWing <[email protected]> wrote: > > ** > There are no interfaces that I'm aware of to ask a specific server what > the next id it will hand out for a specific form is > > On Thu, Oct 12, 2017 at 2:14 PM, Thomas Miskiewicz <[email protected]> > wrote: > >> Hello List, >> >> with NextID Block size being set to 100 —> is it possible the find out >> using the API which will be the next Request-ID that the server will assign >> to a request? Or what other options do I have to find out? >> >> >> --Thomas >> >> ____________________________________________________________ >> ___________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _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"
