They market their apps. If I had,to wager a bet, I would wager that their apps operate better, en mass, with the new default settings. On Oct 12, 2011 12:02 PM, "Rick Cook" <remedyr...@gmail.com> wrote:
> ** I agree with your technical dissection of the construct, Axton. When I > presented my findings to BMC a few years ago, their engineers basically said > the same thing. I have no problem with the idea behind it, or its > function. It certainly has a real value to a relatively few larger > customers who pump thousands or tens of thousands of entries into their > Remedy systems daily. > > But that's where the value ends, IMO. I therefore don't understand why BMC > made this setting (value depends on the version) the default across all > forms, since it messes up, or presents the potential to mess up, other > things. These aren't big things, but they are anomalies in say, the > synchronization between Entry ID and Create Date, or the possibility of > missing Entry IDs, that are introduced with no corresponding value add. I > would like to see BMC explain their decision to apply OOB settings for all > customers that really offer value only to a very small percentage of their > customers. > > Rick > > On Wed, Oct 12, 2011 at 9:50 AM, Axton <axton.gr...@gmail.com> wrote: > >> ** If one transaction updates arschema.nextid, does it's other processing, >> then commits, any subsequent update to that row in arschema will be blocked >> until that commit on the initial transaction completes. This will occur if >> "Next-ID-Commit:F", which is the default on 7.5. It's not a big issue >> until you start trying to create a lot of new records on a single form using >> multiple threads. When you have that condition, setting the above to T >> (which is non-issue when NextID-Block-Size > 1 is defined) will have a >> drastic impact on throughput. The higher the concurrency, the larger the >> impact. Common examples of high concurrency would include many users >> submitting incidents; distributed clients that all send data to your remedy >> server at the same or near same time, etc. >> >> None of this is a deal breaker until the time to wait exceeds the timeout, >> at which point things really break. The worst case, up to the point of >> breaking, is lower throughput. >> >> I don't have any numbers to offer; this is all speculation on my part >> based on my understanding of how these things work. Numbers would be nice, >> wish I had the time to draw some up. >> >> Axton Grams >> >> On Wed, Oct 12, 2011 at 10:17 AM, Rick Cook <remedyr...@gmail.com> wrote: >> >>> ** Well of course there is the potential for contention, the question is >>> whether that contention causes any kind of noticeable latency and whether >>> the solution is better than the problem. Within that context, does the >>> scenario I laid out below have a logical flaw? >>> >>> >>> Rick >>> >>> On Wed, Oct 12, 2011 at 8:08 AM, Axton <axton.gr...@gmail.com> wrote: >>> >>>> ** If you have more than 1 thread, you have a potential for resource >>>> contention. On seperate threads you can create an entry in the same form. >>>> If each transaction has to update/commit the same record in arschema, you >>>> can get a bottleneck. By managing the numbers in memory (versus the db), >>>> you can fetch and use a block of IDs, thus alleviating the contention on >>>> the >>>> record in arschema. >>>> >>>> Axton Grams >>>> >>>> On Wed, Oct 12, 2011 at 9:20 AM, Rick Cook <remedyr...@gmail.com>wrote: >>>> >>>>> ** Mark, isn't that bottleneck only an issue when multiple sources >>>>> (such as NMS) are attempting to submit multiple entries to the same form >>>>> at >>>>> the same time? That was the initial problem that the Next-ID block was >>>>> added to alleviate. If so, I fail to see the value-add to making a larger >>>>> value than "1" a global setting. And if a company has a low volume of >>>>> records without the streaming issue above, what is the value add at all? >>>>> >>>>> >>>>> This seems like a global answer for a problem very few companies are >>>>> having. >>>>> >>>>> Rick >>>>> >>>>> >>>>> On Wed, Oct 12, 2011 at 3:32 AM, Walters, Mark >>>>> <mark_walt...@bmc.com>wrote: >>>>> >>>>>> Before the block size option was introduced there was a potential >>>>>> bottleneck on the arschema table when a large number of records were >>>>>> being >>>>>> created as each new record needed to update the nextId for the form in >>>>>> this >>>>>> table. The default behavior was to update the nextID to get the new >>>>>> request >>>>>> id but not to commit this change until the new record creation completed. >>>>>> If there was a lot of workflow run during the submit this could cause a >>>>>> performance problem as threads would be unable to get at the arschema >>>>>> table >>>>>> until the thread that was using it completed its transaction. >>>>>> >>>>>> When the Next-ID-Commit setting was enabled this caused the server to >>>>>> issue a commit as soon as it had updated the nextID, thereby releasing >>>>>> the >>>>>> arschema table for other threads to use. >>>>>> >>>>>> Now that we have next id blocks the arschema table is only updated >>>>>> when the block is refreshed so there original setting is redundant in >>>>>> this >>>>>> case. >>>>>> >>>>>> The default for Next-ID-Commit is FALSE in 7.6.04. >>>>>> >>>>>> From the 7.6.04 config guide; >>>>>> >>>>>> Next-ID-Commit: >>>>>> >>>>>> Flag indicating whether to perform a new commit transaction when the >>>>>> system generates the next ID for a record in the database. Values are >>>>>> T—Perform a new commit transaction. To increase efficiency and >>>>>> for debugging, use this value. >>>>>> F—(Default) Include the transaction to generate the next ID in >>>>>> the create entry transaction. >>>>>> >>>>>> This option does not work with Informix databases. >>>>>> >>>>>> Note: Next-ID-Block-Size replaced Next-ID-Commit, but Next-ID-Commit >>>>>> is available for backward compatibility >>>>>> Next-ID-Block-Size Option that allocates next IDs in blocks instead of >>>>>> one at a time. >>>>>> >>>>>> From a quick test setting the block size to 1 for a form and then >>>>>> setting Next-ID-Commit to T works as you would expect and commits the >>>>>> update >>>>>> to arschema after incrementing the nextId. >>>>>> >>>>>> mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Action Request System discussion list(ARSList) [mailto: >>>>>> arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>>> Sent: 12 October 2011 10:16 >>>>>> To: arslist@ARSLIST.ORG >>>>>> Subject: Re: Next Request ID Block Size - Info required >>>>>> >>>>>> Hi, >>>>>> >>>>>> If I understand you correct, if you have the Next-ID-Block-Size set to >>>>>> a value greater than 1, the Next-ID-Commit has no relevance. >>>>>> >>>>>> Why make a Next-ID-Commit default of "T" and Next-ID-Block-Size of >>>>>> "25" >>>>>> the default in that case? >>>>>> >>>>>> If I want a unbroken serial on one form, I guess I can do something >>>>>> like this without impacting performance on anything else: >>>>>> Next-ID-Block-Size:25 >>>>>> Next-ID-Commit:F >>>>>> Form-Specific-Next-ID-Block-Size:1 (form property via DevStudio) >>>>>> >>>>>> This would give me what I want, and the 25 would make any other form >>>>>> work with the same performance benefits as the 7.6.04 default setting. >>>>>> Right? >>>>>> >>>>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP >>>>>> 2011) >>>>>> >>>>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >>>>>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>>>>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>>>>> logs. >>>>>> Find these products, and many free tools and utilities, at >>>>>> http://rrr.se. >>>>>> >>>>>> > Sorry, nothing on that one. >>>>>> > >>>>>> > I must admit I've never really understood the requirement to have >>>>>> > linear request ids. That's not to say there's not a good reason you >>>>>> > might want to do this but I don't see the need. There has never >>>>>> been >>>>>> > a guarantee that there would be no gaps in the sequence - a failed >>>>>> > submit may leave a gap for example - and this has always been the >>>>>> case. >>>>>> > >>>>>> > The Next-ID-Commit was introduced as a performance tweak to reduce >>>>>> > contention on the arschema table when the nextId was being >>>>>> incremented. >>>>>> > If you're using next id blocks it is redundant as the call to >>>>>> > increment the nextId is only made when the server has used all the >>>>>> ids >>>>>> > in the block and needs to get the next chunk, not on every record >>>>>> submit. >>>>>> > >>>>>> > Mark >>>>>> > >>>>>> > -----Original Message----- >>>>>> > From: Action Request System discussion list(ARSList) >>>>>> > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>>> > Sent: 12 October 2011 08:29 >>>>>> > To: arslist@ARSLIST.ORG >>>>>> > Subject: Re: Next Request ID Block Size - Info required >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > You learn something new every day, right :-) >>>>>> > >>>>>> > What about the Next-ID-Commit on a per-form-basis? That would be >>>>>> > equally important if you want your IDs in a straight line. >>>>>> > >>>>>> > Best Regards - Misi, RRR AB, http://rrr.se >>>>>> > >>>>>> >> Next-ID-Block-Size can be set per form - it's an option that can be >>>>>> >> enabled under Form, Properties. >>>>>> >> >>>>>> >> Mark >>>>>> >> >>>>>> >> -----Original Message----- >>>>>> >> From: Action Request System discussion list(ARSList) >>>>>> >> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>>>>> >> Sent: 12 October 2011 07:30 >>>>>> >> To: arslist@ARSLIST.ORG >>>>>> >> Subject: Re: Next Request ID Block Size - Info required >>>>>> >> >>>>>> >> Hi, >>>>>> >> >>>>>> >> What happens is that each thread will reserve 10 numbers at a time. >>>>>> >> >>>>>> >> This means that thread "1" will create something like number 15-24, >>>>>> >> and that the next thread will get 25-34 etc. >>>>>> >> >>>>>> >> This also means that the creation time of record 25 may be prior to >>>>>> >> lets say 18. >>>>>> >> >>>>>> >> In pre 7.6.04, the default value was 1, but it is now 25, which is >>>>>> a >>>>>> >> big change. >>>>>> >> >>>>>> >> Another important thing is the Next-ID-Commit setting, that will >>>>>> make >>>>>> >> sure that a number is not used until the record hits the database. >>>>>> >> >>>>>> >> New default settings from ar.cfg/conf in 7.6.04: >>>>>> >> Next-ID-Commit:T >>>>>> >> Next-ID-Block-Size:25 >>>>>> >> >>>>>> >> Default values från earlier version: >>>>>> >> Next-ID-Commit:F >>>>>> >> Next-ID-Block-Size:1 >>>>>> >> >>>>>> >> It would be very nice if you could set this on a per form basis. I >>>>>> >> know many instances where you want to keep your request ids both >>>>>> >> straight and strict... >>>>>> >> >>>>>> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList >>>>>> MVP >>>>>> >> 2011) >>>>>> >> >>>>>> >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): >>>>>> >> * RRR|License - Not enough Remedy licenses? Save money by >>>>>> optimizing. >>>>>> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>>>>> >> logs. >>>>>> >> Find these products, and many free tools and utilities, at >>>>>> >> http://rrr.se. >>>>>> >> >>>>>> >>> Hi All, >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> I need your help to understand the form property "Next Request ID >>>>>> >>> Block Size". What I understood if I enable this property and set >>>>>> it >>>>>> >>> to as say 10. I would get request id as 2,12, 22,32 on the >>>>>> >>> subsequent created request on that form. But it did not happen >>>>>> that way. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> Could any expert please throw a little light on this form property >>>>>> >>> and use of it. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> PS: We also have similar setting on Server Information form, I >>>>>> guess >>>>>> >>> that is for setting globally for all forms and can be overwritten >>>>>> >>> for a particular form using form property. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> Please correct me if I am wrong >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> Ashutosh >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> Think green - keep it on the screen. >>>>>> >>> >>>>>> >>> This e-mail and any attachment is for authorised use by the >>>>>> intended >>>>>> >>> recipient(s) only. It may contain proprietary material, >>>>>> confidential >>>>>> >>> information and/or be subject to legal privilege. It should not be >>>>>> >>> copied, disclosed to, retained or used by, any other party. If you >>>>>> >>> are not an intended recipient then please promptly delete this >>>>>> >>> e-mail and any attachment and all copies and inform the sender. >>>>>> Thank you. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> ____________________________________________________________________ >>>>>> >>> _ _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>>> >>> www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the >>>>>> >>> Answers Are" >>>>>> >>> >>>>>> >> >>>>>> >> >>>>>> _____________________________________________________________________ >>>>>> >> _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>>> www.arslist.org >>>>>> >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> >> >>>>>> >> >>>>>> _____________________________________________________________________ >>>>>> >> _ _________ UNSUBSCRIBE or access ARSlist Archives at >>>>>> www.arslist.org >>>>>> >> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> >> >>>>>> > >>>>>> > >>>>>> ______________________________________________________________________ >>>>>> > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>>> > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> > >>>>>> > >>>>>> ______________________________________________________________________ >>>>>> > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>>> > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> > >>>>>> >>>>>> >>>>>> _______________________________________________________________________________ >>>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend >>>>>> wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> >>>>>> >>>>>> _______________________________________________________________________________ >>>>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>>>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" >>>>>> >>>>> >>>>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>>>> >>>> >>>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>>> >>> >>> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >>> >> >> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ >> > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
