Unable to solve slow up and down speed on LAN

Hey all,

First and foremost thank you for the great product. It is a breeze to install with the provided Docker compose .yml

I have issues with down and upload speed on LAN. I only have 20-25MB/s (HTTPS) through Website and App. These are actually lower than with a test install of NextCloud (30-35 MB/s), strangely.

I tried for some time now to improve the speed, but I seem unable to. Any help would be welcomed, as I am close to giving up :slight_smile:

Hence: what would you recommend?

(I posted as well on the Reddit channel)

Below the complete conf. :

Server conf.

  • I7 4930k (6cores) 12 Threads
  • 16GB ram
  • SSD disk

Client conf.:

  • i7 6600u with 20GB ram and SSD

Both connected with Ethernet 1Gb/s cables to router.

Iperf bandwidth TCP between Client an Server: 931Mbits/sec

Config files after tinkering to try to solve slow up/down speed (I don’t necessarily know what all means, but I tried):

seafdav.conf

[WEBDAV]
enabled = false
port = 8080
share_name = /seafdav

ccnet.conf

[General]

[Database]
ENGINE = mysql
HOST = db
PORT = 3306
USER = seafile
PASSWD = $supersecretpassword
DB = ccnet_db
CONNECTION_CHARSET = utf8

seafile.conf

[fileserver]
port = 8082
worker_threads = 15
max_indexing_threads = 12
fixed_block_size = 70
web_token_expire_time = 86400
skip_block_hash = true

[database]
type = mysql
host = db
port = 3306
user = seafile
password = $supersecretpassword
db_name = seafile_db
connection_charset = utf8
max_connections = 200

seafile.nginx.conf

# -*- mode: nginx -*-
# Auto generated at 09/24/2022 13:54:22
proxy_request_buffering off;
client_body_buffer_size 70m;
ssl_buffer_size 70m;
client_header_buffer_size 50k;
large_client_header_buffers 2 50k;
proxy_connect_timeout 1d;
proxy_send_timeout 1d;
proxy_read_timeout 1d;
send_timeout 1d;
client_max_body_size 0;




server {
    listen 80;
    server_name _ default_server;

    # allow certbot to connect to challenge location via HTTP Port 80
    # otherwise renewal request will fail
    location /.well-known/acme-challenge/ {
        alias /var/www/challenges/;
        try_files $uri =404;
    }

    location / {
        rewrite ^ https://$myadress$.duckdns.org$request_uri? permanent;
    }
}
server {
listen 443 ssl;
    ssl_certificate      /shared/ssl/$myadress$.duckdns.org.crt;
    ssl_certificate_key  /shared/ssl/$myadress$.duckdns.org.key;

    ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

    # TODO: More SSL security hardening: ssl_session_tickets & ssl_dhparam
    # ssl_session_tickets on;
    # ssl_session_ticket_key /etc/nginx/sessionticket.key;
    # ssl_session_cache shared:SSL:10m;
    # ssl_session_timeout 10m;
server_name $myadress$.duckdns.org;


    location / {
        proxy_pass http://127.0.0.1:8000/;
        #proxy_read_timeout 310s;
        proxy_set_header Host $host;
        proxy_set_header Forwarded "for=$remote_addr;proto=$scheme";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Connection "";
        proxy_http_version 1.1;

        #client_max_body_size 0;
        #access_log      /var/log/nginx/seahub.access.log seafileformat;
        #error_log       /var/log/nginx/seahub.error.log;
    }

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        proxy_pass http://127.0.0.1:8082;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 0;
        #proxy_connect_timeout  36000s;
        #proxy_read_timeout  36000s;
        proxy_request_buffering off;
        #access_log      /var/log/nginx/seafhttp.access.log seafileformat;
        #error_log       /var/log/nginx/seafhttp.error.log;
    }

    location /seafdav {
        proxy_pass         http://127.0.0.1:8080;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_set_header   X-Forwarded-Proto $scheme;
        #proxy_read_timeout  1200s;
        #client_max_body_size 0;

        #access_log      /var/log/nginx/seafdav.access.log seafileformat;
        #error_log       /var/log/nginx/seafdav.error.log;
    }

    location /media {
        root /opt/seafile/seafile-server-latest/seahub;
    }

    # For letsencrypt
    location /.well-known/acme-challenge/ {
        alias /var/www/challenges/;
        try_files $uri =404;
    }
}

