The tests below were conducted from a VM client (win7) located in Utrecht against a VM server (debian lenny) located in Amsterdam. The network path was at least 1 Gbps (with 2-10Gbps path segments in between), 5 hops and a latency of approx. 3-5 ms (both IPv6 and IPv4).

Case 1 - Upload performance test using Gears

Conducted by:

Xander Jansen

Since the upload speed is rather poor some tests were conducted to check the influence of debug logging and the gears upload chunk size. The tests were done with a 1 GByte file with random data against svn revision 205. The source file was located on and uploaded from local storage.

• Size in bytes: 1073527438 1GByte-random.dat
• MD5: 2280f7891ef488f937efc502dd394582 1GByte-random.dat

The table contains upload times (mm:ss) computed from the timestamp of the apache log of the first chunk (start) and the timestamp (Date: field) of the mail sent when the upload was done (stop).

As expected both the debug setting and the chunksize have a large impact on the upload speed. The effect of setting debug to true is largest with a small chunksize and isn't noticable anymore with the larger chunksizes (10MB+).

Case 2 - Upload performance test using Flash

The tests were done with a 1 GByte file with random data against svn revision 205. The source file was located on and uploaded from local storage.

• Size in bytes: 1073527438 1GByte-random.dat
• MD5: 2280f7891ef488f937efc502dd394582 1GByte-random.dat

The table contains upload times (mm:ss) computed from the timestamp of the call to fs_uploadit.php in the apache log (start) and the timestamp of the first fs_main.php call in the apache log after that (stop).

Notes

• Due to weird problems on the Win7 testbox with Safari and SSL the Apache server was instructed to disable 'keepalive' when doing SSL for Safari browsers, this may have some impact (to be tested where possible). Note that this option didn't solve the Safari problem