? Forms load test, keystroke files, 2nd commit LONG ?

From: Jennifer R. Amon <bamon_at_ocvaxc.cc.oberlin.edu>
Date: Fri, 21 Jan 1994 08:29:07 -0500
Message-ID: <bamon-210194082907_at_amon.cc.oberlin.edu>


I'm doing a load test on 40+ users using a complex SQL*Forms application. In order to be able to run the test for an extended period of time, the keystrokes all perform a circular set of modifications, leaving the data somewhat the same as they found it, so they can be run again and again.

Here's the Question:

The first time we query up a master/detail set and make a change, the commit takes about 1-3 seconds, and the second time we query the same m/d set and make a change, the commit takes between 30-120 seconds, with most commits falling into the 30-50 second range.

I'm wondering if the second change is forcing the first change to be written to the database from the buffers? I'm really at a loss here. Ideas?

The data looks like this:



| A |
          |_______|            If a significant change is made to
              |                tables C, D, E, or F, then a whole
           _______             new set of rows is inserted into

| B | the tables, committed and the tables
|_______| are re-queried. This is done with an | on-update trigger, that chooses between _______ insert and update on the basis of which
| C | fields have been changed. The tables
|_______| are locked in share update mode for | this change. ___________________ | | |

 _______ _______ _______
| D | | E | | F |
|_______| |_______| |_______|

Thanks in advance for your help.


Jennifer R. Amon            PHONE: (216) 775-6987
Houck Computing Center        FAX: (216) 775-8573
Oberlin College
Oberlin, OH 44074        INTERNET: bamon_at_ocvaxc.cc.oberlin.edu
_____________________________________________________________________
Received on Fri Jan 21 1994 - 14:29:07 CET

Original text of this message