<div dir="ltr"><div dir="ltr">Thanks a lot Dridi & Team for details..<div><br></div><div>You could try avoiding grouping, use varnishncsa with a custom format,<br>overall store and process less data in memory. </div><div><font color="#000000"><b>-I was analyzing varnishncsa logs as well and could see problem with it also. Means missing ReqAcct sometime.</b></font></div><div><font color="#000000"><b>Does that means shared memory its self does not have ReqAcct tag ? </b></font></div><div><font color="#000000"><b>-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.</b></font></div><div><br></div><div>If only ReqAcct is important, and the rest of the information you need<br>is available on the request side, you should definitely stop using the<br>-g option, and use the -c option to further limit internal processing. </div><div><b>-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 ). </b><br></div><div><b>-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 ? </b></div><div><b>-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..</b></div><div><b><br></b></div><div>Thank you</div><div>Hardik</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Mar 2019 at 22:49, Dridi Boukelmoune <dridi@varni.sh> 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 Wed, Mar 13, 2019 at 3:56 PM Hardik <<a href="mailto:hetardik.p@gmail.com" target="_blank">hetardik.p@gmail.com</a>> wrote:<br>
><br>
> Hi Dridi,<br>
><br>
> We should able to recreate with load and mobile requests. I have not tried with 6.0.3.<br>
<br>
I guess there's no need for that. Your varnishlog setup is stretched<br>
too thin to cope with your load.<br>
<br>
I was completely oblivious to the problems slink spotted right away...<br>
<br>
> @Nils,<br>
> 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.<br>
><br>
> 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...!<br>
<br>
You could try avoiding grouping, use varnishncsa with a custom format,<br>
overall store and process less data in memory.<br>
<br>
> Normal varnish command we use to grep running logs<br>
> varnishlog -g request -q "ReqURL ~ '/abc/xyz'"<br>
><br>
> command uses to read shared memory directly for billing<br>
> varnishlog -g session<br>
> --> 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.<br>
<br>
There are few practical uses of -g session for live traffic. This<br>
works better on offline logs for example when examining traffic<br>
post-mortem.<br>
<br>
If only ReqAcct is important, and the rest of the information you need<br>
is available on the request side, you should definitely stop using the<br>
-g option, and use the -c option to further limit internal processing.<br>
<br>
If you need information from the backend transactions too, try to<br>
figure how you could make this information available on the client<br>
side.<br>
<br>
Dridi<br>
</blockquote></div>