Statistics->Conversation->duration is a godsend, i don't deny that. But it has one flaw (intended by design) : it calculates conversation duration upto (and including) the final closing FINs/ACKs. When the daemon/client/server whatever takes his time cleaning up used connections, this has the unintended consequence of making it harder to find 'abnormal long' connexions, because they are flooded among the 'long' connections which are only due to final close packets. My first though was to try and filter out FIN packets, hoping the duration would be adjusted, but it doesn't work, as there are one/two ACK packets after the FIN which i couldn't remove in batch. So being stuck here with 25k connections to analyze, i'm coming here for help, and to throw the idea for a little tweak in duration calculations. Example #1 : 'abnormaly long' connection** which i want to quickly find Client opens connection, waits 3 seconds to sent his GET Then sends it, fetchs the reply, and closes the connection immediately This one lasts ~3 sec, due to a the client taking his time before sending the request) Example #2 : normal 'long' connection Client opens connection, sends get ASAP, get reply ASAP, no problem there. Then either the client or the server wait a few (or a bunch) of seconds before closing the connection (let's say 3 sec for the sake of the example) So the FIN/ACK + ACKs begin 3s after the last payload packet. And the total duration of the connection is ~3 seconds too, due only to the idle time before closing. BUT the interesting parts of that connection might only have accounted for 0.1 sec ! My point of view : let's say i'm looking fo the 'real' slow connection, and let's say that i have 25k connections to filter, i'm back to finding a needle in a haystack. Being able to modify the way the duration is displayed (or calculated, temporarily or not) would make able to spot the "real slow" connections without sifting through the delayed close clutter. Basically, a checkbox in the conversation pane to modify the duration calculation to calculate it up to the last packet before the first FIN, or something alike, would be perfect. Or a similar way to achieve this result, of course ! Thanks in advance for your help, hints, tips or thoughs. asked 25 Nov '14, 08:19  nipil |
One Answer:
I think this kind of duration calculation is probably not easy to implement, because it needs a little fuzzy logic to determine if a delay is normal or abnormal. This is also more of a feature request that would have to be put into the bug tracker. Since you describe your problem as trying to track down client delays before issuing GET requests you may be able to leverage something like the transum plugin to do what you need. answered 25 Nov '14, 08:31  Jasper ♦♦ |
