IT WORKED!! I edited the file in nano

(which was really hard for nano) and hard-reloaded the window (no need to restart server). Now files upload in 1MB chunks as I configured! See GIF:
Now it uploads faster although not as fast as I thought because now the server is slower to respond to larger chunks. I set it to 1MB because I read that’s the default limit for nginx, but I’m waiting for sysadmin to configure my vhost to allow 50MB to match cloudflare, and it should be better then.

Ok so I set it to 50mb now but I found out that maxChunkSize actually is used even if adaptive = false, despite what the documentation said (I opened a PR). So I also had to add maxChunkSize:-1 (cuz it’s not used if it’s less than 0, but it could also be set equal to or larger than chunkSize.)

Now uploads under 50mb are uploaded in one request, allowing maximum bandwidth and fastest upload speed. Only issue now is that the progress meter shows 0% the entire time.

1 Like

Nice work. I vote this should be and issue or feature request.

I’m trying to fix this as you said, but I cannot find the correct value anymore. Perhaps because it’s been updated since September 2019.

@lamp can you check if it’s currently still fixable with an auto-updating snaps installation of Rocket Chat? I can find the .js file but no mention of r.Uploader…

I found it here in the snap version 2.4.2:

adaptive is true, chunkSize is 16KiB, maxChunkSize is 4MB. Setting adaptive to false, maxChunkSize to -1 and chunkSize to your desired chunk size like 50MB should make uploads faster.
The thing is the snap files are in a read-only squashfs so you can’t modify them. So you’ll have to rebuild the snap or deploy differently. It’s probably best to fork the repo on github and make your modifications to the source code, then build the meteor app from that. That’s what I did. Although then you have to merge upstream changes every time you want to update. But I ended up not really using so I’ve never updated.

1 Like

wtf why can’t I post links to github here?!

WHAT THE HELL?? Why have all of my posts in this thread suddenly been flagged as spam?!?!?!

Rocket chat is backed by China. Look out your window. :wink:

1 Like

@bbrendon Any sources for this or further reads?

@lamp thanks for the helpful post (even though it’s marked as spam, which is clearly ridiculous).

Would you make an issue at their official github page?

I really think it’ll get more attention there. It should definitely be easy to fix for them, or at least allow users to properly tune it for their own needs. The current upload speed is ridiculously slow.

@lamp Are you able to submit it to github? You have a lot more knowledge about this than I do!

@diego.sampaio @rodrigo.nascimento I wonder if we should expose these settings?

I think slow uploads is something we all have experienced before on the web client.


Seems you hit a discourse spam setting:

I’ve now whitelisted for now :slight_smile:

1 Like

I actually have asked @guilherme.gazzo already to change the way our web client send files to use a single POST request. I don’t know how it was prioritised.


@diego.sampaio github issue?

Here somebody made issue

Did anyone else hit their reverse proxy (nginx / apache / others…) configured request size limit?

These limits may not be easy to raise, for security reasons, especially if the reverse proxy is shared by other servers that don’t need huge file upload capabilities.

1 Like

Normally you would apply the upload size limit to one parrticular vhost.

But I see how splitting the files can help when there is an unchangeable upload limit or the files are larger than the largest upload limit (i.e. 1GB file with 100MB limit on cloudflare free plan)

In this case, it would help a lot if the UploadFS module could upload multiple chunks in parallel.

But if the server upload limit allows, one request will always be fastest I think.

The problem is, the UploadFS thing calculates the progress based on completion of chunks, so if you just set the chunk size really high so it uploads in one chunk, the progress meter will show 0% the entire time, then jump to 100% the moment it’s done.

So I think the UploadFS module needs major changes, but it appears it is now discontinued :man_shrugging:

Well in this case, what is the best way to fix this issue?

Especially on local networks, file upload and download speeds needs to be drastically improved. It’s currently extremely slow. Fixing that first, we can worry about reverse proxies next.

on or if you are running develop there is this PR being ran:

But… while sending in big chunk… you for sure will hit limits of your proxy for bigger files