NC: Laden des Toplevel-Verzeichnisses dauert lange

[Rüdiger Kupper]

Das Anzeigen des Toplevel-Verzeichnisses dauert immer recht lange und die SFTP-Shares erscheinen erst nacheinander. Sobald man sich hingegen in einem der Shares befindet, geht das Auflisten recht zügig.

[Rüdiger Kupper]

Diese Foreneinträge legen nahe, dass es tatsächlich ein NC-internes Problem sein könnte. Allerdings nutzen die meisten Nutzer SMB-Shares. Aber es könnte auch sein, dass grundsätzlich die Zahl der eingebundenen externen Quellen die Performance verschlechtert:

​https://help.nextcloud.com/t/very-slow-web-interface-with-external-smb-storage-with-approx-80000-files-and-folders/57227/7

-> ich werde als Sofortmaßnahme erst mal die Zahl der Verzeichnisse reduzieren. Das Downloads-Verzeichnis muss nicht unbedingt extern zugreifbar sein, und das Vorlagen-Verzeichnis haben die meisten unserer Nutzer vermutlich nicht mal entdeckt (siehe Ticket zu den Fortbildungen ;-)).
Vielleicht bringt das schon etwas Performancegewinn.

[Rüdiger Kupper]

Habe die Freigaben für ~/Downloads ~/Videos und ~/Vorlagen entfernt, weil ich vermute, dass die selten genutzt werden. Bitte um Rückmeldung, ob das den Zugriff beschleunigt.

[Rüdiger Kupper]

Das ist derzeit das vordringlich zu lösende Problem mit NC.

[Rüdiger Kupper]

Ich versuche gerade mal, mich dem Problem irgendwie zu nähern. Bin auf rechner-lz-02 eingeloggt und mache von da aus ssh auf den cloud-Rechner (10.16.112.16). Einmal als Nutzer "kup" und einmal als Nutzer "root" und messe die Zeit, bis der Login abgeschlossen ist:

kup@rechner-lz-02:~$ time ssh 10.16.112.16 exit

real	0m1,241s
user	0m0,025s
sys	0m0,006s

kup@rechner-lz-02:~$ time ssh root@10.16.112.16 exit

real	0m0,241s
user	0m0,023s
sys	0m0,008s

Ein Login al normaler Nutzer dauert also etwa 1,2s, als root 240ms.

Jetzt vom Rechner cloud nach localhost (so macht es NC):

kup@cloud:~$ time ssh localhost exit

real	0m1,165s
user	0m0,012s
sys	0m0,004s

Login dauert lokal für normale Nutzer also ebenfalls über eine Sekunde. Bei unseren 7 eingebundenen Ordnern erwartet man also schon mal ca. 8 Sekunden.

Aber warum dauert der Login für normale Nutzer so lange?

[Rüdiger Kupper]

Dagegen das selbe Szenario auf rechner-lz-02:

kup@rechner-lz-02:~$ time ssh kup@localhost exit

real    0m0,369s
user    0m0,031s
sys     0m0,005s

Warum dauert das selbe auf dem cloud-Rechner so viel länger? Das ist doch letztlich ein Client genau wie die Klassenraumrechner? Auf denen geht der Login aber eine Sekunde schneller?

[Rüdiger Kupper]

@bau

Hier müssen wir gemeinsam auf die Suche gehen: Kann der lxc-Container dazwischenfunken? Ich habe mit den Containern keine Erfahrung. Vielleicht sollten wir den cloud-Rechner einfach mal in eine volle VM verfrachten oder sogar auf bare metal, um zu testen, ob die Containerisierung die Ursache ist. Ein dedizierter Rechner für NC ist in jedem Fall anzustreben.

[bau]

Prinzipiell funktioniert ein Container genau wie eine andere Maschine.
Vorteil von LXC ist, dass man nur einmal den Kernel am Laufen hat und nicht wie bei qemu/kvm eine komplette VM in der dann der Kernel nochmals läuft.

Erinnerung: Wir haben die VM deshalb, weil wir keinen gesamt-Reset der Maschine machen müssen - also normalerweise der Host weiterläuft, und nur die VM neu startet - UND - die VM sich problemlos auf andere Maschinen umziehen lassen.

[bau]

