Performance Metrics > SQL Read Test

SQL Read Test

Where located: AGRIS\Bin\agris.sql.loadtest1.exe (Or in AGRIS > Utilities > Diagnostics > Performance Metrics > Read)

Sample results:

Interpreting results:

• Larger calls/sec are more desirable.

• 800 calls/sec: This is the bottom threshold for what we would consider acceptable performance.

• 1100 calls/sec: This should be seen as about average.

• 1400 calls/sec: This represents the higher end of performance, generally speaking, when gauging ‘roundtrips’ for a single SQL record from a client to a SQL server using this utility.

• If running the utility directly on the SQL server (or standalone instance), results in the 4000 calls/sec range are more commonly observed.

Advanced Information:

This command can be used to run the read test in an unattended mode and record the output to a file: agris.sql.loadtest1.exe >> readtest.txt

The above command from agris\bin will output results to agris\bin\readtest.txt file.
>> indicates to append rather than overwrite.
> would indicate to overwrite if desired.

You could then open notepad++ and do a replace operation (with search mode set to 'regular expression') with these values:

Find what: Calls: \d+ Errors: 0
Replace with: (leave empty)

This would return results such as these:
Calls/sec: 4366
Calls/sec: 3687
Calls/sec: 3624
Calls: 23231 Errors: 1 Calls/sec: 4560
Calls/sec: 4898

This should make it easier to identify if errors occur. (Search for 'errors')

From here you could do another Find/replace:

Find what: Calls/sec: \b(?:[1-9][0-9][0-9][0-9])\b
Replace with: OK

This would return results where calls/sec are less than 1000:
OK
OK
OK
Calls/sec: 155
OK

If you are running the read test unattended, you can determine timestamps as long as you know when the report was started by using row numbers. Dividing a row number by 60 will tell you how many minutes into the process the row occurred. Divide by 60 again if you want to know how many hours into the process the row occurred.

Additional scenarios to consider when using this utility:

• If I manually browse to and run \AGRIS\Bin\AGRIS.SQL.LoadTest1.exe, then it references the default AGRIS\Bin\dbconnections.config file.

• If I launch an AGRIS session that uses the default dbconnection.config file, then it also uses the connection specified in the default dbconnection file.

• Things change if I launch an AGRIS session that uses an alternate AGRIS.ini/dbconnections.config combo. In this scenario, it will use the connection found in the alternate dbconnections.config file (but a ‘default’ dbconnections must be present in the Bin directory even if that default file is not correctly configured).