Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss potential pitfalls of concurrent upload (currently set to 3) #4

Open
skjnldsv opened this issue May 13, 2022 · 6 comments
Open
Labels
1. to develop Accepted and waiting to be taken care of discussion Being discussed performances Performances issues and optimisations

Comments

@skjnldsv
Copy link
Contributor

No description provided.

@skjnldsv skjnldsv added 1. to develop Accepted and waiting to be taken care of performances Performances issues and optimisations discussion Being discussed labels May 13, 2022
@skjnldsv
Copy link
Contributor Author

skjnldsv commented Feb 6, 2024

From nextcloud/server#43337

at the moment, uploading a large file is split into chunks, which get pushed to nextcloud server 3 at a time; i've found that 3 connections are not enough for me to max out my network line and think it would be great if this value is configurable via occ

@realies I'm really interested in this discussion! I chose 3 kind of randomly.
Do you have some informations or insights on which amount should be better?

@realies
Copy link

realies commented Feb 6, 2024

@skjnldsv, I would like to try with 10 concurrent chunks. What can I patch to try it out?

@skjnldsv
Copy link
Contributor Author

skjnldsv commented Feb 6, 2024

You cannot, why 10 ? Is it just randomly chosen?
What uplink are you using? 1Gbps?

@realies
Copy link

realies commented Feb 6, 2024

why 'cannot'? 10, because iperf3 -c x.x.x.x -P 10 gave me optimal results; the link is 1Gbps

@skjnldsv
Copy link
Contributor Author

skjnldsv commented Feb 6, 2024

Because this is compiled libraries, you cannot patch our server bundles

@MrRinkana
Copy link

If different uplinks perform optimally with different amount of chunks, shouldn't that number be dynamic rather than a compiled in constant?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. to develop Accepted and waiting to be taken care of discussion Being discussed performances Performances issues and optimisations
Projects
None yet
Development

No branches or pull requests

3 participants