Nextcloud Download bricht ab

  • Hallo zusammen!


    Ich verwende das Webhosting EiWoMiSau. Hierauf habe ich nextcloud installiert.


    Jetzt habe ich nur folgendes Problem. Der Download von Dateien oder Ordnern bricht ab:

    • Bei einer 100 Mbit/s Anbindung nach ca. 6,2 GB
    • Bei einer 50 Mbit/s Anbindung nach ca. 3 GB

    Immer nach ca. 8 Minuten. Mal nach 7 Minuten 22 Sekunden und mal nach 8 Minuten 45 Sekunden.


    Bei Leistungen steht "PHP Execution Time: 60s (120s Webhosting 8000)". Aber 8 Minuten sind ja eindeutig mehr als 60 bzw. 120 Sekunden.


    Gibt es da noch irgendein anderes Limit oder ein Timeout, das ich einstellen kann? Oder hat es was mit dem Output-Buffering zu tun? Bin an der Stelle leider mit meinem Latein am Ende.


    Vielen Dank schon mal für eure Tipps!

  • Nur beim Download.


    Mittlerweile habe ich rausgefunden, dass es nicht an nextcloud selber liegt.


    Zum Test habe ich mal folgendes Script ausprobiert:


    Hier ist das Verhalten genau so wie bei Nextcloud. Wenn meine Leitung schnell genug ist, schaffe ich es auch die Datei vollständig runterzuladen. Ist sie es aber nicht, bricht der Download ab.

  • Hay,


    und wenn Du das File mal direkt vom Webspace herunterlädtst, also ohne php-Kram drumherum? Damit kannst Du ausschließen, dass es am PHP liegt. Wie sieht es aus, wenn ein anderer oder Du von einem anderen Ort das File holt? Damit kannst Du ausschließen, dass es an Deiner Seite liegt. Wenn es "nackig" von einem anderen Ort dieselben Probleme macht, dann würde ich mal den Support anfragen, denn dann kann es nur noch am Webhost selbst liegen.


    CU, Peter

  • Was meinst du genau mit "von einem anderen Ort das File holen"? Von einem anderen Anschluss runterladen? Oder von einem anderen Webhost mal testen?

    Ja von einem anderen Anschluss, jedoch

    bricht der Download ja ohne PHP nicht mehr ab. Deshalb sollte ein Fehler deines Anschlusses auszuschließen sein.


    Welche PHP Konfiguration nutzt du im WCP und wie liefertst du die Daten aus, per apache oder nginx?


    Ansonsten würde ich, wie Peter, den Support kontaktieren.

  • Da tippe ich mal, dass du entweder das memory_limit oder die max_execution_time überschreitest, Die max_execution_time ist ja nicht die "echte" Zeit, die man mit einer Stoppuhr misst. Passt ja auch dazu, dass du mit einer schnelleren Verbindung mehr von der Datei laden kannst, bevor der Download abbricht.

  • Der Anschluss spielt dabei keine Rolle.

    Welche PHP Konfiguration nutzt du im WCP und wie liefertst du die Daten aus, per apache oder nginx?

    PHP 7.2.17 FastCGI von Apache bedient.

    Ich probiere jetzt mal FPM. Vielleicht bringt das ja einen Unterschied. Ansonsten frage ich mal beim Support nach.

    Da tippe ich mal, dass du entweder das memory_limit oder die max_execution_time überschreitest,

    In wie weit haben denn diese Werte Einfluss darauf? Das memory_limit ist 512 MB. Aber ich bekomme ja mehr als 512 MB runtergeladen. Und wie geht PHP denn mit der max_execution_time um? Falls du mir das erklären könntest, wäre das echt super.

  • Die max_execution_time legt die maximale Zeit in Sekunden zum Ausführen eines Scripts fest, bevor der Prozess vom System gekillt wird.


    Diese PHP Werte sollten aber für den Download keine allzu große Rolle spielen. Zur Not kannst du, um auf Nummer sicher zugehen, das PHP error reporting aktivieren (am besten inkl. logging) und schauen ob bei Abbruch des Downloads Fehler angezeigt werden.

  • Die max_execution_time legt die maximale Zeit in Sekunden zum Ausführen eines Scripts fest, bevor der Prozess vom System gekillt wird.


    Diese PHP Werte sollten aber für den Download keine allzu große Rolle spielen. Zur Not kannst du, um auf Nummer sicher zugehen, das PHP error reporting aktivieren (am besten inkl. logging) und schauen ob bei Abbruch des Downloads Fehler angezeigt werden.

    Aber:

    Quote
    Hinweis:
    Die set_time_limit()-Funktion und die max_execution_time Konfigurationsdirektive beschränken nur die Ausführungszeit des Skripts selbst. Zeit die für Aktivitäten außerhalb des Skripts aufgebracht wird wie z.B. die Ausführung von Systemaufrufen mit system(), Streamoperationen, Datenbankabfragen usw. werden nicht in die Berechnung der Ausführungszeit mit einbezogen.


    Nix genaues ist da leider nicht zu finden und finde ich auch sonst auf die Schnelle nirgends. Notfalls ausprobieren. Aber zwischen den Zeilen würde ich lesen - wegen "werden nicht in die Berechnung der Ausführungszeit mit einbezogen" - dass hier nicht stur die reale Ausführungszeit des gesamten Downloadvorgangs genommen wird.

  • Danke für die Erklärungen!

    Ich habe mittlerweile mal mit FPM statt FastCGI getestet. Und tatsächlich tritt hier das Problem nicht auf. Mein Problem ist damit also "gelöst".


    Trotzdem interessiert es mich noch, wieso das mit FastCGI nicht funktioniert. Ich frage dazu mal beim Support nach und gebe dann Bescheid.


    Vielen Dank für eure Hilfe.

  • Ich habe vom Support eine Antwort erhalten:

    netcup Team wrote:

    FPM steht für "FastCGI Process Manager". Dabei wird nicht für jedes PHP-Skript ein neuer Interpreter-Job gestartet, sondern mehrere FastCGI Prozesse sind im Hintergrund aktiv und warten auf Eingaben/Aufträge vom Webserver. Dadurch ist die Ausführung verlässlicher, da die Prozesse nicht vom Webserver abhängig sind (und auch nicht mit den Rechten des Webservers, sondern des PHP-FPM Benutzers ausgeführt werden).

  • Das umstellen auf FPM hat das ganze leider nicht behoben, sondern nur die Grenze der mindestens vorhandenen Downloadgeschwindigkeit etwas nach unten gesetzt.


    Folgendes Verhalten kann ich beim Download von https://vm0.de/5GB.php beobachten:

    • 5 GB Datei über 50 Mbit/s: nach ca. 14 Minuten erfolgreich
    • 5 GB Datei über 25 Mbit/s: nach ca. 5,5 Minuten abgebrochen

    Im Log finde ich folgende Fehlermeldungen:

    Code: error_log
    1. [Wed Apr 24 09:54:45.924903 2019] [proxy_fcgi:error] [pid 32264] [client XXX.XXX.XXX.XXX] AH01068: Got bogus version 166
    2. [Wed Apr 24 09:54:45.924972 2019] [proxy_fcgi:error] [pid 32264] (22)Invalid argument: [client XXX.XXX.XXX.XXX] AH01075: Error dispatching request to : (passing brigade to output filters)

    Ich hab auch schon versucht den Support zu kontaktieren, der stellt sich aber quer:

    netcup Support wrote:

    Bitte haben Sie dafür Verständnis, dass wir keinen Support zu Ihren Inhalten und Anwendungen anbieten können, da es schlicht unendlich viel Software, Versionen, Plugins und Optionen als Möglichkeiten gibt

    Dies würde schlicht jeglichen sinnvollen Supportrahmen sprengen.

    Wobei ich das starke Gefühl habe, dass meine Mail nur sehr halbherzig gelesen wurde. Es geht ja nicht konkret um eine Software, sondern um eine Grundfunktion von PHP. Aber ich bleibe da dran.

    Ehrlich gesagt habe ich keine Ahnung, was ich mir jetzt von euch erhoffe. Ich denke nämlich, dass nur der Support kann da wirklich was reißen. Aber vielleicht hat ja jemand eine Erleuchtung.

  • vielleicht hilft die "Serve static files directly by nginx" Funktion unter "Apache & nginx Settings"?

    Es handelt sich dabei ja nicht um eine statische Datei, sonder um eine Datei, die durch PHP "durchgeschliffen" wird. Also bringt die Einstellung leider nichts. Aber danke für deinen Tipp.


    Bin übrigens nach wie vor mit dem Support in Kontakt. Das Problem kann dort nachgestellt werden. Jedoch ist im Moment noch von einem Timeout von FastCGI die Rede. Dagegen spricht aber meiner Meinung nach, was ich oben erwähnt habe:

    5 GB Datei über 50 Mbit/s: nach ca. 14 Minuten erfolgreich
    5 GB Datei über 25 Mbit/s: nach ca. 5,5 Minuten abgebrochen

    Ich halte euch hier weiter auf dem Laufenden.

  • Ganz verstehe ich die Antwort vom Support nicht, aber sie klingt irgendwie plausibel:



    Also abschließend lässt sich sagen: Mit Apache klappt es einfach nicht. Mit "FPM served by nginx" jedoch schon. Ich verwende jetzt also nginx. Jetzt muss ich nur noch rausfinden, wie ich die Meldung weg bekomme:

    nextcloud wrote:

    PHP scheint zur Abfrage von Systemumgebungsvariablen nicht richtig eingerichtet zu sein. Der Test mit getenv("PATH") liefert nur eine leere Antwort zurück. Bitte die Installationsdokumentation auf Hinweise zur PHP-Konfiguration durchlesen, sowie die PHP-Konfiguration Deines Servers überprüfen, insbesondere dann, wenn PHP-FPM eingesetzt wird.