From scan-admin at coverity.com  Sun Aug  2 11:55:08 2020
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Sun, 02 Aug 2020 11:55:08 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <5f26a99c88a73_1ada6a2aafc0020f548858f@prd-scan-dashboard-0.mail>


    Your request for analysis of varnish has been completed successfully.
    The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DxUJP_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je48IoJQdExuWpS71xA8nJzk-2Fn99-2BE1jC-2F-2FibrWNR4q36Lpw3FMC32h6P-2F8h6k-2BlBmx14GwJ5CtWhx3TJEtZsdkmUYLC7z-2Bq7vRlqPhiTEdNEybAamk6uA5VKeIXV4OsKuUiEM1FsJ3rGmgH7afPOkRahm9TLYoSLXfTBhBZLyWRA5Rj10mZK2E9KGpE6a0pOS3k-3D

    Build ID: 330168

    Analysis Summary:
       New defects found: 0
       Defects eliminated: 0


From martin.grigorov at gmail.com  Mon Aug  3 15:14:33 2020
From: martin.grigorov at gmail.com (Martin Grigorov)
Date: Mon, 3 Aug 2020 18:14:33 +0300
Subject: Compared performance of Varnish Cache on x86_64 and aarch64
In-Reply-To: <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
References: <CAMomwMorvbuhSms0m9nEQ=Y31McJNyR9EefC07K=J8w81iD4KA@mail.gmail.com>
 <70851.1595944863@critter.freebsd.dk>
 <CAMomwMr65an54q9mnUSQ8bcR+XAEgxWStVwb-9aH+7i_oCC53w@mail.gmail.com>
 <81825.1596024704@critter.freebsd.dk>
 <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
Message-ID: <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>

Hi,

Thank you all for the feedback!
After some debugging it appeared that it is a bug in wrk - most of the
requests' latencies were 0 in the raw reports.

I've looked for a better maintained HTTP load testing tool and I liked
https://github.com/tsenart/vegeta. it provides (correctly looking)
statistics, can measure latencies while using constant rate, and last but
not least can produce plot charts!
I will update my article and let you know once I'm done!

Regards,
Martin

On Fri, Jul 31, 2020 at 4:43 PM P?l Hermunn Johansen <
hermunn at varnish-software.com> wrote:

> I am sorry for being so late to the game, but here it goes:
>
> ons. 29. jul. 2020 kl. 14:12 skrev Poul-Henning Kamp <phk at phk.freebsd.dk>:
> > Your measurement says that there is 2/3 chance that the latency
> > is between:
> >
> >         655.40?s - 798.70?s     = -143.30?s
> >
> > and
> >         655.40?s + 798.70?s     = 1454.10?s
>
> No, it does not. There is no claim anywhere that the numbers are
> following a normal distribution or an approximation of it. Of course,
> the calculations you do demonstrate that the data is far from normally
> distributed (as expected).
>
> > You cannot conclude _anything_ from those numbers.
>
> There are two numbers, the average and the standard deviation, and
> they are calculated from the data, but the truth is hidden deeper in
> the data. By looking at the particular numbers, I agree completely
> that it is wrong to conclude that one is better than the other. I am
> not saying that the statements in the article are false, just that you
> do not have data to draw the conclusions.
>
> Furthermore I have to say that Geoff got things right (see below). As
> a mathematician, I have to say that statistics is hard, and trusting
> the output of wrk to draw conclusions is outright the wrong thing to
> do.
>
> In this case we have a luxury which you typically do not have: Data is
> essentially free. You can run many tests and you can run short or long
> tests with different parameters. A 30 second test is simply not enough
> for anything.
>
> As Geoff indicated, for each transaction you can extract many relevant
> values from varnishlog, with the status, hit/miss, time to first byte
> and time to last byte being the most obvious ones. They can be
> extracted and saved to a csv file by using varnishncsa with a custom
> format string, and you can use R (used it myself as a tool in my
> previous job - not a fan) to do statistical analysis on the data. The
> Student T suggestion from Geoff is a good idea, but just looking at
> one set of numbers without considering other factors is mathematically
> problematic.
>
> Anyway, some obvious questions then arise. For example:
> - How do the numbers between wrk and varnishlog/varnishncsa compare?
> Did wrk report a total number of transactions than varnish? If there
> is a discrepancy, then the errors might be because of some resource
> restraint (number of sockets or dropped syn packages?).
> - How does the average and maximum compare between varnish and wrk?
> - What is the CPU usage of the kernel, the benchmarking tool and the
> varnish processes in the tests?
> - What is the difference between the time to first byte and the time
> to last byte in Varnish for different object sizes?
>
> When Varnish writes to a socket, it hands bytes over to the kernel,
> and when the write call returns, we do not know how far the bytes have
> come, and how long it will take before they get to the final
> destination. The bytes may be in a kernel buffer, they might be on the
> network card, and they might be already received at the client's
> kernel, and they might have made it all into wrk (which may or may not
> have timestamped the response). Typically, depending on many things,
> Varnish will report faster times than what wrk, but since returning
> from the write call means that the calling thread must be rescheduled,
> it is even possible that wrk will see that some requests are faster
> than what Varnish reports. Running wrk2 with different speeds in a
> series of tests seems natural to me, so that you can observe when (and
> how) the system starts running into bottlenecks. Note that the
> bottleneck can just as well be in wrk2 itself or on the combined CPU
> usage of kernel + Varnish + wrk2.
>
> To complicate things even further: On your ARM vs. x64 tests, my guess
> is that both kernel parameters and parameters for the network are
> different, and the distributions probably have good reason to choose
> different values. It is very likely that these differences affect the
> performance of the systems in many ways, and that different tests will
> have different "optimal" tunings of kernel and network parameters.
>
> Sorry for rambling, but getting the statistics wrong is so easy. The
> question is very interesting, but if you want to draw conclusions, you
> should do the analysis, and (ideally) give access to the raw data in
> case anyone wants to have a look.
>
> Best,
> P?l
>
> fre. 31. jul. 2020 kl. 08:45 skrev Geoff Simmons <geoff at uplex.de>:
> >
> > On 7/28/20 13:52, Martin Grigorov wrote:
> > >
> > > I've just posted an article [1] about comparing the performance of
> Varnish
> > > Cache on two similar
> > > machines - the main difference is the CPU architecture - x86_64 vs
> aarch64.
> > > It uses a specific use case - the backend service just returns a static
> > > content. The idea is
> > > to compare Varnish on the different architectures but also to compare
> > > Varnish against the backend HTTP server.
> > > What is interesting is that Varnish gives the same throughput as the
> > > backend server on x86_64 but on aarch64 it is around 30% slower than
> the
> > > backend.
> >
> > Does your test have an account of whether there were any errors in
> > backend fetches? Don't know if that explains anything, but with a
> > connect timeout of 10s and first byte timeout of 5m, any error would
> > have a considerable effect on the results of a 30 second test.
> >
> > The test tool output doesn't say anything I can see about error rates --
> > whether all responses had status 200, and if not, how many had which
> > other status. Ideally it should be all 200, otherwise the results may
> > not be valid.
> >
> > I agree with phk that a statistical analysis is needed for a robust
> > statement about differences between the two platforms. For that, you'd
> > need more than the summary stats shown in your blog post -- you need to
> > collect all of the response times. What I usually do is query Varnish
> > client request logs for Timestamp:Resp and save the number in the last
> > column.
> >
> > t.test() in R runs Student's t-test (me R fanboi).
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200803/a16ebe40/attachment.html>