Hast du mal die LDAP-Anbindung auf dem Next-Cloud mit der auf dem Rechner im LZ verglichen?
auf dem Next-Cloud-Server ist ldaps eingetragen. Wenn da beim Aushandeln was schiefläuft (hatten wir bei LDAP schon häufiger) dann dauert das unnötig lange - wir sind immerhin im Schulverwaltungsnetz, da brauchen wir kein SSL.

[Rüdiger Kupper]

Guter Hinweis, ich schaue nach. Außerdem werde ich mal die alten Wikiseiten durchgehen, wo ich notiert hatte, wie man einen Linuxmusterclient komplett von Hand neu aufsetzt und was man wo in die Configs eintragen muss. Mit dieser Anleitung ist ja auch das Image entspranden, das auf den Klassenraumrechnern ist. Vielleicht fehlt da irgend ein Schritt – ich hatte gestern den Verdacht, dass der nscd (Name Sewrvice Caching Daemon) nicht installiert ist, doch der läuft. Der soll ja LDAP-Anfragen lokal zwischenspeichern. Auffällig ist jedoch, dass der nscd auf rechner-lz-02 sehr viel mehr "Cache Hits" aufweist, als der auf dem cloud-Rechner. Und das, obwohl der Rechner im LZ nur einen Tag lief und die Cloud seit 8 Tagen.
"nss" gibt es auch noch, ich erinnere mich dunkel, dass das irgendwo eingertagen werden musste (pam-auth??). Das steht aber in der besagten Anleitung, wenn ich heute Zeit habe, gehe ich mal durch.

[Stephan Richter]

Abgesehen vom ldap / user login könnte es theoretisch auch daran liegen, dass root ein lokales HOME hat und alle anderen Nutzer vermutlich ein externes, über NFS gemountetes!?

...nur so eine Idee.

[Rüdiger Kupper]

Ja, richtig. Doch da der Login auf rechner-lz-02 als Nutzer kup (mir NFS-Home) ebenfalls schnell ist, habe ich diesen Grund verworfen. Es wäre azch sektsam, denn die NFS-Homes sibd auf der Maschine dauerhaft gemountet (vom Boot an)

[Rüdiger Kupper]

Gerade gehen mir mal wieder die Ideen aus – was für ein seltsames Problem! Keine meiner Vermutungen hat sich bestätigt: Der cloud-Rechner scheint ganz genau so wie alle Klassenraum- und LZ-Rechner konfiguriert zu sein. Nur, dass dort der SSH-Login eine Sekunde schneller geht. Falsche Benutzerrechte auf Systemverzeichnissen konnte ich auch nicht finden. Und im Syslog und Kernellog findet sich nichts, was mit der Verzögerung zusammenhängen könnte.

Der lxc-Container selbst könnte vielleicht die Ursache sein, doch ich konnte keinen Grund ergoogeln, warum. Andere Leute haben ihre NC-Instanz auch im lxc-Container laufen. Ob die natürlich SFTP zur Anbindung benutzen …?

Wie immer, wenn man ein Problem nicht lösen kann, geht man auf die Suche nach Workarounds und mir ist da einer eingefallen, der funktionieren müsste: Symlinks statt mehrer SFTP-Einbindungen.
Wir legen in den Homeverzeichnissen der Nutzer ein Verzeichnis an, in dem alle Server-Verzeichnisse, die eingeunden sein sollen, verlinkt sind. Dieses "Link-Verzeichnis" binden wir dann als externen Speicher per SFTP an.
Aus Sicht der Nutzer ändert sich dabei fast nichts, außer, dass in NC nun die Verzeichnisse auf dem Fileserver nicht mehr direkt im Toplevel-Verzeichnis erscheinen, sondern unterhalb eines Verzeichnisses, das z.B. "Server" heißt. Herdurch reduziert sich die Zahl der nötigen SFTP-Verbindungen aber auf 1 pro Nutzer, statt wie bisher 7.
Das löst zwar nicht das eigentlich zugrundeliegende Problem, doch es reduziert dessen Auswirkungen erheblich. Und der Komfortverlust für die Nutzer ist gering, sie müssen einen Klick mehr machen.

@rich

Könntest Du das mal mit Deinem Testnutzer "richtest" ausprobieren und schauen, ob es besser funktioniert? Dieser Nutzer ist weder in der Gruppe "teachers" noch "Schüler", hat die üblichen SFTP-Zugriffe also nicht eingebunden. Ich habe in Deinem Homeverzeichnis ein entsprechendes Verzeichnis mit Links angelegt. Du kannst es folgendermaßen einbinden:

