the benefit of multithreading depends heavily on two factors:
- whether the db is in the filesystem cache or needs real disk I/O
- whether you use Java or pure C

if there is real disk I/O, then multithreading gives a big
performance enhancement: 8 threads outperform a single one
by a factor of 4.2 (C) or 3.3 (Java) respectively,
and C outperforms Java only by a factor of
1.3 (single-threaded) or 1.6 (8 threads).

if there is sufficient memory available to cache the whole db,
so that the process is mostly CPU bound,
then 8 threads give only a 9% throughput advantage over one in C,
and an 18% performance degradation (!) in Java.
C outperforms Java by a factor of 50 (yes, 5000% percent !)
with 8 threads or 38 single-threaded.


======

conclusion:
For a mostly I/O-bound server, you might well use threaded Java,
it is only about 40% slower than multithreaded C,
but still beats single-threaded C by a factor of 2.5 .

If, on the other hand, you want to go for real performance,
get the memory needed and use C.
As long as you are not concerned too much with fairness and there
is no risk of some too lengthy operations, it may as well be
single threaded.


======

the following numbers were derived without any thread interlocking (mutex)
on a single processor


some numbers from the C multithreaded crashtest (make crash)
on the unesb db for prefix "Z" running on an 800MHz PIII with 1/4G RAM
under Linux 2.4.13

409 terms
4205 postings max mfn 58880

*	with lots of memory available for caching:
$
sequential read 58880 rows in 0.618 seconds 95275 rows per sec

8 threads  82384 rows per sec
2 threads  79600 rows per sec
1 threads  75544 rows per sec
4 threads  81916 rows per sec

real    0m3.040s
user    0m1.860s
sys     0m0.920s
$

*	with nearly all memory locked down by root:
$
sequential read 58880 rows in 6.720 seconds 8761 rows per sec

8 threads  1199 rows per sec
2 threads  467 rows per sec
1 threads  288 rows per sec
4 threads  624 rows per sec

real    5m6.422s
user    0m1.940s
sys     0m2.230s
$



some numbers from the Java multithreaded crashtest (make jcrash)
on the same db and machine

409 terms
4205 postings max mfn 58880

*	with lots of memory available for caching:
$
sequential read 58880 rows in 30.508 seconds 1929 rows per sec

8 threads  1645 rows per sec
2 threads  1836 rows per sec
1 threads  2013 rows per sec
4 threads  1785 rows per sec
129.00user 7.40system 2:20.80elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (4978major+7237minor)pagefaults 0swaps
$

*	with nearly all memory locked down by root:
$
sequential read 58880 rows in 58.827 seconds 1000 rows per sec

8 threads  738 rows per sec
2 threads  380 rows per sec
1 threads  225 rows per sec
4 threads  558 rows per sec
123.68user 3.87system 8:16.98elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (5286major+7366minor)pagefaults 0swaps
$

*	on a 360MHz Mob. PII with 40MB and Linux 2.2.12,
	numbers differ even more:
	without disk activity,
	a single thread gives about 50% more throughput than 8
	with lots of disk I/O on the other hand,
	8 threads nearly quadruple the single thread throughput

*	the mobile now with an 2.4.18 kernel:
$
enough memory:
8 threads  54558 rows per sec
4 threads  49822 rows per sec
2 threads  43575 rows per sec
1 threads  37656 rows per sec

with mutex:
8 threads  49525 rows per sec
4 threads  45174 rows per sec
2 threads  41859 rows per sec
1 threads  36262 rows per sec

no memory (mutex):
8 threads  696 rows per sec
4 threads  367 rows per sec
2 threads  258 rows per sec
1 threads  150 rows per sec
$