Forum Linux.débutant [Nextcloud] : Augmenter le débit descendant d'un serveur

Posté par  . Licence CC By‑SA.
Étiquettes :
1
25
nov.
2019

Bonjour à tous,

J'utilise actuellement le serveur nextcloud pour transférer mes data.

J'ai cherché pendant un moment pour augmenter le débit lorsque j'envoie un fichier sur mon serveur.
/var/www/html/nextcloud/config/config.php
/etc/php/7.3/apache2/php.ini
/var/www/html/nextcloud/.htaccess

Rien n'y fait, je plafonne à 1 Mo/s maximum.

Mon OS est debian buster, apache2 et php-7.3.

Merci d'avance.

  • # Pas la bonne piste ?

    Posté par  (Mastodon) . Évalué à 2.

    Salut,

    Le débit est très rarement une affaire de fichier de configuration de l'application (ici : Nextcloud). Quel type de serveur est-ce ? Comment t'y connectes-tu ?

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Pas la bonne piste ?

      Posté par  . Évalué à 1.

      Serveur debian buster.

      Je m'y connecte en ssh et j'ai fait un test de connection avec speedtest-cli.

      A priori c'est une affaire à régler avec mon FAI qui me promait 60Mb/s en montant et 1Gb/s en descendant.

      • [^] # Re: Pas la bonne piste ?

        Posté par  . Évalué à 2.

        A priori c'est une affaire à régler avec mon FAI qui me promait 60Mb/s en montant et 1Gb/s en descendant.

        1Gbps descendant (internet -> chez toi)
        60Mbps montant (chez toi -> internet)

        ok, et donc tu testes ton débit comment vers/depuis ton nextcloud ?

        sur quoi est-il hébergé ?
        car parfois tu auras beau avoir un super debit entre internet et la prise de ta box,
        ensuite il y a le debit :
        - entre la box et ton ordi (filaire ou wifi)
        - entre la connexion et le stockage (HDD, SSD, RAMfile ?)

        bref il nous faut plus d'infos.

        chez moi, par exemple, dans la meme piece, selon que je suis en wifi 2.4Ghz et 5Ghz je multiplie le debit par 5 avec le 2e choix, sur la meme machine.

        • [^] # Re: Pas la bonne piste ?

          Posté par  . Évalué à 1. Dernière modification le 25 novembre 2019 à 16:45.

          J'ai testé mon débit par iperf3 -c ping.online.net -p5207 et -R

          Débit montant 60 Mbits/s
          Débit descendant 546 Mbits/s

          il est hébergé chez Gandi.

          Je suis en RJ45.

          Mon PC c'est un CPU ryzen 3, 4Go de RAM DDR4 2333 MHz et HDD toshiba 5200tr/min (je crois) éco d'énergie de 2To.

          Box port Giga ethernet.

          • [^] # Re: Pas la bonne piste ?

            Posté par  . Évalué à 1.

            Si je désactive ufw et fail2ban, j'envoie à 1Mo/s au lieu de 745 Kbit/s.

          • [^] # Re: Pas la bonne piste ?

            Posté par  (Mastodon) . Évalué à 2. Dernière modification le 25 novembre 2019 à 22:13.

            J'ai testé mon débit par iperf3 -c ping.online.net -p5207 et -R

            Ce serait bien que tu testes le débit vers ton serveur particulièrement. Soit tu installes iperf3 (très bien d'ailleurs) sur ton serveur, soit tu fais un simple scp dessus, mais dans tous les cas des essais de vitesse vers ton serveur autrement que avec Nextcloud permettraient de cibler la limitation.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Pas la bonne piste ?

              Posté par  . Évalué à 1.

              En local depuis : 192.168.1.X/html
              -RJ45 en local box SFR - Client web nextcloud
              Avec nload : 50 Mo/s en descendant
              Avec nload : 50 Mo/s en montant (mais 500Ko/s si fichiers > 2Go)

              -RJ45 depuis internet (pas 3G/4G)
              2,5 Mo/s en descendant -> nload 2,5Mo/s incoming ; CPU 10% ; Io top jbd2/dm-1-8 15% max
              => problème réseau
              => en SFTP => 5Mo/s
              ==========> Nextcloud : à régler pour la réception (redis server besoin ? )

              ===> contre 7,5 Mo/s avec iperf3 -c ping.online.net -p5207

              6,2 Mo/s en montant (sur des fichiers > 2G => le CPU est à 100% pendant envoie car gunzip pas au dela de 512 Mo de cache php)
              => problème gunzip pendant envoie des données serveurs au client
              => contre test en sftp sans gunzip => 5,3 Mo/s (CPU 13%)
              ==========> Nextcloud :

              ===> contre 64 Mo/s avec iperf3 -c ping.online.net -p5207

              • [^] # Re: Pas la bonne piste ?

                Posté par  (Mastodon) . Évalué à 2. Dernière modification le 26 novembre 2019 à 08:45.

                Ah bin j'avais pas fait l'essai mais comme toi je trouve des chiffres curieux (attention, je parle en mega bits par seconde qui est le standard en communication, toi parfois en mega octets par seconde, donc divise mes chiffres par 8 si tu veux).

                • connexion fibre 300Mb/s, mon PC est en RJ45 Gb/s
                • serveur OVH 100Mb/s sur Internet (donc c'est ma limite)

                => Si je pushe un fichier en ssh par exemple, j'ai bien 100Mb/s mesurés
                => Si je pushe un fichier via Nextcloud je suis à 20Mb/s, le CPU du serveur OVH (un petit Atom) étant à 25% (rien d'extraordinaire donc).

                J'sais pô…

                EDIT : ce serait une limitation dûe au protocole WebDAV : https://help.nextcloud.com/t/sync-speed-limited-to-30mb-s-webdav-php-bottleneck/32546

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: Pas la bonne piste ?

                  Posté par  . Évalué à 1.

                  C'est possible que c'est à cause de ce protocole.

                  • [^] # Re: Pas la bonne piste ?

                    Posté par  (Mastodon) . Évalué à 2.

                    Et on n'est pas les seuls à l'avoir remarqué :)

                    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                    • [^] # Re: Pas la bonne piste ?

                      Posté par  . Évalué à 1.

                      Personne n'a de solution bien abouti.

                      J'ai juste relevé ces différentes vitesses :

                      Habituellement on me dit plus tôt l'inverse ^ ^ (on parle de minimum 4 machines dédiées, le tout conçu justement pour tenter de scaller webdav qui reste bloqué en lecture/écriture à 27Mo/s alors que
                      SFTP monte a +-45Mo/s,
                      FTP a +-80Mo/s et
                      glusterfs a 120Mo/s

                      • [^] # Re: Pas la bonne piste ?

                        Posté par  . Évalué à 1.

                        Pour améliorer les performances de nextcloud, ils ont ajouté redis-server à priori.

                        • [^] # Re: Pas la bonne piste ?

                          Posté par  . Évalué à 1.

                          Malgré tous, pourquoi ils mettent en config DAV off ?

                          https://www.c-rieger.de/nextcloud-16-installation-guide-debian-apache2/

                          <IfModule mod_ssl.c>
<VirtualHost *:443>
SSLEngine on
SSLOptions +StrictRequire
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
ServerAdmin mail@dedyn.io
DocumentRoot /var/www/html/nextcloud
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
ServerName your.dedyn.io
SSLCertificateFile /etc/letsencrypt/live/your.dedyn.io/fullchain.pem
SSLCACertificateFile /etc/letsencrypt/live/your.dedyn.io/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/your.dedyn.io/privkey.pem
<Directory /var/www/html/nextcloud/>
Options +FollowSymlinks
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/html/nextcloud
SetEnv HTTP_HOME /var/www/html/nextcloud
</Directory>
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15768000; preload"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set X-Content-Type-Options "nosniff"
#Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>
</VirtualHost>
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLCipherSuite TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
SSLOpenSSLConfCmd Curves X448:secp521r1:secp384r1:prime256v1
SSLOpenSSLConfCmd ECDHParameters secp384r1
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"
</IfModule>

                          • [^] # Re: Pas la bonne piste ?

                            Posté par  . Évalué à 1. 

                            <IfModule mod_dav.c>
    Dav off
</IfModule>

                            N'a pas l'air d'interférer avec Nextcloud. C'est une mesure de sécurité au cas où, pour une raison étrange (ou en suivant un mauvais tuto), tu aurais activé le module mod_dav d'apache2.

                        • [^] # Re: Pas la bonne piste ?

                          Posté par  . Évalué à 1.

                          Pour améliorer les performances de nextcloud, ils ont ajouté redis-server à priori.

                          Si ce n'est déjà fait, côté perf ajoute php-acpu : https://docs.nextcloud.com/server/17/admin_manual/configuration_server/caching_configuration.html#id1

                          Les codes PHP s’exécuteront de façon bien plus rapide. (Tu peux aussi passer par Redis en lieu et place, mais je trouve que acpu est plus rapide et moins contraignant pour du localhost)

  • # Commentaire supprimé

    Posté par  . Évalué à 0. Dernière modification le 26 novembre 2019 à 09:20.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -2. Dernière modification le 26 novembre 2019 à 09:16.

      Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.