• als richtest in der Cloud anmelden
• Einstellungen -> Externer Speicher
• Speicher hinzufügen mit:
  • Ordnername: Server
  • Methode: SFTP
  • Anmeldemethode: Benutzername und Passwort
  • Host: localhost
  • Root: /home/teachers/rich/Server
  • Benutzername: rich
  • Passwort: (Dein Passwort als Nutzer rich)

Danach müsste der richtest-Nutzer die Server-Verzeichnisse von Nutzer rich bei den Dateien sehen.
Nextcloud wird dann erst mal anfangen, die Verzeichnisse neu zu indizieren, was etwas dauern kann. Solange bei der Verzeichnisgrößer noch "Ausstehend" steht, ist die Indizierung nicht fertig. Danach ist der Zugriff aber hoffentlich performanter als bisher.

Danke für's Ausprobieren!

[Stephan Richter]

Funktioniert tadellos. Das Top-Level lädt jetzt zügig und die Unterordner wie bisher auch schon akzeptabel schnell.

[Rüdiger Kupper]

Na, das ist doch mal eine erfreuliche Nachricht! Ich bin zwar kein großer Fan von Workarounds, weil einem das Problem doch meist früher oder später wieder auf die Füße fällt. Aber das wäre dann wohl zum jetzigen Zeitpunkt die Methode der Wahl.

[Rüdiger Kupper]

Habe das SFTP-Share jetzt für alle Nutzer umgestellt (wir haben inzwischen 276). NC scannt jetzt erst mal die Verzeichnisse neu.

@rich

Die Tablet-Nutzer, die ihre TT-Datenbank in ihr Dokumente-Verzeichnis gesynct haben, müssen ihren Pfad jetzt auf Fileserver/Dokumente ändern. Sonst landet die DB nicht auf dem Fileserver, sondern lokal auf dem cloud-Rechner, wo die Nutzer nur die mickrigen 64MB frei haben.

[Rüdiger Kupper]

Infomail geht dann morgen raus, ich hoffe, bis dahin ist der Filescan durch.

[Stephan Richter]

Ich habe gerade versucht mein TeacherTool umzustellen auf das neue WebDAV Zielverzeichnis:

• der Ordner Fileserver taucht in der kepler-cloud auf und sieht gut aus
• ich konfiguriere das WebDAV neu --> Upload schlägt fehl
• in der kepler-cloud ist "Fileserver" plötzlich rot hinterlegt; die Netcloud-App zeigt ihn an, aber ist angeblich leer

Ich habe nun als User nochmal das Verzeichnis "Server" unter einem anderen Namen eingehängt und so funktioniert es jetzt.
Wenn es anderen Nutzern aber so ergeht wie mir und oben beschrieben, sehe ich etwas schwarz.

[Rüdiger Kupper]

