From kokoniimasu at gmail.com Sun Feb 2 11:37:39 2014 From: kokoniimasu at gmail.com (kokoniimasu) Date: Sun, 2 Feb 2014 20:37:39 +0900 Subject: Statistics for each domain or url-pattern Message-ID: Hi, all. I made a convenient script for cache tuning. This script show to statistics (hit-rate, bps, rps, error-rate and other.. ) for each domain or url-pattern. Output sample: date: 2014/02/02 12:10:00 interval: 5 Host | Mbps | rps | hit | time/req | (H)time/req | (M)time/req | KB/req | 2xx/s | 3xx/s | 4xx/s | 5xx/s --------------------------------------------------------------------------------------------------------------------------------------------------------------------- #alldata | 0.000938 | 1.800000 | 22.222222 | 0.000905 | 0.000103 | 0.001134 | 0.066732 | 1.400000 | 0.000000 | 0.400000 | 0.000000 example.net | 0.000038 | 1.000000 | 0.000000 | 0.001236 | 0.000000 | 0.001236 | 0.004883 | 1.000000 | 0.000000 | 0.000000 | 0.000000 example2.net | 0.000015 | 0.400000 | 0.000000 | 0.000878 | 0.000000 | 0.000878 | 0.004883 | 0.400000 | 0.000000 | 0.000000 | 0.000000 example3.net | 0.000885 | 0.400000 | 100.000000 | 0.000103 | 0.000103 | 0.000000 | 0.283203 | 0.000000 | 0.000000 | 0.400000 | 0.000000 --url-pattern date: 2014/02/02 12:14:32 interval: 5 Host | Mbps | rps | hit | time/req | (H)time/req | (M)time/req | KB/req | 2xx/s | 3xx/s | 4xx/s | 5xx/s ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ #alldata | 0.002698 | 1.600000 | 75.000000 | 0.000339 | 0.000101 | 0.001053 | 0.215820 | 0.400000 | 0.000000 | 1.200000 | 0.000000 [F1]example.net@^/img/ | 0.001788 | 0.800000 | 100.000000 | 0.000095 | 0.000095 | 0.000000 | 0.286133 | 0.000000 | 0.000000 | 0.800000 | 0.000000 [F2]example.net@^/css/ | 0.000894 | 0.400000 | 100.000000 | 0.000112 | 0.000112 | 0.000000 | 0.286133 | 0.000000 | 0.000000 | 0.400000 | 0.000000 [F3]example.net | 0.000015 | 0.400000 | 0.000000 | 0.001053 | 0.000000 | 0.001053 | 0.004883 | 0.400000 | 0.000000 | 0.000000 | 0.000000 https://github.com/xcir/varnishHostStat I hope that this script is of help to you. -- Shohei Tanaka(@xcir) http://xcir.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From collier.matthew at gmail.com Wed Feb 5 17:38:32 2014 From: collier.matthew at gmail.com (Matt Collier) Date: Wed, 05 Feb 2014 12:38:32 -0500 Subject: Varnish is functioning and caching but varnihstat show no hits Message-ID: <52F27718.7010309@gmail.com> I am running varnish v. 3.05 on a debian server. I have had varnish running on this server for a long while now and I am not having any problems with the installation except: When I run varnishstat, my hit ratio is 0, and when I run varnishstat -1 it shows 0 client connections accepted. I can also add that the server uptime displayed in the upper left hand corner of varnishstat is does not appear to be incrementing properly. It's been sitting at 0+00:00:00 for the last hour. There are values in other misc. items such as backend_busy, backend_reuse The varnishtop utility shows activity as expected. I read that it is possible for varnishstat to connect to the wrong daemon if a name is not specified, so I am utilizing the -n parameter in starting the daemon and varnishstat I am quite certain varnish is serving the data and even getting cache hits through the use of tools likehttp://www.isvarnishworking.com/ The site name is http://events.floydecovillage.com if you'd like to see for yourself. I am familiar with cookie issues relating to the use of CMS's. I believe I have adequately addressed all these issues. Again, tools like isvarnishworking.com show the proper "X-Varnish-Cache:HIT" header. I can add that I upgraded varnish from 3.0.2-3 to 3.0.4-1 in August of last year. I upgraded from 3.04 to 3.05 today. EDIT: I just found this post of someone reporting similar symptoms: http://www.gossamer-threads.com/lists/varnish/misc/28836 -- Matt Collier http://floydecovillage.com/ Floyd EcoVillage Floyd, VA -------------- next part -------------- An HTML attachment was scrubbed... URL: From japrice at gmail.com Wed Feb 5 17:48:47 2014 From: japrice at gmail.com (Jason Price) Date: Wed, 5 Feb 2014 12:48:47 -0500 Subject: Varnishlog -d -m XID: ? Message-ID: How can I see the full varnishlog output for a given XID (assuming it hasn't expired from the shared memory log)? (ideally, it wouldn't use '-m' since it would require separate calls for -c and -b...) --Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From piotr.teodorowski at unity.pl Thu Feb 6 03:57:17 2014 From: piotr.teodorowski at unity.pl (Piotr Teodorowski) Date: Thu, 6 Feb 2014 04:57:17 +0100 Subject: Fwd: Miss and obj.hits In-Reply-To: <52F0980A.7090300@unity.pl> References: <52F0980A.7090300@unity.pl> Message-ID: <52F3081D.80306@unity.pl> Hi, i have strange behaviour with few requests. It looks, that response wasn't in cache, it was fetched and obj.hits wasn't 0. Is it a bug? Should I upgrade Varnish to 3.X? 15 SessionOpen c 89.231.100.51 40774 XXX.XXX.XXX.97:80 15 ReqStart c 89.231.100.51 40774 783244377 15 RxRequest c GET 15 RxURL c / 15 RxProtocol c HTTP/1.1 15 RxHeader c TE: deflate,gzip;q=0.3 15 RxHeader c Connection: TE, close 15 RxHeader c Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 15 RxHeader c Host: www.example.com 15 RxHeader c Referer: http://monit24.pl/?cmd_id=1391237079.43060 15 RxHeader c User-Agent: www.monit24.pl-m24Bot/3.1- 15 VCL_call c recv 15 VCL_acl c NO_MATCH Unity 15 VCL_acl c NO_MATCH Unity 15 VCL_acl c NO_MATCH Unity 15 VCL_return c lookup 15 VCL_call c hash hash 15 VCL_call c miss fetch 15 Backend c 16 tsprod tsapp1 15 TTL c 783244377 RFC 120 1391237080 0 0 0 0 15 VCL_call c fetch pass 15 ObjProtocol c HTTP/1.1 15 ObjStatus c 200 15 ObjResponse c OK 15 ObjHeader c Date: Sat, 01 Feb 2014 06:44:40 GMT 15 ObjHeader c Server: LiteSpeed 15 ObjHeader c X-Powered-By: PHP/5.4.13 15 ObjHeader c Content-Type: text/html 15 ObjHeader c X-Host-Name: tsapp1 15 VCL_call c deliver deliver 15 TxProtocol c HTTP/1.1 15 TxStatus c 200 15 TxResponse c OK 15 TxHeader c Server: LiteSpeed 15 TxHeader c X-Powered-By: PHP/5.4.13 15 TxHeader c Content-Type: text/html 15 TxHeader c X-Host-Name: tsapp1 15 TxHeader c Content-Length: 0 15 TxHeader c Date: Sat, 01 Feb 2014 06:44:40 GMT 15 TxHeader c X-Varnish: 783244377 15 TxHeader c Age: 0 15 TxHeader c Via: 1.1 varnish 15 TxHeader c Connection: close 15 TxHeader c X-Cache: HIT 15 TxHeader c X-Cache-Hits: 1 15 Length c 0 15 ReqEnd c 783244377 1391237080.636201859 1391237080.811423540 0.000034094 0.175161123 0.000060558 sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; set resp.http.X-Cache-Hits = obj.hits; } else { set resp.http.X-Cache = "MISS"; } if (resp.http.X-Mark) { unset resp.http.X-Mark; set resp.http.age = "0"; } return(deliver); } varnishd -V varnishd (varnish-2.1.5 SVN ) CentOS 6.3 Regards, Pitor Teodorowski From Anton.Kornexl at Uni-Passau.De Thu Feb 6 12:26:22 2014 From: Anton.Kornexl at Uni-Passau.De (Anton Kornexl) Date: Thu, 06 Feb 2014 13:26:22 +0100 Subject: Backend-health Message-ID: <52F38D7E020000940007E257@smtp1.gw.uni-passau.de> Hello, i have many backends definied in varnish (different IPs). But all backends are vhosts of the same apache installation (same host as Varnish, access with localhost) If one backend is healthy/unhealthy, then normally all backends are healthy/unhealthy Is it possible to probe only one backend and set the healty/unhealthy status for all backends -- Anton Kornexl -------------- next part -------------- A non-text attachment was scrubbed... Name: Kornexl, Anton.vcf Type: application/octet-stream Size: 244 bytes Desc: not available URL: From Anton.Kornexl at Uni-Passau.De Thu Feb 6 13:46:48 2014 From: Anton.Kornexl at Uni-Passau.De (Anton Kornexl) Date: Thu, 06 Feb 2014 14:46:48 +0100 Subject: Backend-health checks Message-ID: <52F3A058020000940007E267@smtp1.gw.uni-passau.de> Hello, running varnish-3.0.5 revision 1a89b1f on Ubuntu 12.04 I have an health-check defined with the following definition backend localhost_1 { .host = "127.0.0.1"; .port = "8080"; .first_byte_timeout = 300s; .probe = { .url = "/varnish-health-check.html"; .interval = 50s; .timeout = 1 s; .window = 5; .threshold = 3; } } in varnishstat after one day: VBE.localhost_1(127.0.0.1,,8080).happy18446743798697425919 . Happy health probes The check reaches the Webserver every 50 seconds. The reported probes 18446743798697425919 in varnishstat are impossible for one day -------------- next part -------------- A non-text attachment was scrubbed... Name: Kornexl, Anton.vcf Type: application/octet-stream Size: 244 bytes Desc: not available URL: From al-varnishmisc at none.at Thu Feb 6 15:30:08 2014 From: al-varnishmisc at none.at (Aleksandar Lazic) Date: Thu, 06 Feb 2014 16:30:08 +0100 Subject: Question about designed solution with dynamic backend setup based on csv-file with backend Basic Authentication Message-ID: Dear list members. I have the following need. A external script make a request to varnish and varnish, get a picture from the specified backend in the mapping file. Store the for ~5Min (=ttl=5m) and the re-fetch it from the backend. 1.) There is a mapping file which looks like this. id;URL;username;password 2.) Build per ID a backend with username:password 3.) Use the right backend for the $REQUEST 4.) Check the backend for availability. Due to the fact that I'm quite new to varnish I hope you can point me to the right way. After some ixquicking and googleing I have found some useful links. https://ixquick.com/do/search?q=varnish+backend+auth https://www.google.de/#q=site:varnish-cache.org+auth https://stackoverflow.com/questions/17704712/varnish-and-esi-http-auth My Idea based on the picture https://www.varnish-cache.org/trac/wiki/VCLExampleDefault and https://www.varnish-cache.org/docs/3.0/reference/vcl.html?highlight=include#multiple-subroutines is. @2.) Write a script which create a $ID.vcl with the necessary "backend $ID { ...}" files. This script add also a 'sub vcl_recv {...}' per backend with header set req.http.Authorization = "BASIC [base64 encoded admin:adminpass]" @3.) add include $sysconfdir/conf.d/*.vcl into default.vcl @4.) I will use https://www.varnish-cache.org/docs/3.0/reference/vcl.html?highlight=include#backend-probes with .request option for the Auth-Header. This solution is very specific for my set-up. Is there a more generic varnish-way to solve my need? Can I use some 'scripting' possibilities in varnish? Is this possible "$sysconfdir/conf.d/*.vcl"? What do you think about the designed solution? Thank you for reading and help. Best regards Aleks From geoff at uplex.de Thu Feb 6 15:31:37 2014 From: geoff at uplex.de (Geoff Simmons) Date: Thu, 06 Feb 2014 16:31:37 +0100 Subject: Backend-health checks In-Reply-To: <52F3A058020000940007E267@smtp1.gw.uni-passau.de> References: <52F3A058020000940007E267@smtp1.gw.uni-passau.de> Message-ID: <52F3AAD9.2070803@uplex.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/06/2014 02:46 PM, Anton Kornexl wrote: > > in varnishstat after one day: > > VBE.localhost_1(127.0.0.1,,8080).happy18446743798697425919 > . Happy health probes The figure in varnishstat is a 64-bit bitmap, representing the last 64 checks (1=good, 0=unhealthy). Your result has 3 0-bits in it (according to my caclulator), so three of your last 64 health checks were unsuccessful. Best, 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJS86rZAAoJEOUwvh9pJNURGa0P/0zo2hA3NgtaqU7w7WNLsSfJ 50u01fnzpnVaSGQdDio5q3rUAOUHAO9KBF0iSTIfPavZ4IlhmE1Rwoi2JGLY7ga4 9BWxwdzLnpLElaPTjgvAqUlZoLradXo6aG937EDOZ+MPsFSb/LviumHI/wVrakaK R90gZY2oh3+gb2eZjYQCOBtaZkwr6YVWTyYJ+84JgDp+mHR5P1ogOG7lo1ISS9tq lxxXlx2SPd3EaEoIDIbl1VIv7BdX0DD464l5hClGHPaRUZ6Cu0UA6w+bzEuA6IlP 2oQmGKfxPjMEnbHrnTLbk4DqXr9p6sXJyaw4B+rJhpkhnx2u4F53HP1F+B1ApiYn W+OuY0U60deEBVstzu0hPTTyN5sFd+8jA0S7+kJ5IuZFD57BoD+mWrDeZVya4sKE pmU3Rqw/Si1BdiiylUjJiQ5uE7RnonHTz+pn1N9BM6+9LRpDkhlg3GybA/HA8tVt Xh+IPdwYV5MiU2FO1czpgabs5GxIUMCbotmb7IsBC8RLVoZKKPxhDr0gwFtTUx+B DioW0FMoIlu7yK083x0xUruFxEGO/mx/n7p8hW32KDLZMbzr32EvCkjvoNi2c1ys Drs2e72E7xGA9SeiJSOKYlHxZXcej+a2FP7UOagFUWWV07+PTXCdb81e4mdEzDxv 0tX14CCtqUXLXuLWGeuZ =FonO -----END PGP SIGNATURE----- From dridi.boukelmoune at zenika.com Mon Feb 10 20:11:46 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Mon, 10 Feb 2014 21:11:46 +0100 Subject: Varnish 503 error In-Reply-To: References: Message-ID: Hi, On Wed, Nov 20, 2013 at 8:25 PM, Jean Respen wrote: > Hi all, > > I sometimes have the following error in my logs: > > 12 VCL_return c hash > 12 VCL_call c miss fetch > 12 Backend c 15 default default > 12 FetchError c http first read error: -1 0 (No error recorded) > 12 Backend c 11 default default > 12 FetchError c http first read error: -1 0 (No error recorded) > 12 VCL_call c error deliver > 12 VCL_call c deliver deliver > 12 TxProtocol c HTTP/1.1 > 12 TxStatus c 503 > 12 TxResponse c Service Unavailable > 12 TxHeader c Server: Varnish > > Does anyone know what could happen? It is boring, as it gives a 503 > error on around 1 over 5 requests. Was you problem solved or do you still need an anwser ? I'm slowly catching up (yes I'm that late) and I could give a quick peek in the source to try to figure out what's hapening. IMHO there isn't probably too many reasons to get a FetchError in the logs. By the way, what version of Varnish are you using ? Dridi > Thanks, > > Cheers, > > -- > Jean Respen > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From lkarsten at varnish-software.com Tue Feb 18 10:10:07 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 18 Feb 2014 11:10:07 +0100 Subject: Question about designed solution with dynamic backend setup based on csv-file with backend Basic Authentication In-Reply-To: References: Message-ID: <20140218101006.GA1962@immer.varnish-software.com> On Thu, Feb 06, 2014 at 04:30:08PM +0100, Aleksandar Lazic wrote: > I have the following need. > A external script make a request to varnish and varnish, get a > picture from the > specified backend in the mapping file. > Store the for ~5Min (=ttl=5m) and the re-fetch it from the backend. > 1.) There is a mapping file which looks like this. > id;URL;username;password > 2.) Build per ID a backend with username:password > 3.) Use the right backend for the $REQUEST > 4.) Check the backend for availability. [..] > @2.) Write a script which create a $ID.vcl with the necessary > "backend $ID { ...}" files. > This script add also a 'sub vcl_recv {...}' per backend with header > > set req.http.Authorization = "BASIC [base64 encoded > admin:adminpass]" If this is for the backend connection/requests, you need to set it on bereq in vcl_miss. If you want to validate a client basic auth session, you should let your generating script write a long if-else segment that checks that the data, not setting/overriding it. > @3.) add include $sysconfdir/conf.d/*.vcl into default.vcl > @4.) I will use https://www.varnish-cache.org/docs/3.0/reference/vcl.html?highlight=include#backend-probes > with .request option for the Auth-Header. > This solution is very specific for my set-up. > Is there a more generic varnish-way to solve my need? No, this should be fine. > Can I use some 'scripting' possibilities in varnish? That is what VCL is for. You're already doing it. > Is this possible "$sysconfdir/conf.d/*.vcl"? No. varnishd will only read a single VCL file, and VCL include entries does not support globbing/wildcards. -- With regards, Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Tue Feb 18 10:12:56 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 18 Feb 2014 11:12:56 +0100 Subject: Backend-health In-Reply-To: <52F38D7E020000940007E257@smtp1.gw.uni-passau.de> References: <52F38D7E020000940007E257@smtp1.gw.uni-passau.de> Message-ID: <20140218101255.GB1962@immer.varnish-software.com> On Thu, Feb 06, 2014 at 01:26:22PM +0100, Anton Kornexl wrote: > i have many backends definied in varnish (different IPs). > But all backends are vhosts of the same apache installation (same host as Varnish, access with localhost) > If one backend is healthy/unhealthy, then normally all backends are healthy/unhealthy > Is it possible to probe only one backend and set the healty/unhealthy status for all backends No, this is not possible. -- With regards, Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Tue Feb 18 10:24:32 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 18 Feb 2014 11:24:32 +0100 Subject: Varnishlog -d -m XID: ? In-Reply-To: References: Message-ID: <20140218102431.GC1962@immer.varnish-software.com> On Wed, Feb 05, 2014 at 12:48:47PM -0500, Jason Price wrote: > How can I see the full varnishlog output for a given XID (assuming it > hasn't expired from the shared memory log)? > (ideally, it wouldn't use '-m' since it would require separate calls for -c > and -b...) You currently can't do that easily. In the upcoming 4.0 version this is simple to do though: https://www.varnish-cache.org/docs/trunk/reference/vsl-query.html https://www.varnish-cache.org/docs/trunk/reference/varnishlog.html -- With regards, Lasse Karstensen Varnish Software AS From lkarsten at varnish-software.com Tue Feb 18 10:28:38 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Tue, 18 Feb 2014 11:28:38 +0100 Subject: Varnish is functioning and caching but varnihstat show no hits In-Reply-To: <52F27718.7010309@gmail.com> References: <52F27718.7010309@gmail.com> Message-ID: <20140218102837.GD1962@immer.varnish-software.com> On Wed, Feb 05, 2014 at 12:38:32PM -0500, Matt Collier wrote: > I am running varnish v. 3.05 on a debian server. I have had varnish > running on this server for a long while now and I am not having any > problems with the installation except: [..] > When I run varnishstat, my hit ratio is 0, and when I run > varnishstat -1 it shows 0 client connections accepted. I can also > add that the server uptime displayed in the upper left hand corner > of varnishstat is does not appear to be incrementing properly. It's > been sitting at 0+00:00:00 for the last hour. [..] > I can add that I upgraded varnish from 3.0.2-3 to 3.0.4-1 in August > of last year. I upgraded from 3.04 to 3.05 today. This is probably due to a dependency problem for libvarnishapi in the older packages. Make sure that you have the correct (same) version of all varnish packages installed on the system. -- With regards, Lasse Karstensen Varnish Software AS From raymond.jennings at nytimes.com Tue Feb 18 13:03:48 2014 From: raymond.jennings at nytimes.com (Raymond Jennings) Date: Tue, 18 Feb 2014 08:03:48 -0500 Subject: Varnish is functioning and caching but varnihstat show no hits In-Reply-To: <20140218102837.GD1962@immer.varnish-software.com> References: <52F27718.7010309@gmail.com> <20140218102837.GD1962@immer.varnish-software.com> Message-ID: <3008999004178264935@unknownmsgid> There is also a problem where your host name changes after Varnish starts. It's looking for the cache location based on the new host name instead if the old host name. Varnish stat and varnish history fail. This is a bug to me but Varnish thinks otherwise. If you are writing to a file based on host name you can easily keep track of what that host name was. This is a common problem on AWS ec2. > On Feb 18, 2014, at 6:20 AM, Lasse Karstensen wrote: > >> On Wed, Feb 05, 2014 at 12:38:32PM -0500, Matt Collier wrote: >> I am running varnish v. 3.05 on a debian server. I have had varnish >> running on this server for a long while now and I am not having any >> problems with the installation except: > [..] >> When I run varnishstat, my hit ratio is 0, and when I run >> varnishstat -1 it shows 0 client connections accepted. I can also >> add that the server uptime displayed in the upper left hand corner >> of varnishstat is does not appear to be incrementing properly. It's >> been sitting at 0+00:00:00 for the last hour. > [..] >> I can add that I upgraded varnish from 3.0.2-3 to 3.0.4-1 in August >> of last year. I upgraded from 3.04 to 3.05 today. > > This is probably due to a dependency problem for libvarnishapi in > the older packages. > > Make sure that you have the correct (same) version of all varnish packages > installed on the system. > > -- > With regards, > Lasse Karstensen > Varnish Software AS > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From hernan at cmsmedios.com Thu Feb 20 13:17:52 2014 From: hernan at cmsmedios.com (=?ISO-8859-1?Q?Hern=E1n_Marsili?=) Date: Thu, 20 Feb 2014 10:17:52 -0300 Subject: best varnish architecture for high concurrency site Message-ID: Hi, We are 'playing' with different architecture options to maximize the usage of Varnish Cache. We currently have 6000 concurrentes users and we are balancing over 4 servers. Each server has a Varnish, (4gb malloc) which consumes a local backend with Apache / Tomcat (another 4gb). Every box is a virtual machine with 8gb RAM and 4 vcpu. We build it that way because we need PERSISTENT CONNECTIONS to the backend on Varnish bypass. We have strong dynamic functionality. We think that having 1 big Varnish (dedicated use) and balance all the connections to the dedicated backends will serves us best. Basically, we will improve varnish caching, reduce the petitions to the database (now we have 4 servers asking the same to the DB) and will also reduce connections and resources on the backend servers. Questions: a) what do you think of each scenario? b) it is possible to balance connections persistently to the backend servers? Regards, Hern?n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at startupgiraffe.com Thu Feb 20 13:59:06 2014 From: john at startupgiraffe.com (John Cihocki) Date: Thu, 20 Feb 2014 08:59:06 -0500 Subject: best varnish architecture for high concurrency site In-Reply-To: References: Message-ID: How many concurrent client connections do those 6000 concurrent users generate? You'll need to make sure you have enough available worker threads to accommodate those users plus extra to soak up traffic spikes, ideally. a) One thing to consider with a single instance architecture is the lack of redundancy. If that host goes down, your site is down. b) Do you mean have persistent client connections to backend, like websockets? Or have varnish make backend requests through persistent connections. The former is possible, the latter is the default behavior as I understand it -- Varnish will always attempt to reuse an existing connection for the next backend request. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hernan at cmsmedios.com Thu Feb 20 14:10:39 2014 From: hernan at cmsmedios.com (=?ISO-8859-1?Q?Hern=E1n_Marsili?=) Date: Thu, 20 Feb 2014 11:10:39 -0300 Subject: best varnish architecture for high concurrency site In-Reply-To: References: Message-ID: Hi John, Thank you very much for you quick response. To be honest I don't have a measure right now of how many connections produces this 6000 concurrent users. I will measure it on the next rush hour. Currently, is distributed along 4 servers. On average, each servers has 1000 connections. a) we know that, we are think on an identical box to maybe balance it or have it as spare b) we need that each users are consistently served from the same backend server. If not, they will appear logged in on 1 server but not the others. Bottom line, do you think 1 Varnish balancing against 3 backends is best than having 4 varnish balancing 1 to 1 with a backend? Saludos, Hern?n. On Thu, Feb 20, 2014 at 10:58 AM, John Cihocki wrote: > >> How many concurrent client connections do those 6000 concurrent users >> generate? You'll need to make sure you have enough available worker threads >> to accommodate those users plus extra to soak up traffic spikes, ideally. >> >> a) One thing to consider with a single instance architecture is the lack >> of redundancy. If that host goes down, your site is down. >> b) Do you mean have persistent client connections to backend, like >> websockets? Or have varnish make backend requests through persistent >> connections. The former is possible, the latter is the default behavior as >> I understand it -- Varnish will always attempt to reuse an existing >> connection for the next backend request. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hernan at cmsmedios.com Mon Feb 24 19:35:40 2014 From: hernan at cmsmedios.com (=?ISO-8859-1?Q?Hern=E1n_Marsili?=) Date: Mon, 24 Feb 2014 16:35:40 -0300 Subject: help with logged in users VCL Message-ID: Hi, We are 'tuning' a VCL for an editorial site. We we need is basically to cache all images, css, js, fonts (for about 600 seconds and 7200 seconds depending on the directory) and HTML (for 60 seconds). When a user is logged in, we want to read a cookie named LOGD and DO NOT cache HTML and set the expires on 0. Also, we included some directories and URL we don't want to cache. We are getting an erratic behavior with the HTML caching. Sometime it works, sometimes it doesn't but we are we are getting MISS when we should be getting HITs. Or for example, we get a MISS, refresh and get a HIT. Close the browser, enter again and we get another MISS. Here is the VCL we built. http://paste.ubuntu.com/6990596/ Any help will be much appreciated. Regards, Hern?n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Tue Feb 25 16:31:34 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 25 Feb 2014 16:31:34 +0000 Subject: Issues restricting HTTP purges based on an ACL Message-ID: Hi all, I have joined this list hoping that someone can help me with an issue I have with restricting Varnish HTTP purges to a defined ACL of IPs. Our CDN provider use Varnish 2.x (not 3), so I've been following this tutorial on implementing restrictions on HTTP Purges: https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. The section that Varnish seems to trip up on is: if (req.request == "PURGE" ) { if (!client.ip ~ purge) { error 403 "Forbidden"; } return (lookup); } When trying to purge the cache via the API from an IP outside of the ACL, it is still accepted and purged. The second line of this block - if (!client.ip ~ purge) { - seems to be the logic that isn't accepted properly. I thought that including the bang outside of the brackets might fix the issue, but it doesn't. I've only used Varnish a few times beforehand, so would appreciate any assistance anyone can provide. Thanks in advance. Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From stef at scaleengine.com Tue Feb 25 16:58:28 2014 From: stef at scaleengine.com (Stefan Caunter) Date: Tue, 25 Feb 2014 11:58:28 -0500 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: It's not clear from your description, is there an acl defined called purge? Do logs show that the PURGE request actually came from the IP range you expect? ---- Stefan Caunter ScaleEngine Inc. E: stefan.caunter at scaleengine.com Skype: stefan.caunter Toll Free Direct: +1 800 280 6042 Toronto Canada On Tue, Feb 25, 2014 at 11:31 AM, Andrew Langhorn wrote: > Hi all, > > I have joined this list hoping that someone can help me with an issue I have > with restricting Varnish HTTP purges to a defined ACL of IPs. > > Our CDN provider use Varnish 2.x (not 3), so I've been following this > tutorial on implementing restrictions on HTTP Purges: > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. > > The section that Varnish seems to trip up on is: > > if (req.request == "PURGE" ) { > if (!client.ip ~ purge) { > error 403 "Forbidden"; > } > return (lookup); > } > > When trying to purge the cache via the API from an IP outside of the ACL, it > is still accepted and purged. The second line of this block - if (!client.ip > ~ purge) { - seems to be the logic that isn't accepted properly. I thought > that including the bang outside of the brackets might fix the issue, but it > doesn't. > > I've only used Varnish a few times beforehand, so would appreciate any > assistance anyone can provide. > > Thanks in advance. > > Kind regards, > > Andrew Langhorn > Web Operations > Government Digital Service > > e: andrew.langhorn at digital.cabinet-office.gov.uk > t: +44 (0)7810 737375 > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From japrice at gmail.com Tue Feb 25 17:02:15 2014 From: japrice at gmail.com (Jason Price) Date: Tue, 25 Feb 2014 12:02:15 -0500 Subject: Varnishlog -d -m XID: ? In-Reply-To: <20140218102431.GC1962@immer.varnish-software.com> References: <20140218102431.GC1962@immer.varnish-software.com> Message-ID: Is there a non-easy way to do it? --Jason ( <- not afraid of getting complicated ) On Tue, Feb 18, 2014 at 5:24 AM, Lasse Karstensen < lkarsten at varnish-software.com> wrote: > On Wed, Feb 05, 2014 at 12:48:47PM -0500, Jason Price wrote: > > How can I see the full varnishlog output for a given XID (assuming it > > hasn't expired from the shared memory log)? > > (ideally, it wouldn't use '-m' since it would require separate calls for > -c > > and -b...) > > You currently can't do that easily. > > In the upcoming 4.0 version this is simple to do though: > > https://www.varnish-cache.org/docs/trunk/reference/vsl-query.html > https://www.varnish-cache.org/docs/trunk/reference/varnishlog.html > > -- > With regards, > Lasse Karstensen > Varnish Software AS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Tue Feb 25 17:05:19 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 25 Feb 2014 17:05:19 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Hi Stefan, Yes - I have an ACL further up called purge: acl purge { "1.2.3.4"; "2.3.4.5"; "3.4.5.6"; "4.5.6.7"; } Of course, I've changed the IPs in the above example. The PURGE seems to be accepted by IPs which should be disallowed according to the ACL - for example, I can perform a HTTP PURGE from 8.9.10.11 or whatever. Thanks Andrew On 25 February 2014 16:58, Stefan Caunter wrote: > It's not clear from your description, is there an acl defined called purge? > > Do logs show that the PURGE request actually came from the IP range you > expect? > > ---- > > Stefan Caunter > ScaleEngine Inc. > > E: stefan.caunter at scaleengine.com > Skype: stefan.caunter > Toll Free Direct: +1 800 280 6042 > Toronto Canada > > > On Tue, Feb 25, 2014 at 11:31 AM, Andrew Langhorn > wrote: > > Hi all, > > > > I have joined this list hoping that someone can help me with an issue I > have > > with restricting Varnish HTTP purges to a defined ACL of IPs. > > > > Our CDN provider use Varnish 2.x (not 3), so I've been following this > > tutorial on implementing restrictions on HTTP Purges: > > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. > > > > The section that Varnish seems to trip up on is: > > > > if (req.request == "PURGE" ) { > > if (!client.ip ~ purge) { > > error 403 "Forbidden"; > > } > > return (lookup); > > } > > > > When trying to purge the cache via the API from an IP outside of the > ACL, it > > is still accepted and purged. The second line of this block - if > (!client.ip > > ~ purge) { - seems to be the logic that isn't accepted properly. I > thought > > that including the bang outside of the brackets might fix the issue, but > it > > doesn't. > > > > I've only used Varnish a few times beforehand, so would appreciate any > > assistance anyone can provide. > > > > Thanks in advance. > > > > Kind regards, > > > > Andrew Langhorn > > Web Operations > > Government Digital Service > > > > e: andrew.langhorn at digital.cabinet-office.gov.uk > > t: +44 (0)7810 737375 > > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi.boukelmoune at zenika.com Tue Feb 25 17:05:10 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Tue, 25 Feb 2014 18:05:10 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn wrote: > Hi all, > > I have joined this list hoping that someone can help me with an issue I have > with restricting Varnish HTTP purges to a defined ACL of IPs. > > Our CDN provider use Varnish 2.x (not 3), so I've been following this > tutorial on implementing restrictions on HTTP Purges: > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. Hi, If you issue an https request, the value of client.ip belongs to your ssl/tls endpoint, which may be allowed by your ACL. You should maybe rely on the X-Forwarded-For header instead (I believe you can trust the XFF header sent by your CDN provider). What do you see in varnishlog ? Best Regards, Dridi > The section that Varnish seems to trip up on is: > > if (req.request == "PURGE" ) { > if (!client.ip ~ purge) { > error 403 "Forbidden"; > } > return (lookup); > } > > When trying to purge the cache via the API from an IP outside of the ACL, it > is still accepted and purged. The second line of this block - if (!client.ip > ~ purge) { - seems to be the logic that isn't accepted properly. I thought > that including the bang outside of the brackets might fix the issue, but it > doesn't. > > I've only used Varnish a few times beforehand, so would appreciate any > assistance anyone can provide. > > Thanks in advance. > > Kind regards, > > Andrew Langhorn > Web Operations > Government Digital Service > > e: andrew.langhorn at digital.cabinet-office.gov.uk > t: +44 (0)7810 737375 > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From andrew.langhorn at digital.cabinet-office.gov.uk Tue Feb 25 17:32:23 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 25 Feb 2014 17:32:23 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Hi Dridi, Unfortunately, I see no references to the purge method being actioned in the varnishlog. I would have thought I would see it there, but it appears not. Perhaps this means the purge isn't being completed successfully? Andrew On 25 February 2014 17:05, Dridi Boukelmoune wrote: > On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn > wrote: > > Hi all, > > > > I have joined this list hoping that someone can help me with an issue I > have > > with restricting Varnish HTTP purges to a defined ACL of IPs. > > > > Our CDN provider use Varnish 2.x (not 3), so I've been following this > > tutorial on implementing restrictions on HTTP Purges: > > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. > > Hi, > > If you issue an https request, the value of client.ip belongs to your > ssl/tls endpoint, which may be allowed by your ACL. You should maybe > rely on the X-Forwarded-For header instead (I believe you can trust > the XFF header sent by your CDN provider). > > What do you see in varnishlog ? > > Best Regards, > Dridi > > > The section that Varnish seems to trip up on is: > > > > if (req.request == "PURGE" ) { > > if (!client.ip ~ purge) { > > error 403 "Forbidden"; > > } > > return (lookup); > > } > > > > When trying to purge the cache via the API from an IP outside of the > ACL, it > > is still accepted and purged. The second line of this block - if > (!client.ip > > ~ purge) { - seems to be the logic that isn't accepted properly. I > thought > > that including the bang outside of the brackets might fix the issue, but > it > > doesn't. > > > > I've only used Varnish a few times beforehand, so would appreciate any > > assistance anyone can provide. > > > > Thanks in advance. > > > > Kind regards, > > > > Andrew Langhorn > > Web Operations > > Government Digital Service > > > > e: andrew.langhorn at digital.cabinet-office.gov.uk > > t: +44 (0)7810 737375 > > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > > > > _______________________________________________ > > varnish-misc mailing list > > varnish-misc at varnish-cache.org > > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkarsten at varnish-software.com Wed Feb 26 10:28:58 2014 From: lkarsten at varnish-software.com (Lasse Karstensen) Date: Wed, 26 Feb 2014 11:28:58 +0100 Subject: help with logged in users VCL In-Reply-To: References: Message-ID: <20140226102857.GC8068@immer.varnish-software.com> On Mon, Feb 24, 2014 at 04:35:40PM -0300, Hern?n Marsili wrote: [..] > We are getting an erratic behavior with the HTML caching. Sometime it > works, sometimes it doesn't but we are we are getting MISS when we should > be getting HITs. Or for example, we get a MISS, refresh and get a HIT. > Close the browser, enter again and we get another MISS. > Here is the VCL we built. http://paste.ubuntu.com/6990596/ > Any help will be much appreciated. I can't really say that your VCL supports the problem you are describing. However, request pipelining/connection reuse and return(pipe) often does bite a bit, so I suggest you add this snippet and try again: sub vcl_pipe { set bereq.http.connection = "close"; } (and you can remove the Accept-Encoding section, Varnish does that internally in 3.0) -- With regards, Lasse Karstensen Varnish Software AS From dridi.boukelmoune at zenika.com Wed Feb 26 10:58:59 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Wed, 26 Feb 2014 11:58:59 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: On Tue, Feb 25, 2014 at 6:32 PM, Andrew Langhorn wrote: > Hi Dridi, > > Unfortunately, I see no references to the purge method being actioned in the > varnishlog. I would have thought I would see it there, but it appears not. > Perhaps this means the purge isn't being completed successfully? When in doubt, std.log :) https://www.varnish-cache.org/docs/3.0/reference/vmod_std.html#log > Andrew > > > On 25 February 2014 17:05, Dridi Boukelmoune > wrote: >> >> On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn >> wrote: >> > Hi all, >> > >> > I have joined this list hoping that someone can help me with an issue I >> > have >> > with restricting Varnish HTTP purges to a defined ACL of IPs. >> > >> > Our CDN provider use Varnish 2.x (not 3), so I've been following this >> > tutorial on implementing restrictions on HTTP Purges: >> > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html. >> >> Hi, >> >> If you issue an https request, the value of client.ip belongs to your >> ssl/tls endpoint, which may be allowed by your ACL. You should maybe >> rely on the X-Forwarded-For header instead (I believe you can trust >> the XFF header sent by your CDN provider). >> >> What do you see in varnishlog ? >> >> Best Regards, >> Dridi >> >> > The section that Varnish seems to trip up on is: >> > >> > if (req.request == "PURGE" ) { >> > if (!client.ip ~ purge) { >> > error 403 "Forbidden"; >> > } >> > return (lookup); >> > } >> > >> > When trying to purge the cache via the API from an IP outside of the >> > ACL, it >> > is still accepted and purged. The second line of this block - if >> > (!client.ip >> > ~ purge) { - seems to be the logic that isn't accepted properly. I >> > thought >> > that including the bang outside of the brackets might fix the issue, but >> > it >> > doesn't. >> > >> > I've only used Varnish a few times beforehand, so would appreciate any >> > assistance anyone can provide. >> > >> > Thanks in advance. >> > >> > Kind regards, >> > >> > Andrew Langhorn >> > Web Operations >> > Government Digital Service >> > >> > e: andrew.langhorn at digital.cabinet-office.gov.uk >> > t: +44 (0)7810 737375 >> > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH >> > >> > _______________________________________________ >> > varnish-misc mailing list >> > varnish-misc at varnish-cache.org >> > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > > > > > -- > Kind regards, > > Andrew Langhorn > Web Operations > Government Digital Service > > e: andrew.langhorn at digital.cabinet-office.gov.uk > t: +44 (0)7810 737375 > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH From hernan at cmsmedios.com Wed Feb 26 14:45:17 2014 From: hernan at cmsmedios.com (=?ISO-8859-1?Q?Hern=E1n_Marsili?=) Date: Wed, 26 Feb 2014 11:45:17 -0300 Subject: help with logged in users VCL In-Reply-To: <20140226102857.GC8068@immer.varnish-software.com> References: <20140226102857.GC8068@immer.varnish-software.com> Message-ID: Hi Lasse, thank you for your response. Excuse my ignorance but I don't quite understand where to put that or which is the line causing that. Could you please elaborate? Also, you meant I can delete this? #normalizar el accept encoding ("Vary") para evitar caching duplicado if (req.http.Accept-Encoding) { if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { # No point in compressing these remove req.http.Accept-Encoding; } elsif (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { # unkown algorithm remove req.http.Accept-Encoding; } } Saludos, Hern?n. [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o RSS feed o Twitter @tfsla >> Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 5350-1090 | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | Venezuela +58 212 335-1180 | Colombia +57 1 508-7840 On Wed, Feb 26, 2014 at 7:28 AM, Lasse Karstensen < lkarsten at varnish-software.com> wrote: > On Mon, Feb 24, 2014 at 04:35:40PM -0300, Hern?n Marsili wrote: > [..] > > We are getting an erratic behavior with the HTML caching. Sometime it > > works, sometimes it doesn't but we are we are getting MISS when we should > > be getting HITs. Or for example, we get a MISS, refresh and get a HIT. > > Close the browser, enter again and we get another MISS. > > Here is the VCL we built. http://paste.ubuntu.com/6990596/ > > Any help will be much appreciated. > > I can't really say that your VCL supports the problem you are describing. > > However, request pipelining/connection reuse and return(pipe) often does > bite > a bit, so I suggest you add this snippet and try again: > > sub vcl_pipe { > set bereq.http.connection = "close"; > } > > (and you can remove the Accept-Encoding section, Varnish does that > internally in 3.0) > > -- > With regards, > Lasse Karstensen > Varnish Software AS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.lecomte at virtual-expo.com Wed Feb 26 15:12:35 2014 From: thomas.lecomte at virtual-expo.com (Thomas Lecomte) Date: Wed, 26 Feb 2014 16:12:35 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: <20140226151235.GA32179@wks140.directindustry.com> On Tue, Feb 25, 2014 at 04:31:34PM +0000, Andrew Langhorn wrote: > The section that Varnish seems to trip up on is: > > if (req.request == "PURGE" ) { > if (!client.ip ~ purge) { > error 403 "Forbidden"; > } > return (lookup); > } > > When trying to purge the cache via the API from an IP outside of the ACL, > it is still accepted and purged. The second line of this block - if > (!client.ip ~ purge) { - seems to be the logic that isn't accepted > properly. I thought that including the bang outside of the brackets might > fix the issue, but it doesn't. Hello, Have you tried doing it the other way? i.e.: if (req.request == "PURGE" ) { if (client.ip ~ purge) { return (lookup); } error 403 "Forbidden"; } Regards, -- Thomas Lecomte / +33 4 86 13 48 65 Sysadmin / Virtual Expo / Marseille From perbu at varnish-software.com Wed Feb 26 15:33:26 2014 From: perbu at varnish-software.com (Per Buer) Date: Wed, 26 Feb 2014 16:33:26 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Hi, I see quite a lot of answers but for some reason noone has noticed the obvious error here. :-) On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn < andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > Hi all, > > > The section that Varnish seems to trip up on is: > > if (req.request == "PURGE" ) { > if (!client.ip ~ purge) { > error 403 "Forbidden"; > } > return (lookup); > } > What I'm guessing you are trying to say is if (client.ip !~ purge) { error 403 "Forbidden"; } "!client.ip" doesn't make sense in my book as client.ip isn't boolean. -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Wed Feb 26 15:39:52 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Wed, 26 Feb 2014 15:39:52 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Thanks Per. I'll give that a go. I was using a tutorial at https://www.varnish-cache.org/docs/2.1/tutorial/purging.html - maybe that needs to be updated if it's wrong? I'll let you all know how I get on. On 26 February 2014 15:33, Per Buer wrote: > Hi, > > I see quite a lot of answers but for some reason noone has noticed the > obvious error here. :-) > > On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn < > andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > >> Hi all, >> >> >> The section that Varnish seems to trip up on is: >> >> if (req.request == "PURGE" ) { >> if (!client.ip ~ purge) { >> error 403 "Forbidden"; >> } >> return (lookup); >> } >> > > What I'm guessing you are trying to say is > if (client.ip !~ purge) { > error 403 "Forbidden"; > } > > "!client.ip" doesn't make sense in my book as client.ip isn't boolean. > > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Wed Feb 26 15:46:25 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Wed, 26 Feb 2014 15:46:25 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: The VCC compiler doesn't like that syntax, I'm afraid, Per. Message from VCC-compiler: Invalid condition '!~' on IP number variable only '==', '!=' and '~' are legal (input Line 121 Pos 21) if (client.ip !~ purge) { --------------------##--------- Running VCC-compiler failed, exit 1VCL compilation failed On 26 February 2014 15:39, Andrew Langhorn < andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > Thanks Per. I'll give that a go. > I was using a tutorial at > https://www.varnish-cache.org/docs/2.1/tutorial/purging.html - maybe that > needs to be updated if it's wrong? > > I'll let you all know how I get on. > > > On 26 February 2014 15:33, Per Buer wrote: > >> Hi, >> >> I see quite a lot of answers but for some reason noone has noticed the >> obvious error here. :-) >> >> On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn < >> andrew.langhorn at digital.cabinet-office.gov.uk> wrote: >> >>> Hi all, >>> >>> >>> The section that Varnish seems to trip up on is: >>> >>> if (req.request == "PURGE" ) { >>> if (!client.ip ~ purge) { >>> error 403 "Forbidden"; >>> } >>> return (lookup); >>> } >>> >> >> What I'm guessing you are trying to say is >> if (client.ip !~ purge) { >> error 403 "Forbidden"; >> } >> >> "!client.ip" doesn't make sense in my book as client.ip isn't boolean. >> >> >> -- >> *Per Buer* >> CTO | Varnish Software >> Phone: +47 958 39 117 | Skype: per.buer >> We Make Websites Fly! >> >> Winner of the Red Herring Top 100 Global Award 2013 >> >> >> > > > -- > Kind regards, > > Andrew Langhorn > Web Operations > Government Digital Service > > e: andrew.langhorn at digital.cabinet-office.gov.uk > t: +44 (0)7810 737375 > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From perbu at varnish-software.com Wed Feb 26 15:57:32 2014 From: perbu at varnish-software.com (Per Buer) Date: Wed, 26 Feb 2014 16:57:32 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Hi, You're on 2.1. That ancient and I would not recommend running it. !~ was introduced in 3.0. Try the suggestion from Thomas if you must stay on 2.1. if (req.request == "PURGE" ) { if (client.ip ~ purge) { return (lookup); } error 403 "Forbidden"; } Per. On Wed, Feb 26, 2014 at 4:46 PM, Andrew Langhorn < andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > The VCC compiler doesn't like that syntax, I'm afraid, Per. > > > > Message from VCC-compiler: > Invalid condition '!~' on IP number variable > only '==', '!=' and '~' are legal > (input Line 121 Pos 21) > if (client.ip !~ purge) { > --------------------##--------- > Running VCC-compiler failed, exit 1VCL compilation failed > > > > On 26 February 2014 15:39, Andrew Langhorn < > andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > >> Thanks Per. I'll give that a go. >> I was using a tutorial at >> https://www.varnish-cache.org/docs/2.1/tutorial/purging.html - maybe >> that needs to be updated if it's wrong? >> >> I'll let you all know how I get on. >> >> >> On 26 February 2014 15:33, Per Buer wrote: >> >>> Hi, >>> >>> I see quite a lot of answers but for some reason noone has noticed the >>> obvious error here. :-) >>> >>> On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn < >>> andrew.langhorn at digital.cabinet-office.gov.uk> wrote: >>> >>>> Hi all, >>>> >>>> >>>> The section that Varnish seems to trip up on is: >>>> >>>> if (req.request == "PURGE" ) { >>>> if (!client.ip ~ purge) { >>>> error 403 "Forbidden"; >>>> } >>>> return (lookup); >>>> } >>>> >>> >>> What I'm guessing you are trying to say is >>> if (client.ip !~ purge) { >>> error 403 "Forbidden"; >>> } >>> >>> "!client.ip" doesn't make sense in my book as client.ip isn't boolean. >>> >>> >>> -- >>> *Per Buer* >>> CTO | Varnish Software >>> Phone: +47 958 39 117 | Skype: per.buer >>> We Make Websites Fly! >>> >>> Winner of the Red Herring Top 100 Global Award 2013 >>> >>> >>> >> >> >> -- >> Kind regards, >> >> Andrew Langhorn >> Web Operations >> Government Digital Service >> >> e: andrew.langhorn at digital.cabinet-office.gov.uk >> t: +44 (0)7810 737375 >> a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH >> > > > > -- > Kind regards, > > Andrew Langhorn > Web Operations > Government Digital Service > > e: andrew.langhorn at digital.cabinet-office.gov.uk > t: +44 (0)7810 737375 > a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH > -- *Per Buer* CTO | Varnish Software Phone: +47 958 39 117 | Skype: per.buer We Make Websites Fly! Winner of the Red Herring Top 100 Global Award 2013 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Wed Feb 26 16:13:22 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Wed, 26 Feb 2014 16:13:22 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: Hi Per, Yes - our CDN currently runs 2.1. I've tried Thomas' suggestion out, and I'm still able to purge from an IP I shouldn't be able to... Andrew On 26 February 2014 15:57, Per Buer wrote: > Hi, > > You're on 2.1. That ancient and I would not recommend running it. !~ was > introduced in 3.0. Try the suggestion from Thomas if you must stay on 2.1. > > > if (req.request == "PURGE" ) { > if (client.ip ~ purge) { > return (lookup); > } > error 403 "Forbidden"; > } > > Per. > > > On Wed, Feb 26, 2014 at 4:46 PM, Andrew Langhorn < > andrew.langhorn at digital.cabinet-office.gov.uk> wrote: > >> The VCC compiler doesn't like that syntax, I'm afraid, Per. >> >> >> >> >> Message from VCC-compiler: >> Invalid condition '!~' on IP number variable >> only '==', '!=' and '~' are legal >> (input Line 121 Pos 21) >> if (client.ip !~ purge) { >> --------------------##--------- >> Running VCC-compiler failed, exit 1VCL compilation failed >> >> >> >> On 26 February 2014 15:39, Andrew Langhorn < >> andrew.langhorn at digital.cabinet-office.gov.uk> wrote: >> >>> Thanks Per. I'll give that a go. >>> I was using a tutorial at >>> https://www.varnish-cache.org/docs/2.1/tutorial/purging.html - maybe >>> that needs to be updated if it's wrong? >>> >>> I'll let you all know how I get on. >>> >>> >>> On 26 February 2014 15:33, Per Buer wrote: >>> >>>> Hi, >>>> >>>> I see quite a lot of answers but for some reason noone has noticed the >>>> obvious error here. :-) >>>> >>>> On Tue, Feb 25, 2014 at 5:31 PM, Andrew Langhorn < >>>> andrew.langhorn at digital.cabinet-office.gov.uk> wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> The section that Varnish seems to trip up on is: >>>>> >>>>> if (req.request == "PURGE" ) { >>>>> if (!client.ip ~ purge) { >>>>> error 403 "Forbidden"; >>>>> } >>>>> return (lookup); >>>>> } >>>>> >>>> >>>> What I'm guessing you are trying to say is >>>> if (client.ip !~ purge) { >>>> error 403 "Forbidden"; >>>> } >>>> >>>> "!client.ip" doesn't make sense in my book as client.ip isn't boolean. >>>> >>>> >>>> -- >>>> *Per Buer* >>>> CTO | Varnish Software >>>> Phone: +47 958 39 117 | Skype: per.buer >>>> We Make Websites Fly! >>>> >>>> Winner of the Red Herring Top 100 Global Award 2013 >>>> >>>> >>>> >>> >>> >>> -- >>> Kind regards, >>> >>> Andrew Langhorn >>> Web Operations >>> Government Digital Service >>> >>> e: andrew.langhorn at digital.cabinet-office.gov.uk >>> t: +44 (0)7810 737375 >>> a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH >>> >> >> >> >> -- >> Kind regards, >> >> Andrew Langhorn >> Web Operations >> Government Digital Service >> >> e: andrew.langhorn at digital.cabinet-office.gov.uk >> t: +44 (0)7810 737375 >> a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH >> > > > > -- > *Per Buer* > CTO | Varnish Software > Phone: +47 958 39 117 | Skype: per.buer > We Make Websites Fly! > > Winner of the Red Herring Top 100 Global Award 2013 > > > -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi.boukelmoune at zenika.com Wed Feb 26 16:47:50 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Wed, 26 Feb 2014 17:47:50 +0100 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: On Wed, Feb 26, 2014 at 5:13 PM, Andrew Langhorn wrote: > > Hi Per, > > Yes - our CDN currently runs 2.1. I've tried Thomas' suggestion out, and I'm still able to purge from an IP I shouldn't be able to... I can't help you with varnish 2.1, and obviously there is no standard vmod before 3.0, and no custom logging (unless maybe with inline C)... You can get the client.ip, http method, and request headers for each request, can't you ? Dridi > Andrew From andrew.langhorn at digital.cabinet-office.gov.uk Wed Feb 26 17:19:17 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Wed, 26 Feb 2014 17:19:17 +0000 Subject: Issues restricting HTTP purges based on an ACL In-Reply-To: References: Message-ID: On 26 February 2014 16:47, Dridi Boukelmoune wrote: > On Wed, Feb 26, 2014 at 5:13 PM, Andrew Langhorn > wrote: > > > > Hi Per, > > > > Yes - our CDN currently runs 2.1. I've tried Thomas' suggestion out, and > I'm still able to purge from an IP I shouldn't be able to... > > I can't help you with varnish 2.1, and obviously there is no standard > vmod before 3.0, and no custom logging (unless maybe with inline C)... > > I hope that we'll be able to upgrade to Varnish 3 in the near future - until then, I'm afraid I'm still stuck with 2.1. > You can get the client.ip, http method, and request headers for each request, can't you ? > Yes, we appear to be able to - using the client IP works fine elsewhere in our VCL. I'll see what else our vendor's support can come up with. -- Kind regards, Andrew Langhorn Web Operations Government Digital Service e: andrew.langhorn at digital.cabinet-office.gov.uk t: +44 (0)7810 737375 a: 6th Floor, Aviation House, 125 Kingsway, London, WC2B 6NH -------------- next part -------------- An HTML attachment was scrubbed... URL: From tousif1988 at gmail.com Thu Feb 27 03:41:00 2014 From: tousif1988 at gmail.com (tousif baig) Date: Thu, 27 Feb 2014 09:11:00 +0530 Subject: help with logged in users VCL In-Reply-To: References: <20140226102857.GC8068@immer.varnish-software.com> Message-ID: You need to add the function said by Lasse Karstensen in your vcl at the end. And no, he did not mean to delete that code. Just add the code he said to your vcl to optimize varnish pipe usage. On Wed, Feb 26, 2014 at 8:15 PM, Hern?n Marsili wrote: > Hi Lasse, thank you for your response. Excuse my ignorance but I don't > quite understand where to put that or which is the line causing that. Could > you please elaborate? > > Also, you meant I can delete this? > > #normalizar el accept encoding ("Vary") para evitar caching duplicado > if (req.http.Accept-Encoding) { > if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { > # No point in compressing these > remove req.http.Accept-Encoding; > } elsif (req.http.Accept-Encoding ~ "gzip") { > set req.http.Accept-Encoding = "gzip"; > } elsif (req.http.Accept-Encoding ~ "deflate") { > set req.http.Accept-Encoding = "deflate"; > } else { > # unkown algorithm > remove req.http.Accept-Encoding; > } > } > > > Saludos, > Hern?n. > > [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | > facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin > ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o > RSS feed o Twitter @tfsla >> > Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 5350-1090 > | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | Venezuela +58 212 > 335-1180 | Colombia +57 1 508-7840 > > > > On Wed, Feb 26, 2014 at 7:28 AM, Lasse Karstensen < > lkarsten at varnish-software.com> wrote: > >> On Mon, Feb 24, 2014 at 04:35:40PM -0300, Hern?n Marsili wrote: >> [..] >> > We are getting an erratic behavior with the HTML caching. Sometime it >> > works, sometimes it doesn't but we are we are getting MISS when we >> should >> > be getting HITs. Or for example, we get a MISS, refresh and get a HIT. >> > Close the browser, enter again and we get another MISS. >> > Here is the VCL we built. http://paste.ubuntu.com/6990596/ >> > Any help will be much appreciated. >> >> I can't really say that your VCL supports the problem you are describing. >> >> However, request pipelining/connection reuse and return(pipe) often does >> bite >> a bit, so I suggest you add this snippet and try again: >> >> sub vcl_pipe { >> set bereq.http.connection = "close"; >> } >> >> (and you can remove the Accept-Encoding section, Varnish does that >> internally in 3.0) >> >> -- >> With regards, >> Lasse Karstensen >> Varnish Software AS >> > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hernan at cmsmedios.com Thu Feb 27 03:43:40 2014 From: hernan at cmsmedios.com (=?ISO-8859-1?Q?Hern=E1n_Marsili?=) Date: Thu, 27 Feb 2014 00:43:40 -0300 Subject: help with logged in users VCL In-Reply-To: References: <20140226102857.GC8068@immer.varnish-software.com> Message-ID: Hi Tousif, On Lasse email, the final note is: (and you can remove the Accept-Encoding section, Varnish does that internally in 3.0) Are you sure he meant otherwise? Saludos, Hern?n. [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o RSS feed o Twitter @tfsla >> Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 5350-1090 | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | Venezuela +58 212 335-1180 | Colombia +57 1 508-7840 On Thu, Feb 27, 2014 at 12:41 AM, tousif baig wrote: > You need to add the function said by Lasse Karstensen in your vcl at the > end. > > And no, he did not mean to delete that code. Just add the code he said to > your vcl to optimize varnish pipe usage. > > > On Wed, Feb 26, 2014 at 8:15 PM, Hern?n Marsili wrote: > >> Hi Lasse, thank you for your response. Excuse my ignorance but I don't >> quite understand where to put that or which is the line causing that. Could >> you please elaborate? >> >> Also, you meant I can delete this? >> >> #normalizar el accept encoding ("Vary") para evitar caching duplicado >> if (req.http.Accept-Encoding) { >> if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { >> # No point in compressing these >> remove req.http.Accept-Encoding; >> } elsif (req.http.Accept-Encoding ~ "gzip") { >> set req.http.Accept-Encoding = "gzip"; >> } elsif (req.http.Accept-Encoding ~ "deflate") { >> set req.http.Accept-Encoding = "deflate"; >> } else { >> # unkown algorithm >> remove req.http.Accept-Encoding; >> } >> } >> >> >> Saludos, >> Hern?n. >> >> [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | >> facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin >> ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o >> RSS feed o Twitter @tfsla >> >> Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 >> 5350-1090 | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | >> Venezuela +58 212 335-1180 | Colombia +57 1 508-7840 >> >> >> >> On Wed, Feb 26, 2014 at 7:28 AM, Lasse Karstensen < >> lkarsten at varnish-software.com> wrote: >> >>> On Mon, Feb 24, 2014 at 04:35:40PM -0300, Hern?n Marsili wrote: >>> [..] >>> > We are getting an erratic behavior with the HTML caching. Sometime it >>> > works, sometimes it doesn't but we are we are getting MISS when we >>> should >>> > be getting HITs. Or for example, we get a MISS, refresh and get a HIT. >>> > Close the browser, enter again and we get another MISS. >>> > Here is the VCL we built. http://paste.ubuntu.com/6990596/ >>> > Any help will be much appreciated. >>> >>> I can't really say that your VCL supports the problem you are describing. >>> >>> However, request pipelining/connection reuse and return(pipe) often does >>> bite >>> a bit, so I suggest you add this snippet and try again: >>> >>> sub vcl_pipe { >>> set bereq.http.connection = "close"; >>> } >>> >>> (and you can remove the Accept-Encoding section, Varnish does that >>> internally in 3.0) >>> >>> -- >>> With regards, >>> Lasse Karstensen >>> Varnish Software AS >>> >> >> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at varnish-cache.org >> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tousif1988 at gmail.com Thu Feb 27 06:16:33 2014 From: tousif1988 at gmail.com (tousif baig) Date: Thu, 27 Feb 2014 11:46:33 +0530 Subject: help with logged in users VCL In-Reply-To: References: <20140226102857.GC8068@immer.varnish-software.com> Message-ID: yup, just saw that. My bad. Yes you need to remove the Accept-Encoding section. Which means you can remove tht whole part of the code. On Thu, Feb 27, 2014 at 9:13 AM, Hern?n Marsili wrote: > Hi Tousif, > > On Lasse email, the final note is: (and you can remove the > Accept-Encoding section, Varnish does that internally in 3.0) > > Are you sure he meant otherwise? > > Saludos, > Hern?n. > > [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | > facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin > ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o > RSS feed o Twitter @tfsla >> > Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 5350-1090 > | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | Venezuela +58 212 > 335-1180 | Colombia +57 1 508-7840 > > > > On Thu, Feb 27, 2014 at 12:41 AM, tousif baig wrote: > >> You need to add the function said by Lasse Karstensen in your vcl at the >> end. >> >> And no, he did not mean to delete that code. Just add the code he said to >> your vcl to optimize varnish pipe usage. >> >> >> On Wed, Feb 26, 2014 at 8:15 PM, Hern?n Marsili wrote: >> >>> Hi Lasse, thank you for your response. Excuse my ignorance but I don't >>> quite understand where to put that or which is the line causing that. Could >>> you please elaborate? >>> >>> Also, you meant I can delete this? >>> >>> #normalizar el accept encoding ("Vary") para evitar caching duplicado >>> if (req.http.Accept-Encoding) { >>> if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") { >>> # No point in compressing these >>> remove req.http.Accept-Encoding; >>> } elsif (req.http.Accept-Encoding ~ "gzip") { >>> set req.http.Accept-Encoding = "gzip"; >>> } elsif (req.http.Accept-Encoding ~ "deflate") { >>> set req.http.Accept-Encoding = "deflate"; >>> } else { >>> # unkown algorithm >>> remove req.http.Accept-Encoding; >>> } >>> } >>> >>> >>> Saludos, >>> Hern?n. >>> >>> [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | >>> facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | >>> Linkedin ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por >>> e-mail o RSS feed o Twitter @tfsla >> >>> Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 >>> 5350-1090 | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | >>> Venezuela +58 212 335-1180 | Colombia +57 1 508-7840 >>> >>> >>> >>> On Wed, Feb 26, 2014 at 7:28 AM, Lasse Karstensen < >>> lkarsten at varnish-software.com> wrote: >>> >>>> On Mon, Feb 24, 2014 at 04:35:40PM -0300, Hern?n Marsili wrote: >>>> [..] >>>> > We are getting an erratic behavior with the HTML caching. Sometime it >>>> > works, sometimes it doesn't but we are we are getting MISS when we >>>> should >>>> > be getting HITs. Or for example, we get a MISS, refresh and get a HIT. >>>> > Close the browser, enter again and we get another MISS. >>>> > Here is the VCL we built. http://paste.ubuntu.com/6990596/ >>>> > Any help will be much appreciated. >>>> >>>> I can't really say that your VCL supports the problem you are >>>> describing. >>>> >>>> However, request pipelining/connection reuse and return(pipe) often >>>> does bite >>>> a bit, so I suggest you add this snippet and try again: >>>> >>>> sub vcl_pipe { >>>> set bereq.http.connection = "close"; >>>> } >>>> >>>> (and you can remove the Accept-Encoding section, Varnish does that >>>> internally in 3.0) >>>> >>>> -- >>>> With regards, >>>> Lasse Karstensen >>>> Varnish Software AS >>>> >>> >>> >>> _______________________________________________ >>> varnish-misc mailing list >>> varnish-misc at varnish-cache.org >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: