[Biojava-l] A further Dazzle/das-client benchmark test and summary

[David Huen]

Test
1) Server: Cyrix PR333, 256MB RAM, IDE disk. Running vanilla Dazzle.

2) Server: PIII/733, 1GB RAM, U160 disks. Running Dazzle 0.90 modified to
do gzip.  gzip enabled at client end too.

3) As in 2 but with gzip disabled at client end and doing buffered IO on
InputStream.

4) As in 2 with Thomas's change to StaX parsing, no gzip at client

5) As in 4 but with gzip.

Client machine is a dual Celeron/450 with 256 MB in all case.

Times (all real world, not cpu usage):
All measured in the getTrueSymbols method.
"connect": time from making the connect() call till data becomes available
from the first call accessing the InputStream.
"parse": time to parse and construct DOM tree.
total: total time spent in getTrueSymbols().

             (1)        (2)      (3)     (4)     (5)
Gzip          N          Y        N       N       Y
StAX          N          N        N       Y       Y

"connect":  90-100     ~300     ~100    ~110    ~300   ms
"parse"  :  2.6-4.2   0.4-0.8  3.9-4.8    -       -    secs
total    :  4.2-5.8   2.1-2.7  3.9-4.8  3-3.5  0.9-1.0 secs

Measurements are typical for accesses to Dros regions 35A, 37A and 39A.

Conclusions
1) Combining StAX parsing and gzip transfers gives us 5x speedup! This
just blows me away!

2) "connect" time is time to first data which is not true connect time at
all.  Parse time includes IO blocking awaiting rest of data.

3) Initial latency for gzip is larger but it is amply saved by a quicker
transfer.

4) It's likely that StaX parsing was held up awaiting data given the
amount of synergy with gzip+StAX!

Wow, I've rarely seen so much speedup for so little change.  We've got a
formidable server/client combo now!


Regards,
David Huen, Dept. of Genetics, Univ. of Cambridge
[P.S. I've copied the das list as this may be relevant to the other
server/client systems around.]