Keine Ahnung, was da passiert :-(. Ich habe grade vorübergehend die File-Versionierung abgeschaltet, vielleicht hatte das Auswirkungen. Mal schauen, wie es sich entwickelt.

[Rüdiger Kupper]

Bei mir funktioniert der WebDAV-Zugriff wie er soll (Linux-Laptop).

Aber noch mal die Frage: Wieso richtest Du am Tablet den WebDAV-Zugriff von Hand ein? Die Nextcloud-App macht die Ordner doch automatisch als Speicherorte im Dateimanager verfügbar? Ich könnte mir vorstellen, dass die App es gar nicht so mag, wenn man daran vorbei noch einen zweiten WebDAV-Zugang manuell einrichtet.

[Rüdiger Kupper]

Replying to rich:

Ich habe nun als User nochmal das Verzeichnis "Server" unter einem anderen Namen eingehängt und so funktioniert es jetzt.

Das ist vermutlich keine so gute Idee, weil Du dann über zwei verschiedene Verbindungen auf das Selbe Verzeichnis auf dem Server zugreifst. NC weiß aber nicht, dass es das selbe Verzeichnis ist. Das könnte zu allen möglichen unerwarteten Effekten führen.

[Rüdiger Kupper]

Das Link-Verzeichnis, das unter "Fileserver" erscheint, ist genau so aufgebaut wie Dein Verzeichnis "Server", da darf es also keinen Unterschied geben?
Bist Du sicher, dass Du in einem der Subverzeichnisse landest (Dokumente, etc …?). Im Verzeichnis "Fileserver" selbst haben die Nutzer nämlich kein Schreibrecht.

[Stephan Richter]

• TeacherTool kann die Datenbank nur per icloud oder webdav syncen. Ich verstehe nicht genau was du mit "an der app vorbei" meinst. Es ist doch vollkommen egal ob ich mit 1, 2 oder 42 Clients auf die Nextcloud zugreife (auch wenn die sich auf dem gleichen Gerät befinden)
• ich weiß nicht was du mit "mein Verzeichnis Server" meinst. In meinem HOME ist ein Verzeichnis Server (root:root), das du erstellt hast. Ich gehe mal davon aus, dass das bei allen Nutzern so ist,
• ich habe eben dieses Verzeichnis nun einfach nochmal als externes Verzeichnis in NC eingebunden (als "Linux", aber das ist ja egal)

Es ist bei mir also weiterhin so, dass Verzeichnisse die per default eingebunden sind meistens nicht laden. Verzeichnisse die ich selbst einbinde, laden immer (siehe Anhang).

[Rüdiger Kupper]

Replying to rich:

• TeacherTool kann die Datenbank nur per icloud oder webdav syncen. Ich verstehe nicht genau was du mit "an der app vorbei" meinst. Es ist doch vollkommen egal ob ich mit 1, 2 oder 42 Clients auf die Nextcloud zugreife (auch wenn die sich auf dem gleichen Gerät befinden)

Grundsätzlich hast Du Recht. Für die Nextcloud-App ist es vielleicht nicht egal, aber das weiß ich nicht. In der Logik von Tablet-Apps würde ich vermuten, dass die App sich als zentraler Zugangsweg zu Deiner Cloud betrachtet. Sie legt für Dich den WebDAV-Zugang als Speicherort auf dem Tablet an. Greifst Du dann gentrennt davon über WebDAV zu, erfährt die App davon ja nichts. Für den Nexcloud-Server kommen die beiden Anfragen aber von der selben IP. Ob das alles so reibungslos klappt, weiß ich nicht. – Im besten Fall sollte es ;-).

• ich weiß nicht was du mit "mein Verzeichnis Server" meinst. In meinem HOME ist ein Verzeichnis Server (root:root), das du erstellt hast. Ich gehe mal davon aus, dass das bei allen Nutzern so ist,

Nein, das Verzeichnis habe ich nur für Dich zum Testen eingerichtet. Die Link-Verzeichnisse in den Homes der User heißen ~/.links-kepler-cloud und werden in die Cloud unter dem Namen "Fileserver" per SFTP eingebunden. Die sind aber genau so aufgebaut wie Dein "Server"-Verzeichnis. Du solltest also nur eins davon mounten :-).
Die Verzeichnisse sind versteckt, daher haben die Nutzer dort auch kein Schreibrecht. Denn würden sie dort Dateien speichern, würden sie sie auf den Schulrechnern niemals wiederfinden.

• ich habe eben dieses Verzeichnis nun einfach nochmal als externes Verzeichnis in NC eingebunden (als "Linux", aber das ist ja egal)

Es ist bei mir also weiterhin so, dass Verzeichnisse die per default eingebunden sind meistens nicht laden. Verzeichnisse die ich selbst einbinde, laden immer (siehe Anhang).

Der einzige Unterschied, der mir dazu einfällt, ist, dass Du selbst vermutlich als Authentifizierung "Login und Passwort" gewählt hast. Die automatisch eingebundenen nutzen "Zugangsdaten in der Datenbank speichern". Sonst sehe ich überhaupt keinen Unterschied mehr, das läuft eigentlich völlig gleich ab.
Treten die gleichen Probleme auf, wenn Du "in Datenbank speichern" auswählst?

[Rüdiger Kupper]

Ich hab Dir jetzt mal einen Link nach ~/Schule im Link-Verzeichnis gesetzt und das Verzeichnis Server entfernt. Vielleicht hattest Du einfach etwas viele verschiedene Wege zum selben Verzeichnis. (Nutzer richtest hatte das ja auch noch eingebunden, vermute ich.)

[Rüdiger Kupper]

