Thanks Rick! I actually don’t care whether they reserve the block or not as long as they allow us to access the info what the next Id is. It could be a special workflow action or at least an API call. I really don’t get why is that so difficult to provide?
> On 12. Oct 2017, at 22:42, Rick Cook <remedyr...@gmail.com> wrote: > > ** > 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" <tmisk...@gmail.com> 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 <lj.longw...@gmail.com> 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 <tmisk...@gmail.com> >>>> 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_ > _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"
