I don't think you'll see the true benefit until you test it with several threads submitting records at the same time. That's when the contention on the arschema table will become a bottleneck. And as fast as that SQL call is, you may need LOTS of threads very quickly submitting LOTS of records.
We saw problems with contention on this back in 6.3. The real problem was actually a very slow and poorly configured SAN for our database system, along with very fragmented tables. But the end result was long waits and blocked processes at the database while arschema was being updated that led to slow response or even timeouts for our end users while they submitted records. A bigger, better, faster SAN configuration took all of our problems away, but I'm confident NextID blocks would have helped us. I just upgraded to 7.0.1 and used NextID blocks on a few major forms, but unfortunately I didn't benchmark anything before or after. Chad Hall (501) 342-2650 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Wednesday, May 28, 2008 3:14 PM To: arslist@ARSLIST.ORG Subject: Re: Next ID Blocking = faster submits? ** I could do that, Axton, but I wanted to test the increase in performance of just the NextID blocking. Unless there's something that says that none of these new features will benefit us without enabling them all, I would like to evaluate them individually and in smaller sets before I do them all. Rick On Wed, May 28, 2008 at 1:08 PM, Axton <[EMAIL PROTECTED]> wrote: What about performing the same test creating a series of entries on separate threads. Then break down the results based on the thread count. Axton Grams On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote: > ** I've been doing some testing to see how much this really helps > performance, and my preliminary numbers were surprising and disappointing. > NOTE: I don't think a single sample is enough from which to draw a global > conclusion. HOWEVER...I am concerned enough to ask some questions. > > I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1 > p2, same code, same DB version, same code and similar (but separate) > databases. > > I ran an Escalation that submits hundreds of records into a relatively small > form (perhaps 25 fields) that previously contained no records. There was no > other load or user on either server. > > Server A is set up without the NextId blocking. > Server B is set up WITH the NextId blocking set for 100 at the server level > but NOT on the form itself, threaded escalations, and the Status History > update disabled for the form in question. > > I went through the SQL logs and tracked the time difference between each > "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry. > The results? > > Server A: Each fetch of single NextIds was separated by an average of .07 > seconds, which is 7 seconds per hundred. > > Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4 > seconds per entry (hundred). A second run showed an average of 12.8 > seconds, so I'm fairly confident that's a good number. The fastest was 5.3 > seconds, the slowest almost 40 seconds. > > Then just to eliminate the possibility that the environments were the issue, > I turned on the NextId blocking on Server A to the same parameters I had set > for Server B. Result? Average of 8 seconds per hundred, though if I throw > out the first two gets (which were 11 sec. ea), the remaining runs average > around 7.25 seconds per hundred. Even in a best-case scenario, it's still > slightly slower than doing it singly. > > The median value between the values in all three sets across two servers was > 8 seconds. The mean value is 11 seconds. Again, the time it takes to "get" > 100 NextId updates 1 at a time was 7 seconds per hundred. > > So the newer, "faster" feature actually appears no faster, and in some cases > slower, than the process it's supposed to have improved. > > Maybe it's not hitting the DB as often, but then why are we not seeing the > omission of 99 DB calls reflected in faster overall submit times at the AR > System level? Am I doing something wrong? Are my expectations > unreasonable? Is there some data in a white paper or something that shows > empirically what improvements one should expect from deploying this new > functionality? > > Is anyone seeing improved performance because of this feature? I don't see > it. > > 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" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
