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"