From martin.grigorov at gmail.com  Tue Aug  4 11:31:40 2020
From: martin.grigorov at gmail.com (Martin Grigorov)
Date: Tue, 4 Aug 2020 14:31:40 +0300
Subject: Compared performance of Varnish Cache on x86_64 and aarch64
In-Reply-To: <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>
References: <CAMomwMorvbuhSms0m9nEQ=Y31McJNyR9EefC07K=J8w81iD4KA@mail.gmail.com>
 <70851.1595944863@critter.freebsd.dk>
 <CAMomwMr65an54q9mnUSQ8bcR+XAEgxWStVwb-9aH+7i_oCC53w@mail.gmail.com>
 <81825.1596024704@critter.freebsd.dk>
 <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
 <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>
Message-ID: <CAMomwMrpCXdcytLYFHKHj_9hGfTgPXe1uWyPm9qEdXpvS+5tzw@mail.gmail.com>

Hi,

I've updated the data in the article -
https://medium.com/@martin.grigorov/compare-varnish-cache-performance-on-x86-64-and-aarch64-cpu-architectures-cef5ad5fee5f
Now x86_64 and aarch64 are almost the same!
Varnish gives around 20% less throughput than the Golang HTTP server but I
guess this is because the Golang server is much simpler than Varnish.

3 min run produces around 3GB of Vegeta reports (130MB gzipped). If anyone
wants me to extract some extra data just let me know!

Regards,
Martin

On Mon, Aug 3, 2020 at 6:14 PM Martin Grigorov <martin.grigorov at gmail.com>
wrote:

> Hi,
>
> Thank you all for the feedback!
> After some debugging it appeared that it is a bug in wrk - most of the
> requests' latencies were 0 in the raw reports.
>
> I've looked for a better maintained HTTP load testing tool and I liked
> https://github.com/tsenart/vegeta. it provides (correctly looking)
> statistics, can measure latencies while using constant rate, and last but
> not least can produce plot charts!
> I will update my article and let you know once I'm done!
>
> Regards,
> Martin
>
> On Fri, Jul 31, 2020 at 4:43 PM P?l Hermunn Johansen <
> hermunn at varnish-software.com> wrote:
>
>> I am sorry for being so late to the game, but here it goes:
>>
>> ons. 29. jul. 2020 kl. 14:12 skrev Poul-Henning Kamp <phk at phk.freebsd.dk
>> >:
>> > Your measurement says that there is 2/3 chance that the latency
>> > is between:
>> >
>> >         655.40?s - 798.70?s     = -143.30?s
>> >
>> > and
>> >         655.40?s + 798.70?s     = 1454.10?s
>>
>> No, it does not. There is no claim anywhere that the numbers are
>> following a normal distribution or an approximation of it. Of course,
>> the calculations you do demonstrate that the data is far from normally
>> distributed (as expected).
>>
>> > You cannot conclude _anything_ from those numbers.
>>
>> There are two numbers, the average and the standard deviation, and
>> they are calculated from the data, but the truth is hidden deeper in
>> the data. By looking at the particular numbers, I agree completely
>> that it is wrong to conclude that one is better than the other. I am
>> not saying that the statements in the article are false, just that you
>> do not have data to draw the conclusions.
>>
>> Furthermore I have to say that Geoff got things right (see below). As
>> a mathematician, I have to say that statistics is hard, and trusting
>> the output of wrk to draw conclusions is outright the wrong thing to
>> do.
>>
>> In this case we have a luxury which you typically do not have: Data is
>> essentially free. You can run many tests and you can run short or long
>> tests with different parameters. A 30 second test is simply not enough
>> for anything.
>>
>> As Geoff indicated, for each transaction you can extract many relevant
>> values from varnishlog, with the status, hit/miss, time to first byte
>> and time to last byte being the most obvious ones. They can be
>> extracted and saved to a csv file by using varnishncsa with a custom
>> format string, and you can use R (used it myself as a tool in my
>> previous job - not a fan) to do statistical analysis on the data. The
>> Student T suggestion from Geoff is a good idea, but just looking at
>> one set of numbers without considering other factors is mathematically
>> problematic.
>>
>> Anyway, some obvious questions then arise. For example:
>> - How do the numbers between wrk and varnishlog/varnishncsa compare?
>> Did wrk report a total number of transactions than varnish? If there
>> is a discrepancy, then the errors might be because of some resource
>> restraint (number of sockets or dropped syn packages?).
>> - How does the average and maximum compare between varnish and wrk?
>> - What is the CPU usage of the kernel, the benchmarking tool and the
>> varnish processes in the tests?
>> - What is the difference between the time to first byte and the time
>> to last byte in Varnish for different object sizes?
>>
>> When Varnish writes to a socket, it hands bytes over to the kernel,
>> and when the write call returns, we do not know how far the bytes have
>> come, and how long it will take before they get to the final
>> destination. The bytes may be in a kernel buffer, they might be on the
>> network card, and they might be already received at the client's
>> kernel, and they might have made it all into wrk (which may or may not
>> have timestamped the response). Typically, depending on many things,
>> Varnish will report faster times than what wrk, but since returning
>> from the write call means that the calling thread must be rescheduled,
>> it is even possible that wrk will see that some requests are faster
>> than what Varnish reports. Running wrk2 with different speeds in a
>> series of tests seems natural to me, so that you can observe when (and
>> how) the system starts running into bottlenecks. Note that the
>> bottleneck can just as well be in wrk2 itself or on the combined CPU
>> usage of kernel + Varnish + wrk2.
>>
>> To complicate things even further: On your ARM vs. x64 tests, my guess
>> is that both kernel parameters and parameters for the network are
>> different, and the distributions probably have good reason to choose
>> different values. It is very likely that these differences affect the
>> performance of the systems in many ways, and that different tests will
>> have different "optimal" tunings of kernel and network parameters.
>>
>> Sorry for rambling, but getting the statistics wrong is so easy. The
>> question is very interesting, but if you want to draw conclusions, you
>> should do the analysis, and (ideally) give access to the raw data in
>> case anyone wants to have a look.
>>
>> Best,
>> P?l
>>
>> fre. 31. jul. 2020 kl. 08:45 skrev Geoff Simmons <geoff at uplex.de>:
>> >
>> > On 7/28/20 13:52, Martin Grigorov wrote:
>> > >
>> > > I've just posted an article [1] about comparing the performance of
>> Varnish
>> > > Cache on two similar
>> > > machines - the main difference is the CPU architecture - x86_64 vs
>> aarch64.
>> > > It uses a specific use case - the backend service just returns a
>> static
>> > > content. The idea is
>> > > to compare Varnish on the different architectures but also to compare
>> > > Varnish against the backend HTTP server.
>> > > What is interesting is that Varnish gives the same throughput as the
>> > > backend server on x86_64 but on aarch64 it is around 30% slower than
>> the
>> > > backend.
>> >
>> > Does your test have an account of whether there were any errors in
>> > backend fetches? Don't know if that explains anything, but with a
>> > connect timeout of 10s and first byte timeout of 5m, any error would
>> > have a considerable effect on the results of a 30 second test.
>> >
>> > The test tool output doesn't say anything I can see about error rates --
>> > whether all responses had status 200, and if not, how many had which
>> > other status. Ideally it should be all 200, otherwise the results may
>> > not be valid.
>> >
>> > I agree with phk that a statistical analysis is needed for a robust
>> > statement about differences between the two platforms. For that, you'd
>> > need more than the summary stats shown in your blog post -- you need to
>> > collect all of the response times. What I usually do is query Varnish
>> > client request logs for Timestamp:Resp and save the number in the last
>> > column.
>> >
>> > t.test() in R runs Student's t-test (me R fanboi).
>> >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200804/110a59ef/attachment-0001.html>

