Introduction
Performance testing is used to
determine the speed or effectiveness of a computer, network, product or device.
This process can involve quantitative tests done in a lab under ideal
conditions, such as measuring the response time or measuring the Transactions
per second (TPS) in database at which a system functions.
The ATM benchmark has served as a
database performance evaluation tool for many years. ATM application is
modified according to DataServer. We are running ATM for Oracle and MSS
DataServer
Database Parameters
Server side Parameters
This should be a test of the database
engine, so bottlenecks involving disk I/O, shared memory, and the BI need to be
eliminated. For each machine we assessed
the amount of free memory available, and the amount of disk space
available. The following guidelines were
used:
Load the entire database into shared
memory. If this is not initially
possible, change the SCALE of the
database to a smaller number so that the database can totally reside in shared
memory.
SCALE - Database
size to load (10)
NUMLOADERS - Number of
load processes (4)
CLSZ
- BI cluster size (196608 KB)
BIBSZ - BI block size ( 16 KB)
NUMAPW - Number of APW’s
-n - number of users 200
-L - Lock table size 10240Kb
-B - Database buffer pool Size 64000
-bibufs - BI
Buffer Size 300
-spin - 5,000 times the number of CPUs on the
machine.
-napmax - 65
-rand - randome
number generator (1)
Client Side parameters
The standard ATM client parameters
specify the use of –rand 2 for the
type of random number generator. A value
of 1 (the default) indicates that OpenEdge should use the original generator;
specify a value of 2 to use the alternate.
The original number generator always generates the same random sequence;
that is, the numbers that it generates are random, but each time a session
starts, it gives you the same set of numbers from the last session. If you have to generate a different sequence
of random numbers, specify the alternate generator. This generator returns a number from a pseudorandom
sequence of numbers rather than a truly random sequence.
All the clients run the application
with ‘-b’ option i.e in batch mode.
Tuning Tips for Databases
- Place the OpenEdge installation
on a different file system
- Database files and bi files on should
be on different file systems
- Fit the entire database into
shared memory. If there is not
enough shared memory available, use the SCALE factor to reduce the size of
the database so that it will fit.
- DB Reads (promon) should be
below 200 per second.
- Checkpoints (promon R&D)
should occur no frequently than once per minute, and preferably once every
two minutes.
- Buffer hits (promon) should be
99%.
- Waits for Record Locks (promon)
should be less than 5%.
- Waits for BI Buffers (promon)
should be less than 5%.
- Writes by APW should be greater
than 95%.
- Writes by BIW should be greater
than 95%.
Tuning Tips for Operating Systems
The best practices to manage Windows
System/Services
- Put the huge application services in manual mode and you
may stop them if they are not required. Ex Oracle Service, SQL server,
Progress Adminserver etc.
- We may disable un necessary services running on the
machine.
- Put the services you want to stop in manual mode. Other
wise they will restart on reboot.
- We can defragment the Disk partitions (type “dfrg.msc”
from run prompt) for better performance and space management inside the
Disk.
- System clean up also works good and cleaning the
unnecessary stuff from temp folder and recycle bin. (type “cleanmgr” from
run prompt)
(we can do this disk defragment and
disk clean up stuff once in a month, else
it can be scheduled it as well)
No comments:
Post a Comment