|
This time, we tested to use a file of 21 MB using 8 threads. The number of megabytes received by the web server is about 168 MB. The following table contains values of time range and average time as the previous results.
| TABS Upload |
SAFileUp |
ABCUpload |
| time range |
avg time |
time range |
avg time |
time range |
avg time |
| 11625~16984 |
14785.13 |
33203~34656 |
34093.50 |
40609~47593 |
45743.88 |

Fig. 2 Elapsed time to complete uploading
The Fig. 3 shows elpased times per upload thread from the the test result sheet.

Fig. 3 Elapsed time per thread
TABS Upload was two or three times faster than SAFileUp and ABCUpload.
To compare in detail, we recorded web server's performance counters such as CPU usage, disk write bytes per sec, and disk queue length. As the IIS takes charge of HTTP communication entirely for uploading, all components have the same condition about network bandwidth.
Because all upload component use the same technology - calling Request.BinaryRead method repeatedly to receive - no additional memory is required, therefore, we did not measure memory usage.
The most important thing for best performance in uploading can be summarized as how fast the upload component can parse MIME data received from the browser and how much it can minimize disk I/O occurred when the upload file is saved into disk.
The CPU usage of performance counters means speed of parsing MIME data and the disk write bytes and disk queue length represents the amount of disk I/O consumed by saving files.
If the disk drive has a sustained load, the value of disk queue length will be consistently high. This value should average less than 2 for good performance. If the value is more than 2 then the disk is very busy and the web server might not respond to the browser's request.
The red triangle shown in the figures of performance counter indicates the position in which to finish uploading.

TABS Upload
|
| |

SAFileUp
|
| |

ABCUpload
|
The range of CPU usages of TABS Upload were very short compared with other components. This means that the one-pass parsing algorithm is faster than competitors' that parses uploaded MIME data. Moreover, the value of disk queue length was lower than other components', TABS Upload occurred no more than disk I/O that it received. It results from buffering technology optimized for NTFS.
Compared with TABS Upload and SAFileUp, ABCUpload showed that the value of disk queue length was very high and had serious variation. It means that the number of requests that are queued and wait for being processed is so many that the disk might be a bottleneck.
|