Upload seems very slow on web frontend

[Trevelian]

Hello,

I am trying Send using the Docker Compose file to deploy it on RHEL9, I also try it on ArchLinux.
I have 10 Gbit servers and 10 Gbit clients, but uploads are only between 10 Mbit/s and 50 Mbit/s.
I verify with iperf3 and there is no network problem, I have 8.8Gbit/sec between these systems.

I tried this both in my homelab and at my company, and the result is the same.
I have tried using NVMe storage as well as S3 storage, but it is still slow.

I try with "ffsend" and I can upload at 2Gbit/sec.
So it seems there is a problem with the web frontend.

How can I debug this? Have other people managed to upload files at reasonable speeds?

Thanks for your help!
Trevelian.

[timvisee]

Files are encrypted and decrypted on the client. It could definitely be a bottleneck.

Do you see similar results with different browsers, and with ffsend?

[Trevelian]

We tested it on Firefox and Chrome, and it's very slow on both.
Our connection speed ranges between 10 Mbit/s and 200 Mbit/s, with an average of around 50 Mbit/s.

Maybe there’s an issue with a dependency?
When we tried the software about four months ago, we didn’t feel it was this slow.

With ffsend, it’s fast (around 2 Gbit/s).

[rvalab]

Tested with Docker Compose on RHEL9. When I upload a file locally (http://localhost:1443), it's quick.
When I upload the same file from a remote machine (same Send instance), I only have some Mbps.
I disabled the firewall on the RHEL9 to be sure but same result.

I also tested with 2 VMs (1 VM for Send and 1 VM for a client) on the same ESXi host and on the same PortGroup), and I have the same problem (cf. image)

Same result on my homelab (on Fedora 42).

Any idea? 🤔

[AzureFatty]

I have the same problem.

[TecsiAron]

+1

[livdebus]

+1
We use your fantastic tool since over a year. Since some weeks uploads got really slow. Especially with files over 1GB file size.
But nothing changed in our S3 backend. Would be nice if you could check into this. Let me know if I can provide any useful information.

[Skijearz]

had the same issue and figured it was because of the buffer size in api.js#239 and the delay which it causes.
await delay(); will default to 100ms delay between uploading chunks which seems a bit too much imo ~ and the 128kb buffer seems to be a bit too small.
I changed the delay to 1ms but html5 will enforce a minimum of 4ms after some timeouts - therefore there should not be a difference between 1-4ms. Also changed the buffer size to 8mb (ws.bufferedAmount > ECE_RECORD_SIZE * 16 * 8 && )

[livdebus]

had the same issue and figured it was because of the buffer size in api.js#239 and the delay which it causes. await delay(); will default to 100ms delay between uploading chunks which seems a bit too much imo ~ and the 128kb buffer seems to be a bit too small. I changed the delay to 1ms but html5 will enforce a minimum of 4ms after some timeouts - therefore there should not be a difference between 1-4ms. Also changed the buffer size to 8mb (ws.bufferedAmount > ECE_RECORD_SIZE * 16 * 8 && )

Great finding. But can you please explain a bit more detailed, how this can be adjusted manually until there is a new release?
I found the mentioned await delay(); under /app/app/api.js, but could not find the corresponding 100ms configuration.
Could you please explain which exact values you modified in which file?

[TecsiAron]

@livdebus delay is defined in utils as
function delay(delay = 100)
changing that might have side-effects so change the call from await delay() to await delay(4);
As for the buffer size, its also in api.js on line 239.
@Skijearz thank you kindly sir.

[rvalab]

It doesn't seem to work in my lab.
I'm using the Docker Compose version.
I edited both lines in the /app/app/api.js file. I save a new image (with docker commit) and I point my env file to my new image. Re-run docker compose and try but no difference.
I also cleared my browser cache to be sure.

What am I doing wrong?

[coko7]

Experiencing this as well when using the Web UI.
Any update on this?