Hoeveel reverse-proxy-werknemersverbindingen hebben hervatbare uploads nodig?

Er is geen veilig universeel aantal werkverbindingen voor hervatbare uploads. Stem dit af op de hoogste gelijktijdige socketbehoefte die je kunt reproduceren en voeg daarna gemeten speelruimte toe.

Op een homeserver kan één zichtbare upload een clientverbinding, een upstreamverbinding en inactieve tijd tussen chunks bezet houden terwijl de browser opnieuw probeert of hervat. Begin met live verbindingstellingen tijdens het drukste normale uploadvenster, vergelijk die met de limieten van de proxy en het besturingssysteem en stop met het verhogen van de proxyinstelling als bestandshandles, upstream-werknemers, geheugen of de applicatie als eerste problemen veroorzaken.

Meet de live uploadbehoefte voordat je een limiet kiest

Tel verbindingen tijdens de relevante werklast, niet wanneer de proxy inactief is. Start hetzelfde aantal uploads dat je huishouden of kleine team waarschijnlijk uitvoert, pauzeer verschillende overdrachten en hervat ze en neem ook mobiele clients mee die na de slaapstand opnieuw verbinding maken. Leg geaccepteerde clientsockets, tot stand gebrachte upstreamsockets en verbindingen die op een upstreamreactie wachten vast.

Een werknemerslimiet wordt verbruikt door alle open verbindingen die door die werknemer worden afgehandeld, niet alleen door voltooide HTTP-verzoeken. Daarom moeten verbindingen met proxied servers naast clientverbindingen in de meting worden opgenomen.

Gebruik het hoogste herhaalbare totaal als werkbasis. Als het totaal alleen tijdens verbindingsstormen stijgt en snel weer daalt, houd die piek dan apart van de aanhoudende vraag. Als het blijft stijgen terwijl de uploadsnelheid gelijk blijft, beschouw het oplopende aantal dan niet als legitieme capaciteit; controleer de upstreamapplicatie, time-outs en vastgelopen sessies voordat je iets verhoogt.

Vertaal de socketbehoefte naar capaciteit per werknemer

Bij een reverse proxy gebruikt één actieve upload doorgaans gelijktijdig een verbinding aan de clientzijde en een verbinding aan de upstreamzijde. HTTP-keepalive, statuscontroles, WebSocket-sessies en administratief verkeer verbruiken extra plaatsen. Beschouw tweemaal het aantal gelijktijdige uploads als een startmodel, niet als een definitief antwoord, omdat je gemeten sockettotaal betrouwbaarder is dan een vuistregel.

Een zichtbare limiet voor werknemersverbindingen kan nieuwe clients weigeren terwijl bestaande overdrachten doorgaan. Vergelijk de drukst bezette werknemer met de geconfigureerde limiet en controleer daarna de limiet voor geopende bestanden van het serviceproces; een hogere proxywaarde kan geen bestandshandles creëren die het proces niet mag openen.

Kies een doelwaarde boven de drukste herhaalbare werknemersbezetting, met voldoende ruimte voor de waargenomen nieuwe-pogingenpiek en normaal verkeer dat geen uploads betreft. Vermenigvuldig dit niet met elke mogelijke client en chunk als die verbindingen nooit gelijktijdig bestaan. Als de limiet van het besturingssysteem lager is, stem die laag dan eerst af of houd de proxylimiet eronder.

Test het oorspronkelijke hervatpad en interpreteer de fout

Herhaal de exacte trigger: start de volledige uploadset, onderbreek verschillende clients en hervat ze terwijl de overige overdrachten actief zijn. Houd het accepteren van nieuwe verbindingen, de timing van nieuwe pogingen, de uploadsnelheid, prox foutmeldingen, de responstijd van de upstream en het aantal geopende bestandshandles in de gaten. Een synthetisch verzoek dat nooit een body uploadt, test niet hetzelfde resourcepad.

Als de proxy meldt dat de werknemersverbindingen uitgeput zijn op hetzelfde moment dat nieuwe uploads mislukken, is de limiet een aantoonbare bottleneck. Als nieuwe verzoeken mislukken door fouten met de bodygrootte, time-outs, een onbeschikbare upstream of een applicatiewachtrij terwijl het aantal verbindingen onder de limiet blijft, lost een hogere werknemersinstelling het probleem niet op. Bij een berekening van de verbindingslimiet moet nog steeds rekening worden gehouden met de limiet voor geopende bestanden en de sockets aan beide kanten van de proxy.

Wijzig één laag tegelijk. Verhoog de werknemerslimiet pas nadat de log- en socketgegevens deze als oorzaak hebben aangewezen, laad de proxy opnieuw en voer hetzelfde onderbrekingspatroon opnieuw uit. Als de fout verschuift naar de upstreamservice of de limiet voor bestandshandles, stop dan; je hebt de volgende beperking bereikt, niet bewezen dat nog meer proxyverbindingen nuttig zijn.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Houd voldoende speelruimte en bepaal wanneer je stopt

Houd ruimte tussen de drukst bezette waargenomen werknemer en de geconfigureerde limiet, maar baseer die marge op werkelijke variatie. Een kleine server met stabiel huishoudelijk verkeer heeft minder speculatieve reserve nodig dan een openbare service met onvoorspelbare pieken. Leg de basiswaarde, doelwaarde, het aantal werknemers, de proceslimiet voor bestanden en het piekresultaat vast, zodat de volgende wijziging kan worden vergeleken in plaats van geraden.

Verbindingscapaciteit is slechts één laag van het uploadpad. Wanneer een dashboard werkt maar een specifiek synchronisatie- of uploadpad faalt, moeten het falende eindpunt en de methode nog steeds worden geïsoleerd voordat je de proxy als gezond beschouwt.

De wijziging is geslaagd wanneer twee volledige hervattests zijn voltooid, nieuwe verbindingen geaccepteerd blijven, de foutlogs schoon blijven en de drukst bezette werknemer een stabiele marge behoudt. Draai de verhoging terug als de geheugendruk of latentie verslechtert zonder dat het aantal fouten afneemt. Escaleer naar de applicatie- of opslaglaag wanneer het verbindinggebruik ruim onder de limiet blijft, maar uploads nog steeds in de wachtrij komen, time-outs veroorzaken of hun hervatstatus beschadigen.