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 <[email protected]> wrote: > On Wed, Mar 13, 2019 at 3:56 PM Hardik <[email protected]> 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 >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