nginx.conf

daemon off;
user www-data;
worker_processes 12;
worker_rlimit_nofile 100000;
error_log /var/log/nginx/error.log crit;

events {
    worker_connections 4000;
     use epoll;
     multi_accept on;
}

http {
    include /etc/nginx/mime.types;
    server_names_hash_bucket_size 256;
    server_names_hash_max_size 1024;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    sendfile on;

    access_log off;

    #gzip on;
    #gzip_types  text/plain text/css application/javascript application/json text/javascript;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

    server {
        listen 80;
        location / {
            return 444;
        }
    }
}
1 Like

Hey SelbstoderhalbDenker,

Do you call yourself a self-thinker and use docker? Then you ask about the latest performance tweaks? Something seems wrong with you.

I have the exact same issue.

@mrpila For your info, I also installed Seafile natively and activated ktls support in the kernel. This had no change.

Difference between native install and docker is minimal. (So don’t waste your time on it :slight_smile: )

No solution found on my side so far

1 Like

I actually had slow upload performance, I really couldnt narrow it down, because there was alot of overhead on both server and client, I eventually found my router was maxing out its CPU and that was the cause

Questions:

  • What are the speeds when using scp/sftp?
  • What is the speed when you are downloading through nginx?
  • What is the Iperf Speed when using $myadress$.duckdns.org as destination.

Be aware if you are using $myadress$.duckdns.org on your LAN and this points to a global IP address all your traffic is routed through your router and you can guess where the bottle neck might me.

An "ugly fix"™ for this problem is a local DNS-Server or /etc/hosts entry which points to your private LAN IP address.

HTH!

@germeier @Narendra_Rajcoomar Thank you :slight_smile:
Looks like you narrowed down the issue.

By using Iperf3 with the domain name $myadress$.duckdns.org I reach 268 Mbits/sec which is effectively the speed I see on Seafile (~30-35MB/s).

From my understanding that means that my router is the bottle neck. The solution would therefore be to buy a better router (I am currently using the standard ISP one).

Do you have any recommendation? What spec of a router data sheet would be important?

Correct!

I disagree! If your clients send requests for a local server to your router this is a configuration problem and not a hardware problem.

For Clients that don’t leave your local network it is far easier and better to add e.g.
$LOCALIPADDRESS $myadress$.duckdns.org
to your /etc/hosts file.

For mobile clients and/or if you have a lot of local clients use a local DNS server. There are nice projects out there e.g. Pi-hole

@germeier What a wonderful answer :slight_smile: You saved my day and project.

I didn’t know the purpose of the etc/hosts file beforehand. I also found out what NAT loopback is on a router. I learned quite a bit today, thank you!

I am now reaching 70MB/s upload and 95MB/s download on LAN with https enabled using Firefox. :partying_face:

Also the NGINX config is finally impacting the down/upload speed. :slight_smile:

I hope this thread will help future selfhosters, as I have found the issue arise often in forum posts.

1 Like

Please mark my post as the “solution” so others have a better chance to find it. Thanks!

I stumbled upon this thread while looking at a similar issue. I thought I’d add some input, although being an old post, might help some people in the future.

If you are using a reverse proxy with ssl for seafile, do not create a DNS record pointing to the seafile server, you need to point it to your reverse proxy where the ssl is issued from.

example:
dns record for your fqdn (mycloud.meee-dot-com) - points to wan ip 90.90.90.900
Seafile server - 192.168.1.1
Nginx reverse proxy server 192.168.1.2

On your local dns, create a record for the fqdn (mycloud.meee-dot-com) to 192.168.1.2 (the reverse proxy server).

Now, when you visit mycloud.meee-dot-com from your LAN, the requests will hit the proxy host, which will then forward it to the seafile and use the ssl cert without any issues.

All traffic while on your LAN will now route locally, and while not on your LAN, you will route via the WAN.

I hope I explained that well enough :slight_smile: