Wie viele Reverse-Proxy-Worker-Verbindungen benötigen resumable Uploads?
Es gibt keine sichere universelle Anzahl von Worker-Verbindungen für fortsetzbare Uploads. Legen Sie den Wert anhand der höchsten reproduzierbaren gleichzeitigen Socket-Auslastung fest und addieren Sie anschließend einen gemessenen Puffer.
Auf einem Heimserver kann ein einzelner sichtbarer Upload eine Client-Verbindung, eine Upstream-Verbindung und Leerlaufzeiten zwischen Chunks belegen, während der Browser es erneut versucht oder fortsetzt. Beginnen Sie mit den Live-Verbindungszahlen während des ausgelastetsten normalen Upload-Zeitraums, vergleichen Sie sie mit den Grenzwerten von Proxy und Betriebssystem und erhöhen Sie die Proxy-Einstellung nicht weiter, wenn zuerst Dateideskriptoren, Upstream-Worker, Arbeitsspeicher oder die Anwendung versagen.
Ermitteln Sie den Live-Bedarf an Upload-Verbindungen, bevor Sie ein Limit festlegen
Zählen Sie die Verbindungen während der relevanten Arbeitslast, nicht während der Proxy untätig ist. Starten Sie dieselbe Anzahl von Uploads, die Ihr Haushalt oder Ihr kleines Team voraussichtlich gleichzeitig ausführen wird, pausieren Sie mehrere Übertragungen und setzen Sie sie fort. Beziehen Sie auch mobile Clients ein, die nach dem Energiesparmodus erneut eine Verbindung herstellen. Erfassen Sie angenommene Client-Sockets, etablierte Upstream-Sockets und Verbindungen, die auf eine Upstream-Antwort warten.
Ein Worker-Limit wird von allen offenen Verbindungen belegt, die dieser Worker verarbeitet, nicht nur von abgeschlossenen HTTP-Anfragen. Deshalb müssen weitergeleitete Serververbindungen neben den Client-Verbindungen in die Messung einbezogen werden.
Verwenden Sie die höchste wiederholbar erreichte Gesamtzahl als Arbeitsgrundlage. Wenn die Gesamtzahl nur während Verbindungsstürmen ansteigt und schnell wieder sinkt, behandeln Sie diesen Spitzenwert getrennt vom anhaltenden Bedarf. Steigt sie weiter, während der Upload-Durchsatz unverändert bleibt, sollten Sie die wachsende Zahl nicht als legitime Kapazität betrachten. Untersuchen Sie zunächst die Upstream-Anwendung, Zeitüberschreitungen und festhängende Sitzungen, bevor Sie einen Wert erhöhen.
Übersetzen Sie den Socket-Bedarf in eine Kapazität pro Worker
Bei einem Reverse-Proxy belegt ein aktiver Upload häufig gleichzeitig eine Client-seitige und eine Upstream-seitige Verbindung. HTTP-Keepalive, Zustandsprüfungen, WebSocket-Sitzungen und Administrationsdatenverkehr verbrauchen zusätzliche Plätze. Betrachten Sie das Doppelte der gleichzeitigen Upload-Anzahl als Ausgangsmodell, nicht als endgültige Antwort, denn die gemessene Gesamtzahl der Sockets ist zuverlässiger als eine Faustregel.
Eine sichtbare Verbindungsobergrenze pro Worker kann neue Clients ablehnen, während etablierte Übertragungen fortgesetzt werden. Vergleichen Sie den ausgelastetsten Worker mit seinem konfigurierten Limit und prüfen Sie anschließend das Limit für geöffnete Dateien des Dienstprozesses. Ein höherer Proxy-Wert kann keine Dateideskriptoren erzeugen, die der Prozess nicht öffnen darf.
Wählen Sie ein Ziel oberhalb des ausgelastetsten wiederholbaren Worker-Werts und lassen Sie ausreichend Spielraum für den beobachteten Wiederholungsansturm sowie den normalen Datenverkehr außerhalb von Uploads. Multiplizieren Sie nicht mit jedem möglichen Client und Chunk, wenn diese Verbindungen nie gleichzeitig bestehen. Wenn die Betriebssystemgrenze niedriger ist, passen Sie zuerst diese Ebene an oder halten Sie das Proxy-Ziel darunter.
Testen Sie den ursprünglichen Fortsetzungsweg und interpretieren Sie den Fehler
Wiederholen Sie den genauen Auslöser: Starten Sie die vollständige Upload-Menge, unterbrechen Sie mehrere Clients und setzen Sie sie fort, während die übrigen Übertragungen aktiv sind. Beobachten Sie die Annahme neuer Verbindungen, das Wiederholungsintervall, den Upload-Durchsatz, Proxy-Fehlermeldungen, die Upstream-Antwortzeit und die Anzahl geöffneter Dateideskriptoren. Eine synthetische Anfrage, die keinen Body hochlädt, testet nicht denselben Ressourcenpfad.
Wenn der Proxy meldet, dass die Worker-Verbindungen erschöpft sind, während gleichzeitig neue Uploads fehlschlagen, ist das Limit ein belegter Engpass. Schlagen neue Anfragen wegen einer Body-Größenbegrenzung, einer Zeitüberschreitung, eines nicht verfügbaren Upstreams oder eines Anwendungswarteschlangenfehlers fehl, während die Verbindungsnutzung unter der Obergrenze bleibt, wird eine höhere Worker-Einstellung den Fehler nicht beheben. Eine Berechnung des Verbindungslimits muss weiterhin das Limit für geöffnete Dateien und die zweiseitigen Sockets des Proxys berücksichtigen.
Ändern Sie jeweils nur eine Ebene. Erhöhen Sie das Worker-Limit erst, wenn Protokoll- und Socket-Daten es als Ursache ausweisen, laden Sie den Proxy neu und wiederholen Sie dasselbe Unterbrechungsmuster. Wandert der Fehler zum Upstream-Dienst oder zum Dateideskriptor-Limit, halten Sie an. Sie haben die nächste Einschränkung erreicht, statt nachgewiesen zu haben, dass noch mehr Proxy-Verbindungen sinnvoll sind.
Lassen Sie ausreichend Spielraum und legen Sie eine Abbruchbedingung fest
Lassen Sie zwischen dem ausgelastetsten beobachteten Worker und der konfigurierten Obergrenze einen Puffer, leiten Sie ihn jedoch aus der tatsächlichen Schwankung ab. Ein kleiner Server mit stabilem Haushaltsverkehr benötigt weniger spekulative Reserve als ein öffentlicher Dienst mit unvorhersehbaren Spitzen. Dokumentieren Sie Grundlage, Zielwert, Worker-Anzahl, Dateilimit des Prozesses und Spitzenwert, damit die nächste Änderung verglichen und nicht geraten werden kann.
Die Verbindungskapazität ist nur eine Ebene des Upload-Pfads. Wenn ein Dashboard funktioniert, aber ein bestimmter Synchronisierungs- oder Upload-Pfad fehlschlägt, müssen der fehlschlagende Endpunkt und die Methode weiterhin isoliert werden, bevor der Proxy als fehlerfrei betrachtet wird.
Die Änderung ist erfolgreich, wenn zwei vollständige Fortsetzungstests abgeschlossen werden, neue Verbindungen weiterhin angenommen werden, die Fehlerprotokolle sauber bleiben und der ausgelastetste Worker einen stabilen Puffer behält. Machen Sie die Erhöhung rückgängig, wenn sich Speicherdruck oder Latenz verschlechtern, ohne dass die Fehler abnehmen. Eskalieren Sie an die Anwendungs- oder Speicherebene, wenn die Verbindungsnutzung deutlich unter dem Limit liegt, Uploads aber weiterhin in Warteschlangen landen, wegen Zeitüberschreitungen fehlschlagen oder ihren Fortsetzungsstatus beschädigen.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
So planen Sie Restic-Aufgaben für Backup, Forget und Prune ohne Sperrkonflikte
Ein vollständiger Restic-Zeitplan für mehrere Hosts, der häufige Backups, eine gezielte Aufbewahrung, physisches Pruning, Prüfungen, Wiederholungsversuche und die Validierung von Wiederherstellungen voneinander trennt.
So verhindern Sie, dass Restic-Prune-Aufträge geplante Backups blockieren
Ein Präventionsplan für gemeinsam genutzte Restic-Repositories, der Sicherungsfenster von Prune trennt und Sperren, Wiederholungsversuche sowie Warnmeldungen beibehält.
So entfernst du eine veraltete Restic-Sperre, ohne eine aktive Sicherung zu unterbrechen
Ein möglichst wenig invasiver Restic-Entsperr-Workflow, der aktive Backups schützt, nur veraltete Zustände entfernt und die Wiederherstellung im Rahmen des normalen Zeitplans bestätigt.