From guillaume at varnish-software.com  Tue Aug  4 14:46:51 2020
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 4 Aug 2020 07:46:51 -0700
Subject: Compared performance of Varnish Cache on x86_64 and aarch64
In-Reply-To: <CAMomwMrpCXdcytLYFHKHj_9hGfTgPXe1uWyPm9qEdXpvS+5tzw@mail.gmail.com>
References: <CAMomwMorvbuhSms0m9nEQ=Y31McJNyR9EefC07K=J8w81iD4KA@mail.gmail.com>
 <70851.1595944863@critter.freebsd.dk>
 <CAMomwMr65an54q9mnUSQ8bcR+XAEgxWStVwb-9aH+7i_oCC53w@mail.gmail.com>
 <81825.1596024704@critter.freebsd.dk>
 <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
 <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>
 <CAMomwMrpCXdcytLYFHKHj_9hGfTgPXe1uWyPm9qEdXpvS+5tzw@mail.gmail.com>
Message-ID: <CAJ6ZYQxTQchdpJFu-8WqwBCgo7OCzbE=YCbs77FFcBD+b6kcLg@mail.gmail.com>

Hi,

> Varnish gives around 20% less throughput than the Golang HTTP server but
I guess this is because the Golang server is much simpler than Varnish.

Since the backend and vegeta are written in go, it's pretty safe they are
going to use H/2 by default, and that's not the case for your varnish
instance, so that possibly explain some of the differences you are seeing.

Cheers,

-- 
Guillaume Quintard


On Tue, Aug 4, 2020 at 4:33 AM Martin Grigorov <martin.grigorov at gmail.com>
wrote:

