trotz intensiver Tests komme ich nicht weiter und benötige Hilfe. Es geht um eine On-Premise Nextcloud bei einem Kunden. Ich bin freiberuflich in der IT unterwegs, aber das Thema überschreitet inzwischen meine Nextcloud-/WebDAV-Tiefenkenntnisse. Der Kunde möchte unbedingt bei Nextcloud bleiben (Apps, Web, Plugins, Workflow), klassische SMB-Freigaben oder “nur Web”-Client sind für ihn keine Option - der Desktop-Client mit den (virtuellen Dateien) ist für ihn ein Kernfeature.
Setup (kurz):
ASUSTOR NAS mit 6× NVMe,
Uplink 10 GbE, Clients 1GbE.
Nextcloud läuft als ASUSTOR-App/Docker (Nextcloud 31.0.10.2).
DB bereits auf MariaDB migriert (ohne Besserung)
Das Problem ist die Performance über WebDAV bzw. den Desktop-Client. Zum Vergleich:
SMB direkt vom NAS: praktisch Fullspeed (Gigabit, ~120 MB/s)
Download über den Browser (Nextcloud Web): ebenfalls nahe Fullspeed
Nextcloud Desktop-Client: meist nur ca. 30–40 MB/s, teils darunter
Windows WebDAV (gemappt) gegen Nextcloud: ähnlich langsam
WebDAV direkt am ASUSTOR (ohne Nextcloud): auch deutlich unter SMB (ca. 60–70 MB/s)
CPU/RAM am NAS sind unauffällig (CPU im einstelligen Prozentbereich, genug Speicher), es wirkt nicht wie ein Hardware-Limit. In den Logs ist mir nichts Offensichtliches aufgefallen (keine klaren Errors, eher “einfach langsam”).
Kennt jemand dieses Verhalten (WebDAV/Client deutlich langsamer als SMB/Browser) in dieser Größenordnung und hat konkrete Ansatzpunkte, wo man sinnvoll ansetzt (Nextcloud-Konfig, Webserver/Proxy, Netzwerk/MTU, Client-Settings, ASUSTOR-spezifische Stolpersteine)? Ich kann bei Bedarf weitere Details/Logs nachreichen.
Und falls sich jemand hier wirklich tief mit Nextcloud + Networking auskennt: Eine professionelle Unterstützung auf Rechnung (gern per PN) wäre mir eine Freude. Ziel ist eine saubere, performante Lösung - sofern das mit Nextcloud realistisch ist.
Ich gehe davon aus, dass das Thema nicht trivial ist und nicht in 10min erledigt sein wird.
Danke euch!
Anhang
-Kopieren am PC - vom Nextcloud Ordner auf lokale Festplatte
die Werte sind nicht soo schlecht würde ich sagen. auch wenn die Kurve für mich aussieht als ob etwas bei ~370MBit/s limitiert, sonst würde ich mehr auuschläge nach oben und unten erwarten. Sicher ist es unschön wenn nur 50% der verfügbaren Bandbreite benutzt wird.. aber normalerweise syncronisiert ein Benutzer nicht täglich Gigabytes an Daten so dass das Limit im “real life” gut verschmerzbar ist. Wenn es doch ist musst du in der Tat ins Rabbithole absteigen und anfangen das System systematisch zu troublsehooten. Wir haben hier einige Diskussionen über (angeblich) schlechte performance ohne dass es klare und eindeutige Schrauben gibt.. wenn es welche geben würde wären sie logischerweise per default aktiv.
Ich würde speziell einen Vergleich von grossen und kleinen Dateien machen - wenn grosse Dateien deutlich schneller übertrage dann dürfte der Overhead auf der einen oder anderen Seite verantwortlich sein.. sonst ist irgendwo die Handbremse angezogen. vielleicht auch mal mit 2-3 Clients synchronisieren und schauen ob die NAS Bandbreite ausgelastet wird.
Ich kann mich an einen Post erinnern der Speziell WebDAV angesprochen hat..
vielen Dank für deine kompetente Antwort. Dash hilft mir etwas beim Einordnen.
Bei uns deutet aktuell vieles darauf hin, dass der Flaschenhals im WebDAV Pfad liegt, also Nextcloud WebDAV plus PHP plus Client Implementierung, vermutlich besonders unter Windows. Wie erwähnt: SMB direkt vom NAS läuft praktisch mit Fullspeed - WebDAV mit NCC Client liegt bei 1/3 bis 1/2 dieser Performance. Das ist leider ein KO Kriterium, weil es beim Kunden hauptsächlich um große Videodateien geht, die lokal im LAN hoch und runter geladen werden.
Synchronisieren im klassischen Sinn findet kaum statt, es wird aber das virtuelle Dateisystem des Nextcloud Clients genutzt, weil mehrere Terabyte Daten sonst gar nicht auf den PCs vorgehalten werden könnten. Ich habe zwei Tage sehr intensiv gesucht und getestet, bin aber nicht zu einem belastbaren Hebel gekommen. Daher wäre für mich auch eine ehrliche Aussage hilfreich, ob das bei Nextcloud über WebDAV in der Praxis einfach die obere Grenze ist
Danke auch für die Links zu ibizaman, scheint ein Crack zu sein - sein Block, superfundiert. Habe leider keine direkten Kontaktdaten (außer LinkedIn) gefunden. Falls du jemanden kennst, der in solchen Fällen wirklich tief drin ist, könntest du mir bitte jemanden empfehlen, gern auch per PN? Wir würden das Thema auch professionell und auf Bezahlbasis mit einem Profi angehen, falls es realistische Optimierungen gibt.
Ansonsten werde ich meinen Klienten leider davon überzeugen müssen, dass der Test mit NC eben gescheitert ist.. Nach etwas Recherche sind mir als realistische Alternativen eigentlich nur FileCloud (kostet, scheint aber ohne WebDAV auszukommen) oder Seafile (eigenes Protokoll/Blockansatz) begegnet. Mir ist sonst keine Lösung bekannt, die On Premise läuft, plattformübergreifende Clients und ein Webfrontend bietet, ein flexibles Benutzer und Rechtekonzept hat und gleichzeitig ohne WebDAV auskommt.
Ich sehe immer noch nicht den Grund warum du dein Experiment als gescheitert ansiehst… aber ich sehe dass ich letztes mal den falschen Link angehängt habe hier habe ich mehrere Tests dokumentiert und man sieht dass ich über 670MBit/s erreicht habe mit alter Hardware und HDD.
jedenfalls würde ich das System genauer anschauen oder auch “organisatorisch” helfen. Wenn ein Benutzer mit den grossen Video Dateien arbeitet wird meiner Meinung nach selten ad-hoc passieren.. sprich wenn ich plane demnächst ein Video Projekt zu bearbeiten und die Dateien auf dem Client lokal brauche dann markiere ich den VFS Ordner und wähle “immer local verfügbar” - der Client startet sofort mit dem Download und während ich mir einen Kaffee hole sind die Files schon da.. dann kommt es auch nicht darauf an ob es 1 oder 3 Minuten dauerte (oder wenn sie so gross sind dass es nicht reicht ist der Netzwerkzugriff eher die falsche Lösung bzw man muss den Download früher starten). und wenn ich mit dem Projekt fertig bin klicke ich “Speicher freigeben” und habe wieder nur noch VFS Platzhalter..
wobei ich sicher in 10GBit/s investieren würde wenn man es für die Arbeit braut - Zeit ist Geld und die Hardware mittlerweile gut bezahlbar.
Danke dir - 670 Mbit/s sind eine andere Hausnummer, vor allem wenn du das sogar mit älterer Hardware und HDD erreicht hast. Das würde auch zu den Werten passen, die ich beim direkten WebDAV-Mapping (Asustore NAS ohne NC).
Damit könnte man leben. Unsere Hardware ist deutlich stärker, RAID 6 auf NVMes, und das NAS hängt mit 10 Gbit Uplink am Switch. Daran sollte es also nicht liegen..
Damit wirkt es für mich zunehmend so, als ob der Flaschenhals eher in unserer konkreten Installation steckt, also Asustore - App Store Docker Stack oder die Container Konfiguration. Ich traue dem nicht - gut gemeint, schnell installiert - aber..Ich werde deshalb testweise Nextcloud auf einem separaten PC in einer VM als sauberen Docker Stack aufsetzen und die gleichen Transfers nochmal messen, um das einzugrenzen.
10 Gbit brauchen wir realistisch nicht als Ziel, der Internet Upload ist ohnehin bei 500 Mbit. Ich teste das am WE und melde mich dann hoffentlich mit besseren Ergebnissen.
“I’m experiencing a very similar issue. When accessing Nextcloud via IP + port directly in my LAN, the upload speed reaches around 85-90 MB/s. However, as soon as I use a domain name within the LAN (routed through a reverse proxy), the speed drops significantly to 35-41 MB/s. It seems the reverse proxy is creating a major bottleneck even for local traffic.”
Thx. I’m accessing Nextcloud directly via hostname or IP plus the mapped container port, so the ASUStore reverse proxy was never in the request path; in addition the PC is in the same network - no routing etc. I disabled it anyway, no change. At this point it looks like an ASUStore implementation issue, so I’m rebuilding the NC on a clean vSphere VM with Docker and an official Nextcloud AIO setup.
Please test, whether all traffic remains inside the network. In many cases the request travels via the internet back into the LAN to the Nextcloud instance - specially, if you call the URI. Keyword: DNS rebind
Thanks for the hint. In my case the tests are done from inside the LAN using direct IP plus port, and both the client and the NAS are in the same subnet. With that setup there should be no WAN hairpin involved, and the router WAN graphs also show no corresponding internet traffic during the test.
hier habe ich mehrere Tests dokumentiert und man sieht dass ich über 670MBit/s erreicht habe mit alter Hardware und HDD.