Treg framgang kan halde ei proxy-nedlasting innanfor lesetidsavbrotet
Forstå kvifor sporadiske svarbitar kan halde ei nedlasting via proxy innanfor ei inaktivitetsgrense for lesing medan den totale varigheita blir uakseptabel.
Eit svar som av og til leverer nokre få bitar, kan halde seg innanfor kvar inaktivitetsgrense for lesing, men ta altfor lang tid totalt. Eit lesetidsavbrot treng ikkje måle heile varigheita av overføringa.
Vel politikken etter arbeidslasta. Eit avgrensa arkiv treng eit fullføringsbudsjett; ein hendingsstraum kan lovleg vare i timar og vere stille innimellom.
Mål nyttig framgang
For ei filnedlasting, hald ein samla frist og vurder dei støtta låg-hastigheits- eller framgangskontrollane til klienten. Definer intervallet og mengda nyttige data. Ein hjarteslagsbyte kan vise aktivitet utan å gjere reell framgang mot fullføring av fila.
Hald tunneloppsettet skilt frå kroppsoverføringa. Å vente på at CONNECT blir fullført og å ta imot ein treg destinasjonskropp er ulike fasar med ulike prov.
Bruk opp eller lukk svaret på kvar utgangsveg. Å la ein treg straum stå open kan få den neste førespurnaden til å vente på poolkapasitet, noko som skaper endå eit tidsavbrot av ein annan grunn.
Viss den observerte varigheita overstig den tiltenkte politikken, undersøk den nøyaktige klientversjonen og leseløkka. Ein korrekt fungerande inaktivitetstimer, tilpassa løkkjeåtferd og ein implementeringsfeil krev kvar si retting.