<div dir="ltr">Thanks a lot Geoff. <div><br></div><div>I was ill and off work for few days so did not reply.</div><div>I am reading second field now. In future to give only response time from varnish, will try to sum other time stamps as you said.</div><div><br></div><div>Thank you</div><div>Hardik </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Mar 2019 at 17:15, Geoff Simmons <<a href="mailto:geoff@uplex.de">geoff@uplex.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/20/19 07:14, Hardik wrote:<br>
> <br>
> what time should give to customer as a response time? Is it 2nd field(Total<br>
> round trip time) or 3rd field(only response time after processed fetched<br>
> content) ?<br>
>        Timestamp Resp: 1501601912.806787* 0.048125* *0.000037*<br>
> <br>
> Reason of asking this question is, Only first time request will go to<br>
> origin. After that next all the request will be served from cache. Also<br>
> generally we do not have control over other network (customer's network)<br>
> when request goes to origin. As per this understanding, I should give 3rd<br>
> field to customer as per response time. Please correct me if I am wrong.<br>
<br>
The third field of Resp is not a useful measurement. It's the time taken<br>
for Varnish userland code to complete network send operations -- when<br>
the syscalls say they're done, there's essentially nothing left for<br>
Varnish to do with the response, so Varnish writes the final timestamp.<br>
<br>
But return from the syscalls for network send may mean nothing more<br>
than: the data has been placed on queues in the TCP stack. It doesn't<br>
tell you anything about the network send, or even if the data has been<br>
sent on the network yet at all.<br>
<br>
As a practical matter, if you tell your customer that "response time"<br>
was 37 microseconds, they probably won't believe you. (I wouldn't.)<br>
<br>
>From what you've said, it sounds like you're looking for something like:<br>
the time taken to process the request, but not including the time for a<br>
fetch from the origin server. Is that about right?<br>
<br>
For that, you'd need to do more than read one field from one Timestamp<br>
entry -- you'll need to read at least two, maybe more, and then do some<br>
arithmetic.<br>
<br>
The best measure for the total time of request processing is the 2nd<br>
field in Timestamp:Resp, 48ms in your example above.<br>
<br>
The best measure for the fetch time is in the backend log, the 3rd field<br>
of Timestamp:Beresp, maybe added to the 3rd field of<br>
Timestamp:BerespBody. So you'd have to find the backend log<br>
corresponding to client log. -g request can help you with that.<br>
<br>
Then (if this is what you're after), subtract the fetch time from the<br>
total request processing time.<br>
<br>
There are some other ways to go about it, but it depends on what exactly<br>
you want to measure as "response time". And since I may have<br>
misunderstood what you're trying to measure, I'll stop there.<br>
<br>
<br>
HTH,<br>
Geoff<br>
-- <br>
** * * UPLEX - Nils Goroll Systemoptimierung<br>
<br>
Scheffelstraße 32<br>
22301 Hamburg<br>
<br>
Tel +49 40 2880 5731<br>
Mob +49 176 636 90917<br>
Fax +49 40 42949753<br>
<br>
<a href="http://uplex.de" rel="noreferrer" target="_blank">http://uplex.de</a><br>
<br>
</blockquote></div>