Hur många reverse proxy-arbetaranslutningar behöver återupptagbara uppladdningar?

Det finns inget säkert universellt antal arbetaranslutningar för återupptagbara uppladdningar. Dimensionera utifrån den högsta samtidiga socketbelastning du kan återskapa och lägg sedan till uppmätt marginal.

På en hemmaserver kan en enda synlig uppladdning hålla en klientanslutning, en uppströmsanslutning och väntetid mellan delar medan webbläsaren försöker igen eller återupptar uppladdningen. Börja med att räkna aktiva anslutningar under det mest belastade normala uppladdningsfönstret, jämför dem med proxy- och operativsystemets gränser och sluta höja proxyinställningen om filbeskrivare, uppströmsarbetare, minne eller applikationen ger upp först.

Mät den aktiva uppladdningsbelastningen innan du väljer en gräns

Räkna anslutningar under den arbetsbelastning som är relevant, inte när proxyn är inaktiv. Starta samma antal uppladdningar som hushållet eller det lilla teamet sannolikt kommer att köra, pausa och återuppta flera överföringar och inkludera eventuella mobila klienter som ansluter igen efter viloläge. Registrera accepterade klientsockets, etablerade uppströmsockets och anslutningar som väntar på ett svar från uppströmsservern.

En arbetargräns förbrukas av alla öppna anslutningar som hanteras av arbetaren, inte bara av slutförda HTTP-förfrågningar. Därför måste proxade serveranslutningar inkluderas i mätningen tillsammans med klientanslutningar.

Använd den högsta upprepningsbara totalen som arbetsbaslinje. Om totalen bara ökar under stormar av återanslutningar och snabbt sjunker igen bör du hålla isär den toppen från den varaktiga belastningen. Om den fortsätter att öka medan uppladdningshastigheten är oförändrad ska du inte betrakta det växande antalet som legitim kapacitet; undersök uppströmsapplikationen, tidsgränserna och fastnade sessioner innan du höjer något.

Översätt socketbelastningen till kapacitet per arbetare

För en omvänd proxy upptar en aktiv uppladdning vanligtvis en klientanslutning och en uppströmsanslutning samtidigt. HTTP-keepalive, hälsokontroller, WebSocket-sessioner och administrativ trafik förbrukar ytterligare platser. Betrakta dubbla antalet samtidiga uppladdningar som en startmodell, inte som ett färdigt svar, eftersom ditt uppmätta socketantal är mer tillförlitligt än en tumregel.

En synlig gräns för arbetaranslutningar kan avvisa nya klienter även medan etablerade överföringar fortsätter. Jämför den mest belastade arbetaren med dess konfigurerade gräns och kontrollera sedan tjänsteprocessens gräns för öppna filer; ett högre proxyvärde kan inte skapa fler filbeskrivare än processen tillåts öppna.

Välj ett mål som ligger över den högsta upprepningsbara belastningen hos arbetaren och som har tillräckligt utrymme för den observerade återförsöksbelastningen och vanlig trafik som inte gäller uppladdningar. Multiplicera inte med alla möjliga klienter och delar om anslutningarna aldrig existerar samtidigt. Om operativsystemets gräns är lägre ska du justera det lagret först eller hålla proxymålet under gränsen.

Testa den ursprungliga återupptagningsvägen och tolka felet

Upprepa exakt samma utlösare: starta hela uppsättningen av uppladdningar, avbryt flera klienter och återuppta dem medan de återstående överföringarna är aktiva. Övervaka om nya anslutningar accepteras, återförsökens tidsintervall, uppladdningshastigheten, proxyns feltext, uppströmsserverns svarstid och antalet öppna filbeskrivare. En syntetisk förfrågan som aldrig laddar upp en meddelandetext testar inte samma resursväg.

Om proxyn rapporterar att arbetaranslutningarna är slut samtidigt som nya uppladdningar misslyckas är gränsen en bekräftad flaskhals. Om nya förfrågningar misslyckas med fel om meddelandestorlek, tidsgräns, otillgänglig uppströmsserver eller applikationskö, medan anslutningsanvändningen ligger under taket, kommer en högre arbetarinställning inte att lösa problemet. En beräkning av anslutningsgränsen måste fortfarande ta hänsyn till gränsen för öppna filer och proxyns sockets på båda sidor.

Ändra ett lager i taget. Höj arbetargränsen först när logg- och socketbevis pekar ut den, ladda om proxyn och kör om samma avbrottsmönster. Om felet flyttar sig till uppströmsservern eller gränsen för filbeskrivare ska du stanna; du har nått nästa begränsning, inte bevisat att ännu fler proxyanslutningar är användbara.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Behåll tillräcklig marginal och definiera stoppvillkoret

Behåll en marginal mellan den högsta observerade belastningen hos arbetaren och den konfigurerade gränsen, men basera den på verkliga variationer. En liten server med stabil hushållstrafik behöver mindre spekulativ reserv än en offentlig tjänst som utsätts för oförutsägbara toppar. Dokumentera baslinjen, målet, antalet arbetare, processens filgräns och toppresultatet så att nästa ändring kan jämföras i stället för att gissas fram.

Anslutningskapacitet är bara ett lager i uppladdningsvägen. När en instrumentpanel fungerar men en specifik synkroniserings- eller uppladdningsväg misslyckas måste den felande slutpunkten och metoden fortfarande isoleras innan proxyn betraktas som frisk.

Ändringen är godkänd när två fullständiga återupptagningstester slutförs, nya anslutningar fortsätter att accepteras, felloggarna förblir tomma och den mest belastade arbetaren behåller en stabil marginal. Rulla tillbaka höjningen om minnestrycket eller svarstiden försämras utan att antalet fel minskar. Eskalera till applikations- eller lagringslagret när anslutningsanvändningen ligger klart under gränsen men uppladdningar fortfarande köas, får tidsgräns eller förstör sitt återupptagningstillstånd.