throughput.so

berkeley db 4.6.21的源码。berkeley db是一个简单的数据库管理系统

m4_comment([$Id: throughput.so,v 10.31 2002/04/02 17:07:05 bostic Exp $])

m4_ref_title(m4_tam Applications,
    Transaction throughput,
    @transaction throughput, transapp/tune, transapp/faq)

m4_p([dnl
Generally, the speed of a database system is measured by the
m4_italic(transaction throughput), expressed as a number of
transactions per second.  The two gating factors for m4_db performance
in a transactional system are usually the underlying database files and
the log file.  Both are factors because they require disk I/O, which is
slow relative to other system resources such as CPU.])

m4_p([dnl
In the worst-case scenario:])

m4_bulletbegin
m4_bullet([dnl
Database access is truly random and the database is too large for any
significant percentage of it to fit into the cache, resulting in a
single I/O per requested key/data pair.])
m4_bullet([Both the database and the log are on a single disk.])
m4_bulletend

m4_p([dnl
This means that for each transaction, m4_db is potentially performing
several filesystem operations:])

m4_bulletbegin
m4_bullet([Disk seek to database file])
m4_bullet([Database file read])
m4_bullet([Disk seek to log file])
m4_bullet([Log file write])
m4_bullet([Flush log file information to disk])
m4_bullet([dnl
Disk seek to update log file metadata (for example, inode information)])
m4_bullet([Log metadata write])
m4_bullet([Flush log file metadata to disk])
m4_bulletend

m4_p([dnl
There are a number of ways to increase transactional throughput, all of
which attempt to decrease the number of filesystem operations per
transaction.  First, the m4_db software includes support for
m4_italic(group commit).  Group commit simply means that when the
information about one transaction is flushed to disk, the information
for any other waiting transactions will be flushed to disk at the same
time, potentially amortizing a single log write over a large number of
transactions.  There are additional tuning parameters which may be
useful to application writers:])

m4_bulletbegin

m4_bullet([dnl
Tune the size of the database cache.  If the m4_db key/data pairs used
during the transaction are found in the database cache, the seek and read
from the database are no longer necessary, resulting in two fewer
filesystem operations per transaction.  To determine whether your cache
size is too small, see m4_link(M4RELDIR/ref/am_conf/cachesize, Selecting
a cache size).])

m4_bullet([dnl
Put the database and the log files on different disks.  This allows reads
and writes to the log files and the database files to be performed
concurrently.])

m4_bullet([dnl
Set the filesystem configuration so that file access and modification times
are not updated.  Note that although the file access and modification times
are not used by m4_db, this may affect other programs -- so be careful.])

m4_bullet([dnl
Upgrade your hardware.  When considering the hardware on which to run your
application, however, it is important to consider the entire system.  The
controller and bus can have as much to do with the disk performance as
the disk itself.  It is also important to remember that throughput is
rarely the limiting factor, and that disk seek times are normally the true
performance issue for m4_db.])

m4_bullet([dnl
Turn on the m4_ref(DB_TXN_WRITE_NOSYNC) or m4_ref(DB_TXN_NOSYNC) flags.
This changes the m4_db behavior so that the log files are not written
and/or flushed when transactions are committed.  Although this change
will greatly increase your transaction throughput, it means that
transactions will exhibit the ACI (atomicity, consistency, and
isolation) properties, but not D (durability).  Database integrity will
be maintained, but it is possible that some number of the most recently
committed transactions may be undone during recovery instead of being
redone.])

m4_bulletend

m4_p([dnl
If you are bottlenecked on logging, the following test will help you
confirm that the number of transactions per second that your application
does is reasonable for the hardware on which you're running.  Your test
program should repeatedly perform the following operations:])

m4_bulletbegin
m4_bullet([Seek to the beginning of a file])
m4_bullet([Write to the file])
m4_bullet([Flush the file write to disk])
m4_bulletend

m4_p([dnl
The number of times that you can perform these three operations per
second is a rough measure of the minimum number of transactions per
second of which the hardware is capable.  This test simulates the
operations applied to the log file. (As a simplifying assumption in this
experiment, we assume that the database files are either on a separate
disk; or that they fit, with some few exceptions, into the database
cache.)  We do not have to directly simulate updating the log file
directory information because it will normally be updated and flushed
to disk as a result of flushing the log file write to disk.])

m4_p([dnl
Running this test program, in which we write 256 bytes for 1000 operations
on reasonably standard commodity hardware (Pentium II CPU, SCSI disk),
returned the following results:])

m4_indent([dnl
% testfile -b256 -o1000
running: 1000 ops
Elapsed time: 16.641934 seconds
1000 ops:   60.09 ops per second])

m4_p([dnl
Note that the number of bytes being written to the log as part of each
transaction can dramatically affect the transaction throughput.  The
test run used 256, which is a reasonable size log write.  Your log
writes may be different.  To determine your average log write size, use
the m4_ref(db_stat) utility to display your log statistics.])

m4_p([dnl
As a quick sanity check, the average seek time is 9.4 msec for this
particular disk, and the average latency is 4.17 msec.  That results in
a minimum requirement for a data transfer to the disk of 13.57 msec, or
a maximum of 74 transfers per second.  This is close enough to the
previous 60 operations per second (which wasn't done on a quiescent
disk) that the number is believable.])

m4_p([dnl
An implementation of the previous m4_linkweb(writetest.cs, [example test
program]) for m4_posix1_name standard systems is included in the m4_db
distribution.])

m4_page_footer