Performance tuning (1 Gbit/s)

[deni]

Hi,

First if all, thanks for this project. It makes me comfortable to setup my own NextCloud instance maintenance-wise.

In my tests, with 1 GB of RAM I got download speeds of approximately 50 MB/s and upload speeds around 25 MB/s.

Upgrading to 4 GB's of RAM gave me download speeds of approximately 100 MB/s (so 800 Mb/s), but with the same upload speed as before.

My wish is to, as much as possible, be able to saturate a gigabit line (so ideally 125 MB/s) and at the very least hopefully be able to get 100 MB/s both ways.

I would appreciate if someone could help me understand where this bottleneck lies and if this snap package would be able to achieve the above.

Thanks in advance, deni

[negativesymptomatic]

Hi, have you checked the performance of the CPU? Are you using the instance in an SSD or an HDD?

[deni]

Hi @sintomaticonegativo,

Thanks for the input. I just tested with 2x Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (according to /proc/cpuinfo) and am still experiencing the same upload cap. It seems to be the same as people are describing in the comments section here on Reddit.

When I initially deployed the VPS, it was with a lower configuration. I vaguely remember reading somewhere that the snap checks the system upon install and sets certain parameters accordingly. It it possible that this operations needs to be repeated in order to have the settings reflect the new system specifications?

[negativesymptomatic]

Ok, good to know, the CPU seems fast enough to play with, have you tried to increase the PHP memory to 1G?

I have no idea about the performance tuning during installation on the snap, but I'm going to check if there's something like this, maybe @kyrofa or @stondino00 could give us a hint about!

The VPS in in HDD or SSD? To give you an example, maybe the VPS is in a RAID array of HDD with SSD caching, so the read/write speeds blows up after few seconds...

[negativesymptomatic]

Anyway, could you give us the specs of the VPS?

[deni]

Of course. It is a Digital Ocean droplet hosted in Amsterdam (datacenter 3) that was initially spun up in their cheapest plan (5 USD/month):

• 1 GB of RAM
• 25 GB of SSD space

Which I used initially (as described in the first post). I then upgraded the RAM in that to 4 GB after which I saw the improved download performance. I have decided to keep this configuration.

The test in my last comment was done by upgrading the CPU to a dedicated one, however it did not seem to improve perform, why I have now gone back to the previous configuration with 4 GB of RAM and no fancy CPU.

[kyrofa]

My wish is to, as much as possible, be able to saturate a gigabit line (so ideally 125 MB/s) and at the very least hopefully be able to get 100 MB/s both ways.

I doubt you'll be able to get there with webdav. It just seems to be a slow protocol, in my experience.

I then upgraded the RAM in that to 4 GB after which I saw the improved download performance.

...

I vaguely remember reading somewhere that the snap checks the system upon install and sets certain parameters accordingly.

That's right, we do a little bit of that here for calculating PHP workers, that may very well be part of the benefit you noticed when you bumped the RAM. Note that this calculation is done at runtime, not install time, so it will respond to a change in system configuration if you restart the snap (or the host, of course).

Really the only setting to play with other than host-specific settings is the PHP memory limit. Try bumping it up and see if you can eek some more performance out of it.

When you're hitting it hard (uploading or downloading as fast as you can) take a look at a monitor of some kind (top, or something else you're familiar with). What seems to be the resource that is maxed out? CPU? Memory?

[deni]

Thanks to both of you. I have tried increasing the PHP memory limit, but am still seeing upload speeds around 15 MB/s. I am not super familiar with monitoring the use of system resources, but I personally do not see a bottleneck. Here is htop during file upload:

[negativesymptomatic]

Sorry for all the questions, but is necessary to have all the information to know what is happening:

Good to know that the server has good performance for the NC instance, but the client?

Have you tried with different clients, that have different cpu/ram specs?

You're hosting the instance on DO, so you should have an internet connection with high upload speed to match the server connection, 15MB/s to 25MB/s means that you are matching a 200Mbit/s upload speed, so maybe your internet connection have 200Mbit in up?

[kyrofa]

Good idea @sintomaticonegativo. The OP leads me to believe @deni has a gigabit connection, but that doesn't necessarily imply there are no other limiting factors. @deni I suggest dispensing with the theory and actually trying to get an idea of what kind of throughput you can accomplish trying to eliminate all other variables. You might try using iperf (here is another resource).

I'm sitting in the same room as my server with a gigabit line and switch between us. Here are my results:

------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.237 port 58328 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   924 MBytes   775 Mbits/sec

Yours may be quite a bit less. Nextcloud's speed will be even less.

[negativesymptomatic]

The simplest thing that he should do is a speedtest of his internet connection in the client that is using for the upload testing in the nextcloud instance. With that we can see what type of connection you have, because the server probably has 1gbit simmetric, e.g. my internet speed is 980Mbit down 290Mbit up

[kyrofa]

Yeah what's coming from the ISP will be worth knowing, but iperf eliminates a lot more variables. Both pieces of information would be valuable.

[deni]

Thanks for the input to both of you. I am 99% sure that I am on a symmetric gigabit connection. Using iperf is a good idea to rule out any line bottlenecks. I will make sure to run it on Monday when I am back in the office. Thanks again.

[deni]

@kyrofa May I ask what speeds you are seeing on file transfers (both up and down) on your NextCloud instance when transferring locally? Then I will know that (at least) that is possible.

[kyrofa]

Excellent. Make sure you're running the iperf client from the same machine running the Nextcloud client if you want to eliminate all variables (e.g. perhaps it's on wifi, which will be far slower than gigabit). Kill the client, first.

Also, I hate you both. I'm paying through the nose for 50 down/10 up.

[kyrofa]

May I ask what speeds you are seeing on file transfers (both up and down)

Oh, yeah that would be interesting, huh. How are you actually gathering that data? Mounting webdav, or just looking at the speed in the desktop client?

[deni]

Also, I hate you both. I'm paying through the nose for 50 down/10 up.

Yeah, I think infrastructure everywhere is not prioritized as much as it should be.

I am actually just taking a large file and downloading/uploading it through the browser, since it will be my main use-case for the setup.

[kyrofa]

Okay so I tested that real quick with a 1GB file. Before I share it though, keep in mind that:

• My server is actually pretty busy doing a number of things that I didn't shut down for this test
• My server is all spinning media in various RAID configurations

Uploading the file through the browser hopped around dramatically between 1-16.5MB/s. Downloading seemed to top out around 108MB/s. I suspect the asymmetry is due to RAID, but it's possible webdav is slow on write as well. The down is more than I would have expected given my iperf test above, but close enough I can attribute it to average calculation and server activity.

[negativesymptomatic]

@kyrofa maybe the thing that @deni do, uploading file from the bowser, could affect performance? We need to ensure that the browser is not capping the cpu on the client, maybe it uses only 1 thread.

I'm sure that is not the server the problem, in fact your htop screen say that the server is barely idle when you are uploading...

[github-actions[bot]]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.