reg: not getting ReqAcct tag in varnishlog

Hardik hetardik.p at gmail.com
Sun Mar 17 12:09:13 UTC 2019


Thanks a lot Dridi & Team for details..

You could try avoiding grouping, use varnishncsa with a custom format,
overall store and process less data in memory.
*-I was analyzing varnishncsa logs as well and could see problem with it
also. Means missing ReqAcct sometime.*
*Does that means shared memory its self does not have ReqAcct tag ? *
*-Is grouping happen to clients memory ? means client reads from shared
memory and then does grouping in client's memory ? Please give some details
so based on that I can arrange the things. Also I am curious to understand.
Any document link or point out any coding part, I will go through that as
well.*

If only ReqAcct is important, and the rest of the information you need
is available on the request side, you should definitely stop using the
-g option, and use the -c option to further limit internal processing.
*-Yes, we are reading now request side only ( till now was reading session
also but found out other alternative so stopped that after your comment ). *
*-I have few doubts here.. is there a difference between NOT assigning -g
option to g_arg(means keep default to  xvid ) and assigning -c option ? *
*-Currently I have stopped using -g option in service which is reading shm
so kept to default option. To by pass berequest tags I have started using
"VSL_t_bereq" structure member. If -c option is still better than this then
I will test out that also. Please suggest..*

Thank you
Hardik

On Wed, 13 Mar 2019 at 22:49, Dridi Boukelmoune <dridi at varni.sh> wrote:

> On Wed, Mar 13, 2019 at 3:56 PM Hardik <hetardik.p at gmail.com> wrote:
> >
> > Hi Dridi,
> >
> > We should able to recreate with load and mobile requests. I have not
> tried with 6.0.3.
>
> I guess there's no need for that. Your varnishlog setup is stretched
> too thin to cope with your load.
>
> I was completely oblivious to the problems slink spotted right away...
>
> > @Nils,
> > We are seeing issue with both varnishlog and varnishlog with -g option.
> But here problem is, shared memory it self does not have ReqAcct tag I
> think ( please correct me if I am wrong). Because all the clients which are
> reading shm all are getting same thing..means no ReqAcct. But yes I am
> agree that impact with "varnishlog -g session" is more.
> >
> > So If shared memory it self has no ReqAcct tag then all clients will
> also not get right ? How to fix this problem ? Please help with some
> details which I can understand because we are loosing bills for which we
> are serving traffic...!
>
> You could try avoiding grouping, use varnishncsa with a custom format,
> overall store and process less data in memory.
>
> > Normal varnish command we use to grep running logs
> > varnishlog -g request -q "ReqURL ~ '/abc/xyz'"
> >
> > command uses to read shared memory directly for billing
> > varnishlog -g session
> > --> we are already planing to use "varnishlog -g xvid" for billing api.
> Because I understood is, -g session option is taking more time to arrange
> in particular order and delivery final output. Please help with some more
> detail.. It will really helpful.
>
> There are few practical uses of -g session for live traffic. This
> works better on offline logs for example when examining traffic
> post-mortem.
>
> If only ReqAcct is important, and the rest of the information you need
> is available on the request side, you should definitely stop using the
> -g option, and use the -c option to further limit internal processing.
>
> If you need information from the backend transactions too, try to
> figure how you could make this information available on the client
> side.
>
> Dridi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20190317/bf8b47e2/attachment.html>


More information about the varnish-misc mailing list