> Hi,
>
> I've updated the data in the article -
> https://medium.com/@martin.grigorov/compare-varnish-cache-performance-on-x86-64-and-aarch64-cpu-architectures-cef5ad5fee5f
> Now x86_64 and aarch64 are almost the same!
> Varnish gives around 20% less throughput than the Golang HTTP server but I
> guess this is because the Golang server is much simpler than Varnish.
>
> 3 min run produces around 3GB of Vegeta reports (130MB gzipped). If anyone
> wants me to extract some extra data just let me know!
>
> Regards,
> Martin
>
> On Mon, Aug 3, 2020 at 6:14 PM Martin Grigorov <martin.grigorov at gmail.com>
> wrote:
>
>> Hi,
>>
>> Thank you all for the feedback!
>> After some debugging it appeared that it is a bug in wrk - most of the
>> requests' latencies were 0 in the raw reports.
>>
>> I've looked for a better maintained HTTP load testing tool and I liked
>> https://github.com/tsenart/vegeta. it provides (correctly looking)
>> statistics, can measure latencies while using constant rate, and last but
>> not least can produce plot charts!
>> I will update my article and let you know once I'm done!
>>
>> Regards,
>> Martin
>>
>> On Fri, Jul 31, 2020 at 4:43 PM P?l Hermunn Johansen <
>> hermunn at varnish-software.com> wrote:
>>
>>> I am sorry for being so late to the game, but here it goes:
>>>
>>> ons. 29. jul. 2020 kl. 14:12 skrev Poul-Henning Kamp <phk at phk.freebsd.dk
>>> >:
>>> > Your measurement says that there is 2/3 chance that the latency
>>> > is between:
>>> >
>>> >         655.40?s - 798.70?s     = -143.30?s
>>> >
>>> > and
>>> >         655.40?s + 798.70?s     = 1454.10?s
>>>
>>> No, it does not. There is no claim anywhere that the numbers are
>>> following a normal distribution or an approximation of it. Of course,
>>> the calculations you do demonstrate that the data is far from normally
>>> distributed (as expected).
>>>
>>> > You cannot conclude _anything_ from those numbers.
>>>
>>> There are two numbers, the average and the standard deviation, and
>>> they are calculated from the data, but the truth is hidden deeper in
>>> the data. By looking at the particular numbers, I agree completely
>>> that it is wrong to conclude that one is better than the other. I am
>>> not saying that the statements in the article are false, just that you
>>> do not have data to draw the conclusions.
>>>
>>> Furthermore I have to say that Geoff got things right (see below). As
>>> a mathematician, I have to say that statistics is hard, and trusting
>>> the output of wrk to draw conclusions is outright the wrong thing to
>>> do.
>>>
>>> In this case we have a luxury which you typically do not have: Data is
>>> essentially free. You can run many tests and you can run short or long
>>> tests with different parameters. A 30 second test is simply not enough
>>> for anything.
>>>
>>> As Geoff indicated, for each transaction you can extract many relevant
>>> values from varnishlog, with the status, hit/miss, time to first byte
>>> and time to last byte being the most obvious ones. They can be
>>> extracted and saved to a csv file by using varnishncsa with a custom
>>> format string, and you can use R (used it myself as a tool in my
>>> previous job - not a fan) to do statistical analysis on the data. The
>>> Student T suggestion from Geoff is a good idea, but just looking at
>>> one set of numbers without considering other factors is mathematically
>>> problematic.
>>>
>>> Anyway, some obvious questions then arise. For example:
>>> - How do the numbers between wrk and varnishlog/varnishncsa compare?
>>> Did wrk report a total number of transactions than varnish? If there
>>> is a discrepancy, then the errors might be because of some resource
>>> restraint (number of sockets or dropped syn packages?).
>>> - How does the average and maximum compare between varnish and wrk?
>>> - What is the CPU usage of the kernel, the benchmarking tool and the
>>> varnish processes in the tests?
>>> - What is the difference between the time to first byte and the time
>>> to last byte in Varnish for different object sizes?
>>>
>>> When Varnish writes to a socket, it hands bytes over to the kernel,
>>> and when the write call returns, we do not know how far the bytes have
>>> come, and how long it will take before they get to the final
>>> destination. The bytes may be in a kernel buffer, they might be on the
>>> network card, and they might be already received at the client's
>>> kernel, and they might have made it all into wrk (which may or may not
>>> have timestamped the response). Typically, depending on many things,
>>> Varnish will report faster times than what wrk, but since returning
>>> from the write call means that the calling thread must be rescheduled,
>>> it is even possible that wrk will see that some requests are faster
>>> than what Varnish reports. Running wrk2 with different speeds in a
>>> series of tests seems natural to me, so that you can observe when (and
>>> how) the system starts running into bottlenecks. Note that the
>>> bottleneck can just as well be in wrk2 itself or on the combined CPU
>>> usage of kernel + Varnish + wrk2.
>>>
>>> To complicate things even further: On your ARM vs. x64 tests, my guess
>>> is that both kernel parameters and parameters for the network are
>>> different, and the distributions probably have good reason to choose
>>> different values. It is very likely that these differences affect the
>>> performance of the systems in many ways, and that different tests will
>>> have different "optimal" tunings of kernel and network parameters.
>>>
>>> Sorry for rambling, but getting the statistics wrong is so easy. The
>>> question is very interesting, but if you want to draw conclusions, you
>>> should do the analysis, and (ideally) give access to the raw data in
>>> case anyone wants to have a look.
>>>
>>> Best,
>>> P?l
>>>
>>> fre. 31. jul. 2020 kl. 08:45 skrev Geoff Simmons <geoff at uplex.de>:
>>> >
>>> > On 7/28/20 13:52, Martin Grigorov wrote:
>>> > >
>>> > > I've just posted an article [1] about comparing the performance of
>>> Varnish
>>> > > Cache on two similar
>>> > > machines - the main difference is the CPU architecture - x86_64 vs
>>> aarch64.
>>> > > It uses a specific use case - the backend service just returns a
>>> static
>>> > > content. The idea is
>>> > > to compare Varnish on the different architectures but also to compare
>>> > > Varnish against the backend HTTP server.
>>> > > What is interesting is that Varnish gives the same throughput as the
>>> > > backend server on x86_64 but on aarch64 it is around 30% slower than
>>> the
>>> > > backend.
>>> >
>>> > Does your test have an account of whether there were any errors in
>>> > backend fetches? Don't know if that explains anything, but with a
>>> > connect timeout of 10s and first byte timeout of 5m, any error would
>>> > have a considerable effect on the results of a 30 second test.
>>> >
>>> > The test tool output doesn't say anything I can see about error rates
>>> --
>>> > whether all responses had status 200, and if not, how many had which
>>> > other status. Ideally it should be all 200, otherwise the results may
>>> > not be valid.
>>> >
>>> > I agree with phk that a statistical analysis is needed for a robust
>>> > statement about differences between the two platforms. For that, you'd
>>> > need more than the summary stats shown in your blog post -- you need to
>>> > collect all of the response times. What I usually do is query Varnish
>>> > client request logs for Timestamp:Resp and save the number in the last
>>> > column.
>>> >
>>> > t.test() in R runs Student's t-test (me R fanboi).
>>> >
>>> >
>>>
>> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200804/e8d7c052/attachment.html>

From martin.grigorov at gmail.com  Wed Aug  5 09:17:11 2020
From: martin.grigorov at gmail.com (Martin Grigorov)
Date: Wed, 5 Aug 2020 12:17:11 +0300
Subject: Compared performance of Varnish Cache on x86_64 and aarch64
In-Reply-To: <CAJ6ZYQxTQchdpJFu-8WqwBCgo7OCzbE=YCbs77FFcBD+b6kcLg@mail.gmail.com>
References: <CAMomwMorvbuhSms0m9nEQ=Y31McJNyR9EefC07K=J8w81iD4KA@mail.gmail.com>
 <70851.1595944863@critter.freebsd.dk>
 <CAMomwMr65an54q9mnUSQ8bcR+XAEgxWStVwb-9aH+7i_oCC53w@mail.gmail.com>
 <81825.1596024704@critter.freebsd.dk>
 <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
 <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>
 <CAMomwMrpCXdcytLYFHKHj_9hGfTgPXe1uWyPm9qEdXpvS+5tzw@mail.gmail.com>
 <CAJ6ZYQxTQchdpJFu-8WqwBCgo7OCzbE=YCbs77FFcBD+b6kcLg@mail.gmail.com>
Message-ID: <CAMomwMpc+4h8rf5cMEMv6yk3c7A5dYv_V5Jzh4tVb=UyrHgXJg@mail.gmail.com>

Hi Guillaume,

On Tue, Aug 4, 2020 at 5:47 PM Guillaume Quintard <
guillaume at varnish-software.com> wrote:

> Hi,
>
> > Varnish gives around 20% less throughput than the Golang HTTP server but
> I guess this is because the Golang server is much simpler than Varnish.
>
> Since the backend and vegeta are written in go, it's pretty safe they are
> going to use H/2 by default, and that's not the case for your varnish
> instance, so that possibly explain some of the differences you are seeing.
>

