I believe the "improvement" performance is for multiple concurrent users (100+) submitting entries to the same form. This option may not work best for single user.
AF. On Wed, May 28, 2008 at 1:13 PM, Rick Cook <[EMAIL PROTECTED]> wrote: > ** 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___ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
