+++ /dev/null
-
-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
-$
projects / webpac / blobdiff