We are using packetbeat to measure memcache flows.Somehow the response time field in the packetbeat logs is always zero for any memcache request-response flow.
What could be the reason ?
Response time is given in milliseconds based on timestamps packets have been sniffed from network interface. That is, it depends on sniffer + clock accuracy. The packet timestamps are the timestamps of first packet seen for said messages. This does not include the time it takes to send the full response. There might still be some extra time used in client libs to read/parse the response + processing. Theoretical responses can be received and processed in parallel (responses of GET requests can be stream-processed one-by-one). If processing takes 'longer' some data might be buffered in OS network buffers (there is no way packetbeat can measure this).
Response time computation requires request and response message. In case response is missing (there are some request-only message types in the protocol), the response time is set to -1.
Have you tried to implement some traffic shaping delaying the memcached responses in time?
Thanks for the detail explanation.Few points
1)Wanted to confirm if response times for memcache are provided by packetbeat.
As per your answer and from docs,I get that the response time is a generic field which is provided for supported protocols including additional protocol specific fields too.
2)As I was not sure about 1) ,I did not test much on trying to introduce delay in memcache response.Will do that and update the question.
3)As the response times are less than millisecond ,these might be coming as zero.
-
yes, every application layer analyzer dealing with transactions computes a response time.
-
right. Given granularity of your clock. We rely on timestamps reported by sniffer/OS.
Thanks.