Völlig verrückt: Eine ssh-Verbindung zum paedml geht vom Cloud-Rechner rasend schnell, aber nach localhost hängt es.

kup@cloud:~$ time ssh 127.0.0.1 exit

real	0m1,159s
user	0m0,008s
sys	0m0,008s
kup@cloud:~$ time ssh paedml exit

real	0m0,069s
user	0m0,010s
sys	0m0,000s

[Rüdiger Kupper]

Hier ist endlich ein Hinweis. In /var/log/auth.log taucht beim Herstellen der ssh-Verbindung auf:

Oct 22 14:43:30 cloud sshd[14085]: Accepted password for kup from ::1 port 43660 ssh2
Oct 22 14:43:30 cloud sshd[14085]: pam_unix(sshd:session): session opened for user kup by (uid=0)
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: could not connect to any LDAP server as cn=admin,dc=kg-fds,dc=de - Can't contact LDAP server
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: failed to bind to LDAP server ldap://10.16.112.4/: Can't contact LDAP server
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: reconnecting to LDAP server...
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: could not connect to any LDAP server as cn=admin,dc=kg-fds,dc=de - Can't contact LDAP server
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: failed to bind to LDAP server ldap://10.16.112.4/: Can't contact LDAP server
Oct 22 14:43:30 cloud systemd-logind: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Oct 22 14:43:31 cloud systemd-logind: nss_ldap: could not connect to any LDAP server as cn=admin,dc=kg-fds,dc=de - Can't contact LDAP server
Oct 22 14:43:31 cloud systemd-logind: nss_ldap: failed to bind to LDAP server ldap://10.16.112.4/: Can't contact LDAP server
Oct 22 14:43:31 cloud systemd-logind: nss_ldap: could not search LDAP server - Server is unavailable
Oct 22 14:43:31 cloud systemd-logind[105]: New session 436251 of user kup.

Von der Kommandozeile aus kann ich aber ldap-Abfragen machen. Das sind zwar verschiedene ldap-Client-Programme, doch sie sind gleich konfiguriert. Und: Wieso kann ich mich überhaupt mit meinem Passwort einloggen, wenn der ldap-Server nicht erreichbar ist?!

[Rüdiger Kupper]

Jedenfalls müsste daher die zusätzliche Sekunde kommen: "(sleeping 1 seconds)..."

[Rüdiger Kupper]

Halleluja! Ich hab's endlich gelöst. Es ist dieser Bug hier, dem wir aufgesessen sind:

​https://bugs.launchpad.net/ubuntu/+source/nis/+bug/1934393

Auslöser war mal wieder unser spezieller Freund systemd. Genauer, der systemd-logind, der sich um das Erstellen der Nutzersitzungen beim Login kümmert. Sysmtemd klinkt sich ja an allen möglichen Stellen in die existierenden Dienste ein – natürlich mit dem Ziel, es besser und sicherer zu machen. Dabei ist es immer so: Systemd versucht, den Dienst zuerst zu erledigen. Misslingt das, kommen die Dienste wie bisher auch zum Aufruf. Und genau so etwas haben wir hier gesehen.

Mit Ubuntu 20.04 (das ist die Version, unter der unser Cloud-Container läuft) gab es eine Änderung im systemd-logind: Für mehr Sicherheit läuft dieser jetzt in einer Sandbox, die nur bestimmte Operationen erlaubt. Und Netzwerkzugriff ist nicht erlaubt. Wie im obigen Bugreport gut erläutert macht das z.B. einen LDAP-Zugriff unmöglich. Trotzdem gelingt der Login, weil danach der "alte" Mechnismus greift und dieser ist nicht gesandboxt.

Obwohl das Problem seit Version 20.04 existiert, hat es bis Juli 21 gedauert, bis er in einem Bugreport beschrieben wurde. Vorher gab es zwar schon viele Tickets zu mysteriösen Wartezeiten und Fehlern, doch niemand hat das auf die Sandbox des logind zurückgeführt.

Der Ablauf bei einem SSH-Login ist so:

