If you're not keeping the connection alive (I assume a loop calling wget is unable to do so) then much of the variance will be down to creating new TCP connections. A further problem is that of ephemeral port exhaustion, you might find the spikes in latency are cyclical, which is when wget is blocked waiting for a port (the others still lingering in TIME_WAIT, for example).
I suggest using apachebench or nodeload (https://github.com/benschmaus/nodeload) with appropriate settings to reuse connections. "I expect stale=update_after to behave the same as stale=ok but also trigger view index update." Yes, it's true. B. On 9 June 2011 10:02, Torstein Krause Johansen <[email protected]> wrote: > Heya, > > On 09/06/11 16:07, Marcello Nuccio wrote: > >> 2011/6/9 Torstein Krause Johansen<[email protected]>: >>> >>> On 08/06/11 19:21, Sean Copenhaver wrote: >>>> >>>> For stale=update_after/ok, does that mean the next query could block >>>> until >>>> the view updated? Even if the it was also a stale=update_after/ok query? >>> >>> I've tested this with two eternal wget loops, one running with stale=ok >>> and >>> one the default non stale data setting. >> >> I think a more interesting test is with two loops, one running with >> stale=ok and one running with stale=update_after. > > Could be, but I'm still on 0.11.0-2.3 :-) > >> I expect stale=update_after to behave the same as stale=ok but also >> trigger view index update. >> Is this true? > > Don't know, but that's what I'd expect too. > > Cheers, > > -Torstein >
