1 files changed, 0 insertions, 125 deletions
diff --git a/libdb/docs/ref/transapp/throughput.html b/libdb/docs/ref/transapp/throughput.html
deleted file mode 100644
index 163f4db00..000000000
--- a/libdb/docs/ref/transapp/throughput.html
+++ /dev/null
@@ -1,125 +0,0 @@
-<!--$Id$-->
-<!--Copyright 1997-2002 by Sleepycat Software, Inc.-->
-<!--All rights reserved.-->
-<!--See the file LICENSE for redistribution information.-->
-<html>
-<head>
-<title>Berkeley DB Reference Guide: Transaction throughput</title>
-<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit.">
-<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,java,C,C++">
-</head>
-<body bgcolor=white>
-<a name="2"><!--meow--></a>
-<table width="100%"><tr valign=top>
-<td><h3><dl><dt>Berkeley DB Reference Guide:<dd>Berkeley DB Transactional Data Store Applications</dl></h3></td>
-<td align=right><a href="../../ref/transapp/tune.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/faq.html"><img src="../../images/next.gif" alt="Next"></a>
-</td></tr></table>
-<p>
-<h1 align=center>Transaction throughput</h1>
-<p>Generally, the speed of a database system is measured by the
-<i>transaction throughput</i>, expressed as a number of
-transactions per second.  The two gating factors for Berkeley 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.
-<p>In the worst-case scenario:
-<p><ul type=disc>
-<li>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.
-<li>Both the database and the log are on a single disk.
-</ul>
-<p>This means that for each transaction, Berkeley DB is potentially performing
-several filesystem operations:
-<p><ul type=disc>
-<li>Disk seek to database file
-<li>Database file read
-<li>Disk seek to log file
-<li>Log file write
-<li>Flush log file information to disk
-<li>Disk seek to update log file metadata (for example, inode information)
-<li>Log metadata write
-<li>Flush log file metadata to disk
-</ul>
-<p>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 Berkeley DB software includes support for
-<i>group commit</i>.  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:
-<p><ul type=disc>
-<li>Tune the size of the database cache.  If the Berkeley 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 <a href="../../ref/am_conf/cachesize.html">Selecting
-a cache size</a>.
-<li>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.
-<li>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 Berkeley DB, this may affect other programs -- so be careful.
-<li>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 Berkeley DB.
-<li>Turn on the <a href="../../api_c/env_set_flags.html#DB_TXN_WRITE_NOSYNC">DB_TXN_WRITE_NOSYNC</a> or <a href="../../api_c/env_set_flags.html#DB_TXN_NOSYNC">DB_TXN_NOSYNC</a> flags.
-This changes the Berkeley 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.
-</ul>
-<p>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:
-<p><ul type=disc>
-<li>Seek to the beginning of a file
-<li>Write to the file
-<li>Flush the file write to disk
-</ul>
-<p>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.
-<p>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:
-<p><blockquote><pre>% testfile -b256 -o1000
-running: 1000 ops
-Elapsed time: 16.641934 seconds
-1000 ops:   60.09 ops per second</pre></blockquote>
-<p>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 <a href="../../utility/db_stat.html">db_stat</a> utility to display your log statistics.
-<p>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.
-<p>An implementation of the previous <a href="writetest.cs">example test
-program</a> for IEEE/ANSI Std 1003.1 (POSIX) standard systems is included in the Berkeley DB
-distribution.
-<table width="100%"><tr><td><br></td><td align=right><a href="../../ref/transapp/tune.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../../reftoc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../../ref/transapp/faq.html"><img src="../../images/next.gif" alt="Next"></a>
-</td></tr></table>
-<p><font size=1><a href="http://www.sleepycat.com">Copyright Sleepycat Software</a></font>
-</body>
-</html>