Reg: exact field for response time
Hardik
hetardik.p at gmail.com
Thu Apr 4 05:54:30 UTC 2019
Thanks a lot Geoff.
I was ill and off work for few days so did not reply.
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.
Thank you
Hardik
On Wed, 20 Mar 2019 at 17:15, Geoff Simmons <geoff at uplex.de> wrote:
> On 3/20/19 07:14, Hardik wrote:
> >
> > what time should give to customer as a response time? Is it 2nd
> field(Total
> > round trip time) or 3rd field(only response time after processed fetched
> > content) ?
> > Timestamp Resp: 1501601912.806787* 0.048125* *0.000037*
> >
> > Reason of asking this question is, Only first time request will go to
> > origin. After that next all the request will be served from cache. Also
> > generally we do not have control over other network (customer's network)
> > when request goes to origin. As per this understanding, I should give 3rd
> > field to customer as per response time. Please correct me if I am wrong.
>
> The third field of Resp is not a useful measurement. It's the time taken
> for Varnish userland code to complete network send operations -- when
> the syscalls say they're done, there's essentially nothing left for
> Varnish to do with the response, so Varnish writes the final timestamp.
>
> But return from the syscalls for network send may mean nothing more
> than: the data has been placed on queues in the TCP stack. It doesn't
> tell you anything about the network send, or even if the data has been
> sent on the network yet at all.
>
> As a practical matter, if you tell your customer that "response time"
> was 37 microseconds, they probably won't believe you. (I wouldn't.)
>
> From what you've said, it sounds like you're looking for something like:
> the time taken to process the request, but not including the time for a
> fetch from the origin server. Is that about right?
>
> For that, you'd need to do more than read one field from one Timestamp
> entry -- you'll need to read at least two, maybe more, and then do some
> arithmetic.
>
> The best measure for the total time of request processing is the 2nd
> field in Timestamp:Resp, 48ms in your example above.
>
> The best measure for the fetch time is in the backend log, the 3rd field
> of Timestamp:Beresp, maybe added to the 3rd field of
> Timestamp:BerespBody. So you'd have to find the backend log
> corresponding to client log. -g request can help you with that.
>
> Then (if this is what you're after), subtract the fetch time from the
> total request processing time.
>
> There are some other ways to go about it, but it depends on what exactly
> you want to measure as "response time". And since I may have
> misunderstood what you're trying to measure, I'll stop there.
>
>
> HTH,
> Geoff
> --
> ** * * UPLEX - Nils Goroll Systemoptimierung
>
> Scheffelstraße 32
> 22301 Hamburg
>
> Tel +49 40 2880 5731
> Mob +49 176 636 90917
> Fax +49 40 42949753
>
> http://uplex.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20190404/0042fa00/attachment.html>
More information about the varnish-misc
mailing list