Core: owncloud webdav too slow

[jsalatiel]

Steps to reproduce

1. Mount a share using davs on nautilus
2. Try to download or upload anything
   

   Expected behaviour

The speed should be close to the speed achieved on owncloud sync client.
Sync client can get about 25MB/s. Wevdav speed is about 300KB/s

Actual behaviour

I get under 5% of the speed i can get using owncloud sync client

Server configuration

Operating system:
Debian 8

Web server:
apache2 2.4.10-10+deb8u4

Database:
mysql-server 5.5.47-0+deb8u1

PHP version:
php5 5.6.17+dfsg-0+deb8u1

ownCloud version: (see ownCloud admin page)
owncloud 8.2.2-1.1

Updated from an older ownCloud or fresh install:
updated.

Where did you install ownCloud from:
official repositories.

[PVince81]

Is the speed measured for a single file or multiple files ?

For multiple files, it is likely that nautilus doesn't keep the session information so needs to reauthenticate for every request, which results in two requests.

[jsalatiel]

Hi @PVince81 , thanks for the quick reply!
Actually i tried to download one single big mp4 file and the speed is still terrible :/

[PVince81]

There should be no speed difference for downloading single files between the desktop client and any webdav clients. The desktop client doesn't do anything special, it just sends a GET request of the big file for download. So at this point there is nothing that the ownCloud server can do to speed up downloads for third party clients. Not sure what that client is doing differently that would make it slower.

Can you try other Webdav clients ?

[elvetemedve]

I'm experiencing similar slowness.
I tried to download a large file (~1GB) using Nautilus and Firefox as Webdav clients and the result is the same, download speed is maximized around 300 kB/s. I had created a symbolic link to the test file in the webroot directory and opened the link in Firefox and the maximum speed was around 10 MB/s.

Server configuration and environment

• Owncloud version: 9.0.2
• Web server: Nginx 1.10.0
• PHP version: 7.0.6
• Database: Mariadb 10.1.14
• OS: Arch Linux

[PVince81]

Can you guys try downloading with curl on the command line ?
The command would look like this:

% curl -D - -X GET "http://localhost/owncloud/remote.php/webdav/bigfile.dat" -o bigfile.dat

Curl will also output some transfer speed values.

So far I still suspect that Dolphin (or an underlying lib) is capping the speed for some reason.
ownCloud does not cap download speeds.

Another thing to test: setup an Apache DAV server (not ownCloud) and test downloading with Dolphin against it and see if the speed is also capped.

[PVince81]

or Nautlius... but the web browsers sound strange.

Let's see what curl says...

[PVince81]

The part that is strange is this one:

Sync client can get about 25MB/s. Wevdav speed is about 300KB/s

Why would the sync client get a higher speed ?

@elvetemedve does your sync client also get a higher speed ?
Maybe it's using parallel downloads.

[rullzer]

As @PVince81 says the sync client is using the exact same endpoint so it is :fish:-y indeed.

For a single file the client does/can not do parallel download (CC: @guruz, @ogoffart).

I would be interested to see the commands send by the davfs libs.. As the normal download is just a get. but maybe other stuff is going on?

[guruz]

Client does no paralleism for downloading a single file.
So this is a nautilus/davfs bug then?

[PVince81]

First let's see what curl says for both @jsalatiel and @elvetemedve who I suspect have different issues (env vs lib)

[elvetemedve]

@PVince81 Basically the speed is the same with curl. The average is a bit higher, approximately 400 kB/s. So the bottleneck must be on the server side.

I don't use the sync client at all.

[elvetemedve]

I tracked down the problem and I have to apologise, because OC works perfectly. It was a networking issue.

I'm going to explain what happened, it might be useful for others.
I run an OC instance on my "home server" which means there is a machine at home connected to the Internet. See the topology below:

When I use the internal domain name (_my-oc.local_) for downloading, the wireless router sends packets from my notebook to the OC server directly (both are in the same subnet). In this case the download speed is the maximum (wifi speed is the bottleneck).
But when I use the public one (_my-oc.net_), then the packets are routed to the ISP Gateway first which realises that the packet is from external subnet and has to be forwarded to the internal router (DMZ is configured on the Gateway). So it goes though the WAN port which is rate limited to my ISP to 3 MB/s (download speed). After that the packet arrives at the WAN interface of the wireless router, which is configured to apply some traffic shaping on this interface. As a result the transfer rate is limited to 300-400 kB/s. And finally the router has a forward rule to send the packet to the OC server.

The conclusion is that the packet should not reach the Gateway at all (and treated as external traffic), but sent to the internal OC server just like when I use the private domain name (which points to the private IP of OC server).
It can be achieved by routing the traffic directly to the OC server. So I added these iptables rules on the wireless router:
iptables -t nat -A PREROUTING -p tcp --dport 443 -d <public-ip> -j DNAT --to <oc-server-ip>
iptables -A FORWARD -p tcp --dport 443 -d <public-ip> -j ACCEPT

[DeepDiver1975]

I tracked down the problem and I have to apologise, because OC works perfectly. It was a networking issue.

Good to know!

[DeepDiver1975]

I see no reason in keeping this issue open - we have no influence on how webdav clients really operate and for upload of bigger files the sync client for sure works better because of chunking an parallel upload.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.