Joe/Mark, did your testing show any performance increase as a result of this change? My tests seem to indicate the opposite, though not to any substantial degree.
Rick On Fri, May 9, 2008 at 11:25 AM, Rick Cook <[EMAIL PROTECTED]> wrote: > Thanks, Mark. The count is set per server, then there's a check box on > each form to enable it to use that server number. > > We'll have to evaluate whether having Entry IDs/Create Dates out of sync is > worth the performance increase. I suspect that it will be, but we may still > have to check our apps and users to ensure no one gets hosed in the > trade-off. > > Rick > > > On Fri, May 9, 2008 at 11:07 AM, Walters, Mark <[EMAIL PROTECTED]> > wrote: > >> When this setting is enabled the server will increment the nextid count in >> the arschema table for the form by the configured number. Once the server >> has allocated all the ids the next block is fetched. If the server is >> terminated for any reason, intentionally or otherwise, any unused ids will >> be discarded and there will be a gap in the request id sequence in the form. >> If you're using a server group and each server is using the feature there >> is increased potential for these gaps to occur. Each server is independant >> in the use of this feature - you could have servers using different values >> for the nextid block or a mix of servers with the setting enabled and >> disabled. The next id count can also be set per form if I recall correctly >> (don't have the docs handy). >> >> The occurrence of gaps in the request id sequence has always been a >> possibility - consider the case of a heavily used form with mutliple users >> running submits. If the workflow that creates a new record has conditions >> that may cause the submit to be cancelled the transaction would be backed >> out and, if subsequent submits had already started, this would result in a >> gap. >> >> Mark >> >> ________________________________ >> >> From: Action Request System discussion list(ARSList) on behalf of Rick >> Cook >> Sent: Fri 09/05/2008 17:32 >> To: [email protected] >> Subject: Next ID Blocks in Server Groups >> >> >> ** We are upgrading to AR System 7.1 (no ITSM - all custom apps), and are >> looking at the potential performance gains of using the pre-allocated nextId >> blocks. >> >> I attended the BUW session where they talked about the optimal setting >> being about 100 for heavily used forms, but I got to thinking "What would >> happen in a fail-over situation? How do the servers play together with >> those pre-allocated blocks?" My thought was that at worst, the allocated >> but as yet unused portion of the block would be discarded, and a new one >> would be spawned on the new primary server, leaving ID gaps of between 1 and >> 99. That, we could live with. >> >> While digging through the 7.1 docs, I read this little gem in the O&T, >> which seems to sort of obliquely reinforce my opinion: >> >> The use of this configuration setting could result in unpredictably large >> NextID sequence gaps. The likelihood of this occurring increases with the >> use of multiple servers that share a database. The AR System server will not >> malfunction due to this gap and should not be considered a defect. >> >> Has someone been through this exercise who could offer some insight into >> whether there might be other issues to be aware of? Is this a setting that >> could be different for different servers in a group (not that I know why one >> WOULD, but...)? >> >> Also, I found it a bit disturbing that the documentation said to adjust >> this value in the ar.conf file when there is a setting in the Administration >> form for it (which the doc does not mention). They probably just didn't >> update that from 7.0.1, but it does tend to make one wonder about the >> completeness of the rest of the information. >> >> Rick >> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> html___ >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
