This issue is about having some preliminary base data points for performance measurements. The upload and download speed was measured on the SwarmID demo app using the default gateway.
The uploads are using web workers for signing the chunks and by default the number of workers (threads) are the same as the number of cores on the machine that runs the app (in our case this was 14). Encryption was enabled, and the upload concurrency is 32 (that means that 32 parallel chunk request is going on at the same time).
Then the same uploaded data was used for downloading. There were two datasets, a 1MB random data and 10MB random data file.
| Dataset |
Upload speed |
Download speed |
| 1MB |
329KB/s |
633KB/s |
| 10MB |
273KB/s |
245KB/s |
In order to support streaming with HLS at 720 (HD) resolution according to Apple the required bitrate for H.264/AVC is 3-4.5 Mbps and for HEVC/H.265 is 2.4-3.4Mbps. Using the same units (and some network overhead) that is 300-450 KB/s for H.264/AVC and 240-340 KB/s for HEVC/H.265.
The numbers are in the same ballpark so with some optimizations they seem achievable. There may be throttling on the gateway, because theoretically there should be no difference in uploading 1MB or 10MBs, on a local instance the differences were minimal.
There is also an opportunity to use websockets for chunk uploads. Currently Bee does not support the browser to use that API endpoint and also it does not allow client-side stamping, there is a PR in progress to add that functionality. Preliminary testing showed about 30-40% faster uploads with that.
Currently there is no way to download chunks from the websocket: ethersphere/bee#5417
1MB
10MB
This issue is about having some preliminary base data points for performance measurements. The upload and download speed was measured on the SwarmID demo app using the default gateway.
The uploads are using web workers for signing the chunks and by default the number of workers (threads) are the same as the number of cores on the machine that runs the app (in our case this was 14). Encryption was enabled, and the upload concurrency is 32 (that means that 32 parallel chunk request is going on at the same time).
Then the same uploaded data was used for downloading. There were two datasets, a 1MB random data and 10MB random data file.
In order to support streaming with HLS at 720 (HD) resolution according to Apple the required bitrate for H.264/AVC is 3-4.5 Mbps and for HEVC/H.265 is 2.4-3.4Mbps. Using the same units (and some network overhead) that is 300-450 KB/s for H.264/AVC and 240-340 KB/s for HEVC/H.265.
The numbers are in the same ballpark so with some optimizations they seem achievable. There may be throttling on the gateway, because theoretically there should be no difference in uploading 1MB or 10MBs, on a local instance the differences were minimal.
There is also an opportunity to use websockets for chunk uploads. Currently Bee does not support the browser to use that API endpoint and also it does not allow client-side stamping, there is a PR in progress to add that functionality. Preliminary testing showed about 30-40% faster uploads with that.
Currently there is no way to download chunks from the websocket: ethersphere/bee#5417
1MB
10MB