ssh bekommt Anfrage auf Port 22
-> ruft PAM auf
-> Pam ruft zuerst systemd-logind auf (ab jetzt befinden wir uns in der Sandbox)
-> logind ruft eine glibc-Funktion auf, um Nutzerdaten zu erhalten (läuft also ebenfalls in der Sandbox)
-> die glibc-Funktion fragt verschiedene konfigurierte Quellen ab: nscd, /etc/passwd, LDAP, …
-> In /etc/passwd stehen nur lokale User wie root (deshalb gab es bei dem die Verzögerung nicht!).
-> Eine LDAP-Anfrage schlägt fehl, weil die Sandbox keinerlei Netzwerkzugriff erlaubt. (Daher kommen die Fehlermeldungen in /var/auth.log)
-> Nach dem ersten Fehlschlag wartet die Funktion eine Sekunde und probiert es erneut. (Daher kam die 1s Verzögerung). Danach meldet sie zurück, dass der Nutzer nicht gefunden wurde.
-> Nun meldet auch systemd-logind an PAM zurück, dass der Nutzer nicht gefunden wurde.
-> Da systemd nur eine der Optionen ist, die in PAM konfiguriert sind, fährt das jetzt mit der nächsten Option fort und fragt selbst beim nscd an – nun aber nicht mehr in der Sandbox!
-> nscd macht die LDAP-Anfrage und liefert die Nutzerdaten zurück
-> Login gelingt.

Dashalb konnten sich unsere Nutzer anmelden, doch es kam zu der Verzögerung.

Die Lösung ist wie im Bugreport beschrieben, man erlaubt Netzwerkzugriff in der logind-Sandbox. Bei systemd läuft das so:

# systemctl edit systemd-logind

Einfügen:

[Service]
RestrictAddressFamilies=AF_INET AF_INET6
IPAddressAllow=any

Nach einem Neustart aller beteiligter Komponenten (bzw. Reboot) ist die 1s-Verzögerung weg:

kup@cloud:~$ time ssh localhost exit

real	0m0,159s
user	0m0,016s
sys	0m0,000s

Mann, wie viele Stunden hat mich dieser blöde Bug gekostet!!

[bau]

Herzlichen Glückwunsch!
Wann wollen wir den Sekt trinken!

Es ist immer wieder erhebend, wenn so ein Problem gelöst ist!

[Rüdiger Kupper]

Replying to bau:

Herzlichen Glückwunsch!
Wann wollen wir den Sekt trinken!

Ja, genau so habe ich mich auch gefühlt, als es endlich klappte.

Allerdings haben wir auch gleich das nächste Problem, das zu lösen ist. Ich dachte, das löst sich mit diesem Ticket von selbst, war aber leider nicht so. (Ticket folgt.)

[Rüdiger Kupper]

Überwachen des auth.log hat übrigens ergeben, dass tatsächllich bei jedem Dateizugriff die SSH-Verbindung wieder neu hergestellt und dann wieder beendet wird. Also jedesmal, wenn man ein Verzeichnis auf dem Fileserver auflistet, jedes Mal, wenn man eine Datei anklickt, u.s.w.

Das ist aus Sicht von Nextcloud vielleicht nachvollziehbar, denn das "Externe Verzeichnis" könnte ja auf einem entfernten Rechner im Internet liegen, hinter einer unzuverlässigen Verbindung, etc.
In unserem Setting ist das aber natürlich überflüssig: Wir haben die Fileserver-Verzeichnisse ja direkt auf dem Cloud-Rechner dauerhaft gemountet und NC macht die SSH-Verbindung nach localhost. Es würde völlig reichen, da für einen Nutzer einmalig eine SSH-Verbindung aufzubauen und diese dann dauerhaft zu benutzen. Ich sehe aber leider keine Möglichkeit, NC das beizubringen. Ich kann nur mal einen Featurerequest an die Entwickler schreiben …

@lehm

Das Problem in diesem Ticket (1s Verzögerung bei jedem Dateizugriff) müsste auch ein Grund gewesen sein, wieso Dein Upload-Versuch mit vielen kleinen Dateien so langsam war. Mit jeder neuen Datei gab es eine Wartezeit von 1s. Falls Du Lust hast, teste es doch noch mal, es müsste jetzt schneller gehen.

[lehm]

Alles klar, ich teste.

[lehm]

Getestet.
Beim Upload einer einzelnen großen Datei gibt exakt alle 10 MB eine kurze Unterbrechung. Das sind bestimmt die 10-MB-Packete, die der Dienst da schnürt.

Der Upload vieler kleiner Dateien hat sich vielliecht etwas aber leider nicht nennenswert beschleunigt.