To use H/2 one has to use -http2 parameter (
https://github.com/tsenart/vegeta#-http2)
In addition I'd need to start the HTTP server with
svr.ListenAndServeTLS(cert, key)
I've added "log.Printf("Protocol: %s", r.Proto)" to the handle function and
it prints "HTTP/1.1" no matter whether I use -http2 parameter for Vegeta or
not


>
> Cheers,
>
> --
> Guillaume Quintard
>
>
> On Tue, Aug 4, 2020 at 4:33 AM Martin Grigorov <martin.grigorov at gmail.com>
> wrote:
>
>> Hi,
>>
>> I've updated the data in the article -
>> https://medium.com/@martin.grigorov/compare-varnish-cache-performance-on-x86-64-and-aarch64-cpu-architectures-cef5ad5fee5f
>> Now x86_64 and aarch64 are almost the same!
>> Varnish gives around 20% less throughput than the Golang HTTP server but
>> I guess this is because the Golang server is much simpler than Varnish.
>>
>> 3 min run produces around 3GB of Vegeta reports (130MB gzipped). If
>> anyone wants me to extract some extra data just let me know!
>>
>> Regards,
>> Martin
>>
>> On Mon, Aug 3, 2020 at 6:14 PM Martin Grigorov <martin.grigorov at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Thank you all for the feedback!
>>> After some debugging it appeared that it is a bug in wrk - most of the
>>> requests' latencies were 0 in the raw reports.
>>>
>>> I've looked for a better maintained HTTP load testing tool and I liked
>>> https://github.com/tsenart/vegeta. it provides (correctly looking)
>>> statistics, can measure latencies while using constant rate, and last but
>>> not least can produce plot charts!
>>> I will update my article and let you know once I'm done!
>>>
>>> Regards,
>>> Martin
>>>
>>> On Fri, Jul 31, 2020 at 4:43 PM P?l Hermunn Johansen <
>>> hermunn at varnish-software.com> wrote:
>>>
>>>> I am sorry for being so late to the game, but here it goes:
>>>>
>>>> ons. 29. jul. 2020 kl. 14:12 skrev Poul-Henning Kamp <
>>>> phk at phk.freebsd.dk>:
>>>> > Your measurement says that there is 2/3 chance that the latency
>>>> > is between:
>>>> >
>>>> >         655.40?s - 798.70?s     = -143.30?s
>>>> >
>>>> > and
>>>> >         655.40?s + 798.70?s     = 1454.10?s
>>>>
>>>> No, it does not. There is no claim anywhere that the numbers are
>>>> following a normal distribution or an approximation of it. Of course,
>>>> the calculations you do demonstrate that the data is far from normally
>>>> distributed (as expected).
>>>>
>>>> > You cannot conclude _anything_ from those numbers.
>>>>
>>>> There are two numbers, the average and the standard deviation, and
>>>> they are calculated from the data, but the truth is hidden deeper in
>>>> the data. By looking at the particular numbers, I agree completely
>>>> that it is wrong to conclude that one is better than the other. I am
>>>> not saying that the statements in the article are false, just that you
>>>> do not have data to draw the conclusions.
>>>>
>>>> Furthermore I have to say that Geoff got things right (see below). As
>>>> a mathematician, I have to say that statistics is hard, and trusting
>>>> the output of wrk to draw conclusions is outright the wrong thing to
>>>> do.
>>>>
>>>> In this case we have a luxury which you typically do not have: Data is
>>>> essentially free. You can run many tests and you can run short or long
>>>> tests with different parameters. A 30 second test is simply not enough
>>>> for anything.
>>>>
>>>> As Geoff indicated, for each transaction you can extract many relevant
>>>> values from varnishlog, with the status, hit/miss, time to first byte
>>>> and time to last byte being the most obvious ones. They can be
>>>> extracted and saved to a csv file by using varnishncsa with a custom
>>>> format string, and you can use R (used it myself as a tool in my
>>>> previous job - not a fan) to do statistical analysis on the data. The
>>>> Student T suggestion from Geoff is a good idea, but just looking at
>>>> one set of numbers without considering other factors is mathematically
>>>> problematic.
>>>>
>>>> Anyway, some obvious questions then arise. For example:
>>>> - How do the numbers between wrk and varnishlog/varnishncsa compare?
>>>> Did wrk report a total number of transactions than varnish? If there
>>>> is a discrepancy, then the errors might be because of some resource
>>>> restraint (number of sockets or dropped syn packages?).
>>>> - How does the average and maximum compare between varnish and wrk?
>>>> - What is the CPU usage of the kernel, the benchmarking tool and the
>>>> varnish processes in the tests?
>>>> - What is the difference between the time to first byte and the time
>>>> to last byte in Varnish for different object sizes?
>>>>
>>>> When Varnish writes to a socket, it hands bytes over to the kernel,
>>>> and when the write call returns, we do not know how far the bytes have
>>>> come, and how long it will take before they get to the final
>>>> destination. The bytes may be in a kernel buffer, they might be on the
>>>> network card, and they might be already received at the client's
>>>> kernel, and they might have made it all into wrk (which may or may not
>>>> have timestamped the response). Typically, depending on many things,
>>>> Varnish will report faster times than what wrk, but since returning
>>>> from the write call means that the calling thread must be rescheduled,
>>>> it is even possible that wrk will see that some requests are faster
>>>> than what Varnish reports. Running wrk2 with different speeds in a
>>>> series of tests seems natural to me, so that you can observe when (and
>>>> how) the system starts running into bottlenecks. Note that the
>>>> bottleneck can just as well be in wrk2 itself or on the combined CPU
>>>> usage of kernel + Varnish + wrk2.
>>>>
>>>> To complicate things even further: On your ARM vs. x64 tests, my guess
>>>> is that both kernel parameters and parameters for the network are
>>>> different, and the distributions probably have good reason to choose
>>>> different values. It is very likely that these differences affect the
>>>> performance of the systems in many ways, and that different tests will
>>>> have different "optimal" tunings of kernel and network parameters.
>>>>
>>>> Sorry for rambling, but getting the statistics wrong is so easy. The
>>>> question is very interesting, but if you want to draw conclusions, you
>>>> should do the analysis, and (ideally) give access to the raw data in
>>>> case anyone wants to have a look.
>>>>
>>>> Best,
>>>> P?l
>>>>
>>>> fre. 31. jul. 2020 kl. 08:45 skrev Geoff Simmons <geoff at uplex.de>:
>>>> >
>>>> > On 7/28/20 13:52, Martin Grigorov wrote:
>>>> > >
>>>> > > I've just posted an article [1] about comparing the performance of
>>>> Varnish
>>>> > > Cache on two similar
>>>> > > machines - the main difference is the CPU architecture - x86_64 vs
>>>> aarch64.
>>>> > > It uses a specific use case - the backend service just returns a
>>>> static
>>>> > > content. The idea is
>>>> > > to compare Varnish on the different architectures but also to
>>>> compare
>>>> > > Varnish against the backend HTTP server.
>>>> > > What is interesting is that Varnish gives the same throughput as the
>>>> > > backend server on x86_64 but on aarch64 it is around 30% slower
>>>> than the
>>>> > > backend.
>>>> >
>>>> > Does your test have an account of whether there were any errors in
>>>> > backend fetches? Don't know if that explains anything, but with a
>>>> > connect timeout of 10s and first byte timeout of 5m, any error would
>>>> > have a considerable effect on the results of a 30 second test.
>>>> >
>>>> > The test tool output doesn't say anything I can see about error rates
>>>> --
>>>> > whether all responses had status 200, and if not, how many had which
>>>> > other status. Ideally it should be all 200, otherwise the results may
>>>> > not be valid.
>>>> >
>>>> > I agree with phk that a statistical analysis is needed for a robust
>>>> > statement about differences between the two platforms. For that, you'd
>>>> > need more than the summary stats shown in your blog post -- you need
>>>> to
>>>> > collect all of the response times. What I usually do is query Varnish
>>>> > client request logs for Timestamp:Resp and save the number in the last
>>>> > column.
>>>> >
>>>> > t.test() in R runs Student's t-test (me R fanboi).
>>>> >
>>>> >
>>>>
>>> _______________________________________________
>> varnish-dev mailing list
>> varnish-dev at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200805/d2e43cc4/attachment-0001.html>

From guillaume at varnish-software.com  Wed Aug  5 13:52:29 2020
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 5 Aug 2020 06:52:29 -0700
Subject: Compared performance of Varnish Cache on x86_64 and aarch64
In-Reply-To: <CAMomwMpc+4h8rf5cMEMv6yk3c7A5dYv_V5Jzh4tVb=UyrHgXJg@mail.gmail.com>
References: <CAMomwMorvbuhSms0m9nEQ=Y31McJNyR9EefC07K=J8w81iD4KA@mail.gmail.com>
 <70851.1595944863@critter.freebsd.dk>
 <CAMomwMr65an54q9mnUSQ8bcR+XAEgxWStVwb-9aH+7i_oCC53w@mail.gmail.com>
 <81825.1596024704@critter.freebsd.dk>
 <CAMNFQgMbwJYbO_tPxx7c--9EGqs52KE-ai6ez3LhoviKP-m8_A@mail.gmail.com>
 <CAMomwMrw-pmZ0+yC1WAamLkfe3S52pp-WF3E1ayEVmxKksLXQg@mail.gmail.com>
 <CAMomwMrpCXdcytLYFHKHj_9hGfTgPXe1uWyPm9qEdXpvS+5tzw@mail.gmail.com>
 <CAJ6ZYQxTQchdpJFu-8WqwBCgo7OCzbE=YCbs77FFcBD+b6kcLg@mail.gmail.com>
 <CAMomwMpc+4h8rf5cMEMv6yk3c7A5dYv_V5Jzh4tVb=UyrHgXJg@mail.gmail.com>
Message-ID: <CAJ6ZYQy6rFYyHzvU+8b7eqqBu=BG4+ZJ4NV3+A21RCu3G3dZtw@mail.gmail.com>

I stand corrected, good to see it's not an issue.

On Wed, Aug 5, 2020, 02:17 Martin Grigorov <martin.grigorov at gmail.com>
wrote:

> Hi Guillaume,
>
> On Tue, Aug 4, 2020 at 5:47 PM Guillaume Quintard <
> guillaume at varnish-software.com> wrote:
>
>> Hi,
>>
>> > Varnish gives around 20% less throughput than the Golang HTTP server
>> but I guess this is because the Golang server is much simpler than Varnish.
>>
>> Since the backend and vegeta are written in go, it's pretty safe they are
>> going to use H/2 by default, and that's not the case for your varnish
>> instance, so that possibly explain some of the differences you are seeing.
>>
>
> To use H/2 one has to use -http2 parameter (
> https://github.com/tsenart/vegeta#-http2)
> In addition I'd need to start the HTTP server with
> svr.ListenAndServeTLS(cert, key)
> I've added "log.Printf("Protocol: %s", r.Proto)" to the handle function
> and it prints "HTTP/1.1" no matter whether I use -http2 parameter for
> Vegeta or not
>
>
>>
>> Cheers,
>>
>> --
>> Guillaume Quintard
>>
>>
>> On Tue, Aug 4, 2020 at 4:33 AM Martin Grigorov <martin.grigorov at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I've updated the data in the article -
>>> https://medium.com/@martin.grigorov/compare-varnish-cache-performance-on-x86-64-and-aarch64-cpu-architectures-cef5ad5fee5f
>>> Now x86_64 and aarch64 are almost the same!
>>> Varnish gives around 20% less throughput than the Golang HTTP server but
>>> I guess this is because the Golang server is much simpler than Varnish.
>>>
>>> 3 min run produces around 3GB of Vegeta reports (130MB gzipped). If
>>> anyone wants me to extract some extra data just let me know!
>>>
>>> Regards,
>>> Martin
>>>
>>> On Mon, Aug 3, 2020 at 6:14 PM Martin Grigorov <
>>> martin.grigorov at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Thank you all for the feedback!
>>>> After some debugging it appeared that it is a bug in wrk - most of the
>>>> requests' latencies were 0 in the raw reports.
>>>>
>>>> I've looked for a better maintained HTTP load testing tool and I liked
>>>> https://github.com/tsenart/vegeta. it provides (correctly looking)
>>>> statistics, can measure latencies while using constant rate, and last but
>>>> not least can produce plot charts!
>>>> I will update my article and let you know once I'm done!
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>>> On Fri, Jul 31, 2020 at 4:43 PM P?l Hermunn Johansen <
>>>> hermunn at varnish-software.com> wrote:
>>>>
>>>>> I am sorry for being so late to the game, but here it goes:
>>>>>
>>>>> ons. 29. jul. 2020 kl. 14:12 skrev Poul-Henning Kamp <
>>>>> phk at phk.freebsd.dk>:
>>>>> > Your measurement says that there is 2/3 chance that the latency
>>>>> > is between:
>>>>> >
>>>>> >         655.40?s - 798.70?s     = -143.30?s
>>>>> >
>>>>> > and
>>>>> >         655.40?s + 798.70?s     = 1454.10?s
>>>>>
>>>>> No, it does not. There is no claim anywhere that the numbers are
>>>>> following a normal distribution or an approximation of it. Of course,
>>>>> the calculations you do demonstrate that the data is far from normally
>>>>> distributed (as expected).
>>>>>
>>>>> > You cannot conclude _anything_ from those numbers.
>>>>>
>>>>> There are two numbers, the average and the standard deviation, and
>>>>> they are calculated from the data, but the truth is hidden deeper in
>>>>> the data. By looking at the particular numbers, I agree completely
>>>>> that it is wrong to conclude that one is better than the other. I am
>>>>> not saying that the statements in the article are false, just that you
>>>>> do not have data to draw the conclusions.
>>>>>
>>>>> Furthermore I have to say that Geoff got things right (see below). As
>>>>> a mathematician, I have to say that statistics is hard, and trusting
>>>>> the output of wrk to draw conclusions is outright the wrong thing to
>>>>> do.
>>>>>
>>>>> In this case we have a luxury which you typically do not have: Data is
>>>>> essentially free. You can run many tests and you can run short or long
>>>>> tests with different parameters. A 30 second test is simply not enough
>>>>> for anything.
>>>>>
>>>>> As Geoff indicated, for each transaction you can extract many relevant
>>>>> values from varnishlog, with the status, hit/miss, time to first byte
>>>>> and time to last byte being the most obvious ones. They can be
>>>>> extracted and saved to a csv file by using varnishncsa with a custom
>>>>> format string, and you can use R (used it myself as a tool in my
>>>>> previous job - not a fan) to do statistical analysis on the data. The
>>>>> Student T suggestion from Geoff is a good idea, but just looking at
>>>>> one set of numbers without considering other factors is mathematically
>>>>> problematic.
>>>>>
>>>>> Anyway, some obvious questions then arise. For example:
>>>>> - How do the numbers between wrk and varnishlog/varnishncsa compare?
>>>>> Did wrk report a total number of transactions than varnish? If there
>>>>> is a discrepancy, then the errors might be because of some resource
>>>>> restraint (number of sockets or dropped syn packages?).
>>>>> - How does the average and maximum compare between varnish and wrk?
>>>>> - What is the CPU usage of the kernel, the benchmarking tool and the
>>>>> varnish processes in the tests?
>>>>> - What is the difference between the time to first byte and the time
>>>>> to last byte in Varnish for different object sizes?
>>>>>
>>>>> When Varnish writes to a socket, it hands bytes over to the kernel,
>>>>> and when the write call returns, we do not know how far the bytes have
>>>>> come, and how long it will take before they get to the final
>>>>> destination. The bytes may be in a kernel buffer, they might be on the
>>>>> network card, and they might be already received at the client's
>>>>> kernel, and they might have made it all into wrk (which may or may not
>>>>> have timestamped the response). Typically, depending on many things,
>>>>> Varnish will report faster times than what wrk, but since returning
>>>>> from the write call means that the calling thread must be rescheduled,
>>>>> it is even possible that wrk will see that some requests are faster
>>>>> than what Varnish reports. Running wrk2 with different speeds in a
>>>>> series of tests seems natural to me, so that you can observe when (and
>>>>> how) the system starts running into bottlenecks. Note that the
>>>>> bottleneck can just as well be in wrk2 itself or on the combined CPU
>>>>> usage of kernel + Varnish + wrk2.
>>>>>
>>>>> To complicate things even further: On your ARM vs. x64 tests, my guess
>>>>> is that both kernel parameters and parameters for the network are
>>>>> different, and the distributions probably have good reason to choose
>>>>> different values. It is very likely that these differences affect the
>>>>> performance of the systems in many ways, and that different tests will
>>>>> have different "optimal" tunings of kernel and network parameters.
>>>>>
>>>>> Sorry for rambling, but getting the statistics wrong is so easy. The
>>>>> question is very interesting, but if you want to draw conclusions, you
>>>>> should do the analysis, and (ideally) give access to the raw data in
>>>>> case anyone wants to have a look.
>>>>>
>>>>> Best,
>>>>> P?l
>>>>>
>>>>> fre. 31. jul. 2020 kl. 08:45 skrev Geoff Simmons <geoff at uplex.de>:
>>>>> >
>>>>> > On 7/28/20 13:52, Martin Grigorov wrote:
>>>>> > >
>>>>> > > I've just posted an article [1] about comparing the performance of
>>>>> Varnish
>>>>> > > Cache on two similar
>>>>> > > machines - the main difference is the CPU architecture - x86_64 vs
>>>>> aarch64.
>>>>> > > It uses a specific use case - the backend service just returns a
>>>>> static
>>>>> > > content. The idea is
>>>>> > > to compare Varnish on the different architectures but also to
>>>>> compare
>>>>> > > Varnish against the backend HTTP server.
>>>>> > > What is interesting is that Varnish gives the same throughput as
>>>>> the
>>>>> > > backend server on x86_64 but on aarch64 it is around 30% slower
>>>>> than the
>>>>> > > backend.
>>>>> >
>>>>> > Does your test have an account of whether there were any errors in
>>>>> > backend fetches? Don't know if that explains anything, but with a
>>>>> > connect timeout of 10s and first byte timeout of 5m, any error would
>>>>> > have a considerable effect on the results of a 30 second test.
>>>>> >
>>>>> > The test tool output doesn't say anything I can see about error
>>>>> rates --
>>>>> > whether all responses had status 200, and if not, how many had which
>>>>> > other status. Ideally it should be all 200, otherwise the results may
>>>>> > not be valid.
>>>>> >
>>>>> > I agree with phk that a statistical analysis is needed for a robust
>>>>> > statement about differences between the two platforms. For that,
>>>>> you'd
>>>>> > need more than the summary stats shown in your blog post -- you need
>>>>> to
>>>>> > collect all of the response times. What I usually do is query Varnish
>>>>> > client request logs for Timestamp:Resp and save the number in the
>>>>> last
>>>>> > column.
>>>>> >
>>>>> > t.test() in R runs Student's t-test (me R fanboi).
>>>>> >
>>>>> >
>>>>>
>>>> _______________________________________________
>>> varnish-dev mailing list
>>> varnish-dev at varnish-cache.org
>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200805/fd10dfd0/attachment.html>

From phk at critter.freebsd.dk  Thu Aug  6 09:06:29 2020
From: phk at critter.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 06 Aug 2020 09:06:29 +0000
Subject: Starting to implement Cache-Status (fwd)
Message-ID: <36898.1596704789@critter.freebsd.dk>

Anybody got time for some VCL hacking ?

------- Forwarded Message
From: Mark Nottingham <mnot at mnot.net>
Message-Id: <97385692-BFF5-4FD2-A2EB-EC499182DCA6 at mnot.net>
Date: Thu, 6 Aug 2020 19:01:54 +1000
To: HTTP Working Group <ietf-http-wg at w3.org>
Subject: Starting to implement Cache-Status

Just as a heads-up, we're starting to get implementation of =
Cache-Status,[1], and I suspect that we're not too far from Last =
Call.[2]

So far I'm aware of:

* My implementation for Fastly VCL - =
<https://gist.github.com/mnot/74ba8ed638a3d85659aa2868b9240d50>
* Amos' patch for Squid - =
<https://github.com/squid-cache/squid/pull/705>

Are there others? I'd like to get more feedback soon, before we ship it, =
so consider this a call for that.

Cheers,

1. =
https://httpwg.org/http-extensions/draft-ietf-httpbis-cache-header.html
2. Speaking as editor of that draft, not as a chair.

- --
Mark Nottingham   https://www.mnot.net/



------- End of Forwarded Message

From scan-admin at coverity.com  Sun Aug  9 11:56:04 2020
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Sun, 09 Aug 2020 11:56:04 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <5f2fe4541372c_539372b0e4f99ef7036535@prd-scan-dashboard-0.mail>


    Your request for analysis of varnish has been completed successfully.
    The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3D1MIQ_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je49fA4GmNJYAuSrNjj9hmGH7ICDImEaC6mapMDbsSvoynC8oEc-2BnnGfc6Oyul3bKPevksHQMUp-2Fv-2BAwTJGTP6V9TppOE0kL2BvAhdRv9rmipMPmVQOSL3liFLRaDS16AlNc2NAymY4jgeOOAyopzNU15TVSl-2BdPIB0yalquZIUaUSOxJrLCVHJ7fDbUZYZvD1gs-3D

    Build ID: 331786

    Analysis Summary:
       New defects found: 46
       Defects eliminated: 8

    If you have difficulty understanding any defects, email us at scan-admin at coverity.com,
    or post your question to StackOverflow
    at https://u15810271.ct.sendgrid.net/ls/click?upn=CTPegkVN6peWFCMEieYYmPWIi1E4yUS9EoqKFcNAiqhRq8qmgeBE-2Bdt3uvFRAFXd-2FlwX83-2FVVdybfzIMOby0qA-3D-3Df1t8_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je49fA4GmNJYAuSrNjj9hmGH7ICDImEaC6mapMDbsSvoynCfa67IBj74z80FeNieHXyDTrrA4F04fvskQ78asSKgsTO0sPNa4MVU889-2BsJnPfzqc9NUMup8uwSqqiDSlzgginyIOiooO5UOwpXUSKrRwTh3elOwVHdyI0Ng9sTSTFThPQMvpdQmOAR2YlUZJ4J5k-3D

From guillaume at varnish-software.com  Tue Aug 11 19:49:55 2020
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 11 Aug 2020 12:49:55 -0700
Subject: Starting to implement Cache-Status (fwd)
In-Reply-To: <36898.1596704789@critter.freebsd.dk>
References: <36898.1596704789@critter.freebsd.dk>
Message-ID: <CAJ6ZYQxHj-pw_DcObOiXV2Snha2p-gRr7TcECh0KdaKxee-_qA@mail.gmail.com>

Hi,

If someone wants a leg up:
https://docs.varnish-software.com/tutorials/hit-miss-logging/

What's the goal here though? Just to provide a VCL snippet following the
spec?

-- 
Guillaume Quintard


On Thu, Aug 6, 2020 at 2:07 AM Poul-Henning Kamp <phk at critter.freebsd.dk>
wrote:

> Anybody got time for some VCL hacking ?
>
> ------- Forwarded Message
> From: Mark Nottingham <mnot at mnot.net>
> Message-Id: <97385692-BFF5-4FD2-A2EB-EC499182DCA6 at mnot.net>
> Date: Thu, 6 Aug 2020 19:01:54 +1000
> To: HTTP Working Group <ietf-http-wg at w3.org>
> Subject: Starting to implement Cache-Status
>
> Just as a heads-up, we're starting to get implementation of =
> Cache-Status,[1], and I suspect that we're not too far from Last =
> Call.[2]
>
> So far I'm aware of:
>
> * My implementation for Fastly VCL - =
> <https://gist.github.com/mnot/74ba8ed638a3d85659aa2868b9240d50>
> * Amos' patch for Squid - =
> <https://github.com/squid-cache/squid/pull/705>
>
> Are there others? I'd like to get more feedback soon, before we ship it, =
> so consider this a call for that.
>
> Cheers,
>
> 1. =
> https://httpwg.org/http-extensions/draft-ietf-httpbis-cache-header.html
> 2. Speaking as editor of that draft, not as a chair.
>
> - --
> Mark Nottingham   https://www.mnot.net/
>
>
>
> ------- End of Forwarded Message
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20200811/c1ebfa3d/attachment.html>

From scan-admin at coverity.com  Sun Aug 16 11:56:50 2020
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Sun, 16 Aug 2020 11:56:50 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <5f391f0164a28_19b4172ad70c0dcf60842d0@prd-scan-dashboard-0.mail>


    Your request for analysis of varnish has been completed successfully.
    The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DrcnE_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4-2FbQXOyP6BexfcUddBeVNuLpS38F2lpbyAkIOzAub24W-2FLMBrAZGqQqlj40nbDAqUGn4ok9-2Fvk-2F94oA9TccxlnQwp7P1D75vxjUO7-2FMF7TLuHFkylJRaeNPBFusd4jKQ4kHIRnirHVZ8hcZjNh0k-2BxPTwDxEV-2BbO3wYYBPw5bUpFJ2IzHvYYaDL17GgIA2QB24-3D

    Build ID: 333119

    Analysis Summary:
       New defects found: 0
       Defects eliminated: 46


From scan-admin at coverity.com  Sun Aug 23 11:57:07 2020
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Sun, 23 Aug 2020 11:57:07 +0000 (UTC)
Subject: Coverity Scan: Analysis completed for varnish
Message-ID: <5f425992e853e_105cfa2b106b1fcf606293f@prd-scan-dashboard-0.mail>


    Your request for analysis of varnish has been completed successfully.
    The results are available at https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yrJbcjUxJo9eCHXi2QbgV6mmItSKtPrD4wtuBl7WlE3MQ-3D-3DC9l1_WyTzqwss9kUEGhvWd0SG502mTu1yasCtuh9h-2FD3Je4926TGpDsO9ZIO0qE0jq9LcFFckLiWs3Ac9Sfz5vnX774MBvxvQll-2FYFwaGZu5vNoBHUYIIUDRfZhmPnX3haGESPnJFKXZK5iU38rhc-2FgvRZ2N-2FQhXmxZE-2FR0YcYodKO2u9uRxcbmwIYK5DRGDfjk5X6qZnI-2FnAElWvzHOAegw2auc1R4LEo9cuUrOKGn04f8o-3D

    Build ID: 334684

    Analysis Summary:
       New defects found: 0
       Defects eliminated: 0


From phk at phk.freebsd.dk  Mon Aug 31 08:00:13 2020
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 31 Aug 2020 08:00:13 +0000
Subject: Decide Name/number of 2020-09-15 release
Message-ID: <51801.1598860813@critter.freebsd.dk>

We're going to nail the name/number of the 2020-09-15 release at the
bugwash today.  Please come prepared.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From dridi at varni.sh  Mon Aug 31 16:48:04 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 31 Aug 2020 16:48:04 +0000
Subject: Decide Name/number of 2020-09-15 release
In-Reply-To: <51801.1598860813@critter.freebsd.dk>
References: <51801.1598860813@critter.freebsd.dk>
Message-ID: <CABoVN9A+tyHSSmXJO-qq53=HKAiWC9oWg6HQc7t4Pf6y_Nj+QA@mail.gmail.com>

On Mon, Aug 31, 2020 at 8:00 AM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> We're going to nail the name/number of the 2020-09-15 release at the
> bugwash today.  Please come prepared.

The consensus is 6.5 unless we made a change that warrants a 7.0 bump,
Nils will try to determine that tomorrow.

Coincidentally, tomorrow we start the freeze period and stop pushing
anything that is not documentation or related to release notes. The
freeze period lasts for the whole month of September.

Dridi