0INBerkeley DB Reference Guide: Transaction Protected Applications[PH

Berkeley DB Reference Guide: Transaction Protected Applications



,

Transaction throughput



HGenerally, the speed of a database system is measured by the transaction?throughput, expressed as the number of transactions per second.

LThe two gating factors for Berkeley DB performance in a transactional systemHare usually the underlying database files and the log file, both becauseFthey require disk I/O, which is incredibly expensive relative to otherresources, e.g., CPU.

In the worst case scenario:



KThis means that for each transaction, Berkeley DB is potentially performingseveral filesystem operations:



DThere are a number of ways to increase transactional throughput, allDof which attempt to decrease the number of filesystem operations per transaction:



DIf you are bottlenecked on logging, the following test will help you+confirm that the number of transactions perIsecond that your application does is reasonable for the hardware on whichJyou're running. Your test program should repeatedly perform the following operations:



JThe number of times that you can perform these three operations per secondDis a rough measure of the number of transactions per second of whichDthe hardware is capable. This test simulates the operations applied0to the log file. (As a simplifying assumption inBthis experiment, we assume that the database files are either on aCseparate disk, or that they fit, with some few exceptions, into theKdatabase cache.) We do not have to directly simulate updating the log fileIdirectory information, as it will normally be updated and flushed to disk3as a result of flushing the log file write to disk.

CRunning this test program on reasonably standard commodity hardware<(Pentium II CPU, SCSI disk), returned the following results:



FNote that the number of bytes being written to the log as part of eachDtransaction can dramatically affect the transaction throughput. TheEabove test run used 256, which is a reasonable size log write. (YourGlog writes may be different. To determine your average log write size,euse the db_stat utility to display out your log statistics.)

HAs a quick sanity check, for this particular disk, the average seek timeEis 9.4 msec, and the average latency is 4.17 msec. That results in aGminimum requirement for a data transfer to the disk of 13.57 msec, or aImaximum of 74 transfers per second. This is close enough to the above 60Goperations per second (which wasn't done on a quiescent disk!) that thenumber is believable.

EThe above example test program (for POSIX 1003.1 standard systems) is+available here.

KFuture releases of Berkeley DB are expected to include group commit and theEability to stripe log files across multiple disks, both of which will@offer additional options for increasing transaction performance.

OAQÿÿ