From phk at phk.freebsd.dk Fri Jan 1 11:26:37 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 01 Jan 2010 11:26:37 +0000 Subject: varnishtest In-Reply-To: Your message of "Thu, 31 Dec 2009 15:47:15 +0800." <4B3C5703.8020002@gmail.com> Message-ID: <61376.1262345197@critter.freebsd.dk> In message <4B3C5703.8020002 at gmail.com>, ll writes: >Is there any manual about the command varnishtest ? I useing varnish >2.0.4 edition . very little. The best docs is the testcases in the tests subdirectory. -- 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 info at makeityourway.de Fri Jan 1 13:28:19 2010 From: info at makeityourway.de (Mike Schiessl) Date: Fri, 1 Jan 2010 14:28:19 +0100 Subject: bind Varnish to IP Adress (Outgoing) Message-ID: <00d701ca8ae6$48c39990$da4accb0$@de> Hi List, is there a way to bind varnish to an ip for outgoing requests ? I have a server with multiple ip addresses and varnish is using the default eth0 address, not the one I bound with the -a hook (eth0:5). Thanks for your replys Mike From phk at phk.freebsd.dk Fri Jan 1 20:17:27 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 01 Jan 2010 20:17:27 +0000 Subject: bind Varnish to IP Adress (Outgoing) In-Reply-To: Your message of "Fri, 01 Jan 2010 14:28:19 +0100." <00d701ca8ae6$48c39990$da4accb0$@de> Message-ID: <64470.1262377047@critter.freebsd.dk> In message <00d701ca8ae6$48c39990$da4accb0$@de>, "Mike Schiessl" writes: >Hi List, > >is there a way to bind varnish to an ip for outgoing requests ? Not right now, but it shouldn't be too hard to add. I have added it to our "shopping list": http://varnish.projects.linpro.no/wiki/PostTwoShoppingList -- 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 info at makeityourway.de Sat Jan 2 08:23:55 2010 From: info at makeityourway.de (Mike Schiessl) Date: Sat, 2 Jan 2010 09:23:55 +0100 Subject: bind Varnish to IP Adress (Outgoing) Message-ID: <00e801ca8b84$ed346ba0$c79d42e0$@de> >From the shopping list: > Does this make sense ? Routing is based on the routes, and the outgoing address should be the one >that matches the route interface ? Well in my opinion it does make sense, at the time you start playing with multiple ips on the varnish host. Varnish always will use the ip from the main iface, not the ip I want varnish to use. If you are using firewalls it could be very useful to care only about one ip ;) Regards Mike Schiessl -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb+varnish at slide.com Sun Jan 3 04:02:20 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Sat, 2 Jan 2010 20:02:20 -0800 Subject: bind Varnish to IP Adress (Outgoing) In-Reply-To: <00e801ca8b84$ed346ba0$c79d42e0$@de> References: <00e801ca8b84$ed346ba0$c79d42e0$@de> Message-ID: <0DB7E581-1033-45F0-8F34-AE2C2C35CE12@slide.com> As a workaround, on Linux (at least) you could emulate this with an iptables SNAT rule, but it does have less performance potential. -- Ken On Jan 2, 2010, at 12:23 AM, Mike Schiessl wrote: > >From the shopping list: > > Does this make sense ? Routing is based on the routes, and the outgoing address should be the one >that matches the route interface ? > > > Well in my opinion it does make sense, at the time you start playing with multiple ips on the varnish host. > Varnish always will use the ip from the main iface, not the ip I want varnish to use. If you are using firewalls it could be very useful to care only about one ip ;) > > > Regards > Mike Schiessl > > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at redpill-linpro.com Mon Jan 4 09:36:59 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 04 Jan 2010 10:36:59 +0100 Subject: Varnish 503 Service unavailable error In-Reply-To: <75cf5800912170417k19b6bccpb2c02fc640260834@mail.gmail.com> (Paras Fadte's message of "Thu, 17 Dec 2009 17:47:06 +0530") References: <75cf5800908130119o5b10f41bn85e7d76fcb7ebc96@mail.gmail.com> <87fxbw5atk.fsf@qurzaw.linpro.no> <75cf5800908130243k3c0e7db6i2d01788a42ab352e@mail.gmail.com> <87k4z61gvj.fsf@qurzaw.linpro.no> <75cf5800911110400h32542eek30946320ae108d8e@mail.gmail.com> <877htwdpex.fsf@qurzaw.linpro.no> <75cf5800911262046p6a5b286awf9b563065d5aaab9@mail.gmail.com> <87fx80xqop.fsf@qurzaw.linpro.no> <75cf5800912170417k19b6bccpb2c02fc640260834@mail.gmail.com> Message-ID: <87ljge43es.fsf@qurzaw.linpro.no> ]] Paras Fadte | Sometimes I see following when using varnishlog | | *Interrupted b BackendOpen* | | What does it mean and under what condition(s) does it occur ? >From the varnishlog source code: /* This is the start of a new request, yet we haven't seen the end of the previous one. Spit it out anyway before starting on the new one. */ -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 4 09:42:53 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 04 Jan 2010 10:42:53 +0100 Subject: Connection issues on Solaris 10 (Accept failed: Bad file number) In-Reply-To: (Jim Hayter's message of "Fri, 18 Dec 2009 13:27:07 -0500") References: Message-ID: <87hbr2434y.fsf@qurzaw.linpro.no> ]] "Jim Hayter" | I've tried running both 2.0.5 and 2.0.6 on a Sun intel box running | Solaris 10. | | Varnish works for a while and then starts generating log output like the | examples below, reporting nothing but " Accept failed: Bad file number". | I raised the process file descriptor limit, but that did not help. | | Is anyone using Varnish 2.0.x on a Sun intel box running Solaris 10? If | so, do you have any suggestions? Can you try some of the suggestions on http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ ? If they help, please tell us so we can try to find out what's wrong with the ports implementation. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 4 09:48:11 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 04 Jan 2010 10:48:11 +0100 Subject: Unconditional GETs and 304 from backend servers In-Reply-To: <95ff419c0912230250j401d314dwe33def2826e9d1b3@mail.gmail.com> (Daniel Rodriguez's message of "Wed, 23 Dec 2009 11:50:02 +0100") References: <95ff419c0912230250j401d314dwe33def2826e9d1b3@mail.gmail.com> Message-ID: <87d41q42w4.fsf@qurzaw.linpro.no> ]] Daniel Rodriguez | The problem that we are currently having is that varnish will only ask | unconditional GETs, so every time that varnish ask the web server for | one of this objects after the age have expired (expecting a 200 and a | full refresh) our servers have to recreate the whole objects (some of | them taking a lot of CPU and time) even if this is not needed (in | normal conditions with conditional GET they will reply 304 with less | CPU usage). | | There is a possible solution to this ? maybe a workaround using VCL ? Varnish doesn't do conditional GETs, but you could switch the system around and do active cache management where you set the TTL of objects to infinity (well, 2 years or something other, high) and let the backend use purge to remove objects that should be evicted. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 4 09:56:08 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 04 Jan 2010 10:56:08 +0100 Subject: can backend trigger pipe? In-Reply-To: <1261959661.7567.1152.camel@totiki> (Gaute Amundsen's message of "Mon, 28 Dec 2009 01:21:01 +0100") References: <1261959661.7567.1152.camel@totiki> Message-ID: <878wce42iv.fsf@qurzaw.linpro.no> ]] Gaute Amundsen | Is there any other way to handle this than to hardcode "pipe" for those | urls in vcl_recv? In 2.0.x, there's no way to do this, other than hardcoding the list of URLs (or a prefix or suffix match, of course). In 2.1, vcl_fetch will be run after the headers have been received and while it's not currently possible to pipe at that point, I don't see why we couldn't add that capability. | Any way for the script to return a header that can tell vcl_fetch to | pipe? Or is that too late? You could use ugly workarounds like having the script send back a X-Please-Pipe: yes and close the connection and then restart in vcl_fetch after setting a req.http.x-pipe = ?yes?. | Am I right to assume that "pass" is not intended to work in a case like | this? Correct. At least not yet. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 4 09:58:12 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 04 Jan 2010 10:58:12 +0100 Subject: varnishtest In-Reply-To: <4B3C5703.8020002@gmail.com> (ll's message of "Thu, 31 Dec 2009 15:47:15 +0800") References: <4B3C5703.8020002@gmail.com> Message-ID: <874on242ff.fsf@qurzaw.linpro.no> ]] ll | Is there any manual about the command varnishtest ? I useing varnish | 2.0.4 edition . | and I want to have a script to test the backend whether the backend | server is normal .I know the varnish can test it ,and configure some | thing to change the backend when it test is failed.so I want to test it | and send a mail or some other log can be trace . It sounds more like you are looking for a monitoring solution like nagios than varnishtest. Varnishtest is used for testing that varnish works correctly and prevent regressions. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From rtshilston at gmail.com Mon Jan 4 13:47:17 2010 From: rtshilston at gmail.com (Rob S) Date: Mon, 04 Jan 2010 13:47:17 +0000 Subject: varnishtest In-Reply-To: <874on242ff.fsf@qurzaw.linpro.no> References: <4B3C5703.8020002@gmail.com> <874on242ff.fsf@qurzaw.linpro.no> Message-ID: <4B41F165.4000405@gmail.com> Tollef Fog Heen wrote: > ]] ll > > | Is there any manual about the command varnishtest ? I useing varnish > | 2.0.4 edition . > | and I want to have a script to test the backend whether the backend > | server is normal .I know the varnish can test it ,and configure some > | thing to change the backend when it test is failed.so I want to test it > | and send a mail or some other log can be trace . > > It sounds more like you are looking for a monitoring solution like > nagios than varnishtest. Varnishtest is used for testing that varnish > works correctly and prevent regressions. > > You might want to look at earlier discussions about automatically monitoring the health of backends. This was on the mailing list a few months ago - see http://www.mail-archive.com/varnish-misc at projects.linpro.no/msg03169.html Rob From jhayter at manta.com Tue Jan 5 16:33:09 2010 From: jhayter at manta.com (Jim Hayter) Date: Tue, 5 Jan 2010 11:33:09 -0500 Subject: Connection issues on Solaris 10 (Accept failed: Bad file number) In-Reply-To: <87hbr2434y.fsf@qurzaw.linpro.no> References: <87hbr2434y.fsf@qurzaw.linpro.no> Message-ID: Thanks for the link (http://letsgetdugg.com/2009/12/04/varnish-on-solaris/). Following the points there: 1) I am running 2.0.6, which either has or I had already made the edit for ticket 547. 2) I set connect_timeout to 0 and turned off keep alive in apache. 3) Starting varnishd with "-p waiter=poll" did not work for me (waiter not recognized), so I rebuilt Varnish using ./configure --disable-kqueue --disable-epoll --disable-ports 4) FYI, varnishd will not run in the background for me, it always fails to start the child process. It works running with the -F flag. One note about http://letsgetdugg.com/2009/12/04/varnish-on-solaris/, where it refers to /etc/projects, it should be /etc/project (not plural). At this point it appears to be working fine. I left a test running overnight and it is still going. The previous tests I did all dumped core long before this amount of time. Thank you very much for your help and the link. I had gone on to look at using Apache2 as a caching front end to Apache1 but I believe that Varnish will be the preferred solution. Jim -----Original Message----- From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Tollef Fog Heen Sent: Monday, January 04, 2010 4:43 AM To: varnish-misc at projects.linpro.no Subject: Re: Connection issues on Solaris 10 (Accept failed: Bad file number) ]] "Jim Hayter" | I've tried running both 2.0.5 and 2.0.6 on a Sun intel box running | Solaris 10. | | Varnish works for a while and then starts generating log output like the | examples below, reporting nothing but " Accept failed: Bad file number". | I raised the process file descriptor limit, but that did not help. | | Is anyone using Varnish 2.0.x on a Sun intel box running Solaris 10? If | so, do you have any suggestions? Can you try some of the suggestions on http://letsgetdugg.com/2009/12/04/varnish-on-solaris/ ? If they help, please tell us so we can try to find out what's wrong with the ports implementation. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From jhayter at manta.com Tue Jan 5 21:06:44 2010 From: jhayter at manta.com (Jim Hayter) Date: Tue, 5 Jan 2010 16:06:44 -0500 Subject: LostHeader when dealing with RxHeaders Message-ID: Varnish 2.0.6 - I have a page that is giving me 503 responses. It appears that this page sets an excessive number of cookies. In the logs I see: 6 RxProtocol b HTTP/1.1 6 RxStatus b 200 6 RxResponse b OK 6 RxHeader b Date: Tue, 05 Jan 2010 21:00:31 GMT 6 RxHeader b Server: Apache 6 RxHeader b Set-Cookie: =; path=/ ... 6 RxHeader b Set-Cookie: =; domain=; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 RxHeader b Set-Cookie: =; domain=; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 LostHeader b Set-Cookie: =; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 HttpGarbage b HTTP/1.1 29 FetchError c http format error I've tried changing the workspace size. It doesn't seem to have any effect. Is there a way to deal with this? I know that I need to talk to the application programmers about the number of cookies, but don't hold out much hope for immediate change. Thanks, Jim From jhayter at manta.com Tue Jan 5 22:03:11 2010 From: jhayter at manta.com (Jim Hayter) Date: Tue, 5 Jan 2010 17:03:11 -0500 Subject: LostHeader when dealing with RxHeaders In-Reply-To: References: Message-ID: I found ticket 455 and increased the HTTP_HDR_MAX_VAL in configure. On another item, the man pages for Varnish do not render correctly on my system. It looks as if anywhere there should be something in bold, or italics, etc that the text is missing. Any thoughts on what I need to do to see the man pages? Thanks, Jim -----Original Message----- From: Jim Hayter Sent: Tuesday, January 05, 2010 4:07 PM To: varnish-misc at projects.linpro.no Subject: LostHeader when dealing with RxHeaders Varnish 2.0.6 - I have a page that is giving me 503 responses. It appears that this page sets an excessive number of cookies. In the logs I see: 6 RxProtocol b HTTP/1.1 6 RxStatus b 200 6 RxResponse b OK 6 RxHeader b Date: Tue, 05 Jan 2010 21:00:31 GMT 6 RxHeader b Server: Apache 6 RxHeader b Set-Cookie: =; path=/ ... 6 RxHeader b Set-Cookie: =; domain=; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 RxHeader b Set-Cookie: =; domain=; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 LostHeader b Set-Cookie: =; path=/; expires=Thur, 01 Jan 1970 00:00:00 GMT 6 HttpGarbage b HTTP/1.1 29 FetchError c http format error I've tried changing the workspace size. It doesn't seem to have any effect. Is there a way to deal with this? I know that I need to talk to the application programmers about the number of cookies, but don't hold out much hope for immediate change. Thanks, Jim From jeremy at hinegardner.org Wed Jan 6 02:05:47 2010 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Tue, 5 Jan 2010 19:05:47 -0700 Subject: varnish child failing to be restarted Message-ID: <20100106020547.GD11017@hinegardner.org> Hi, We have an issue with varnish 2.0.6 (and it appeared in 2.0.4 also) where there is an error starting the child process. In this case the child is dead and the parent does not auto restart it. In our system, the child process dies a dozen or more times a day and the parent restarts the child. On occasion, the child does not restart correctly. Here is a snippet of the log: Jan 3 08:27:05 fs6 varnishd[8548]: child (6114) Started Jan 3 08:27:05 fs6 varnishd[8548]: Child (6114) said Closed fds: 4 5 6 10 11 13 14 Jan 3 08:27:05 fs6 varnishd[8548]: Child (6114) said Child starts Jan 3 08:27:05 fs6 varnishd[8548]: Child (6114) said managed to mmap 4294967296 bytes of 4294967296 Jan 3 08:27:05 fs6 varnishd[8548]: Child (6114) said Ready Jan 3 16:51:32 fs6 varnishd[8548]: Child (6114) not responding to ping, killing it. Jan 3 16:51:35 fs6 varnishd[8548]: Child (6114) died signal=3 Jan 3 16:51:35 fs6 varnishd[8548]: child (5494) Started Jan 3 16:51:35 fs6 varnishd[8548]: Child (5494) said Closed fds: 4 5 6 10 11 13 14 Jan 3 16:51:35 fs6 varnishd[8548]: Child (5494) said Child starts Jan 3 16:51:35 fs6 varnishd[8548]: Child (5494) said managed to mmap 4294967296 bytes of 4294967296 Jan 3 16:51:35 fs6 varnishd[8548]: Child (5494) said Ready Jan 3 18:50:44 fs6 varnishd[8548]: Child (5494) not responding to ping, killing it. Jan 3 18:50:59 fs6 varnishd[8548]: Child (5494) not responding to ping, killing it. Jan 3 18:50:59 fs6 varnishd[8548]: Child (5494) died signal=3 Jan 3 18:51:07 fs6 varnishd[8548]: child (14404) Started Jan 3 18:51:10 fs6 varnishd[8548]: Pushing vcls failed: CLI communication error Jan 3 18:51:10 fs6 varnishd[8548]: Child (14404) said Closed fds: 4 5 6 10 11 13 14 Jan 3 18:51:10 fs6 varnishd[8548]: Child (14404) said Child starts Jan 3 18:51:10 fs6 varnishd[8548]: Child (14404) said managed to mmap 4294967296 bytes of 4294967296 Jan 3 18:51:10 fs6 varnishd[8548]: Child (14404) said Ready Jan 3 18:51:10 fs6 varnishd[8548]: Child (14404) ended Jan 3 18:55:26 fs6 varnishd[8548]: Manager got SIGINT The SIGINT here is when our nagios page went off and I logged in and did a restart on varnish. I'm wondering if there are two issues here. The first being, why does our child process die many times during the day, and the 2nd being, why does the restarting of the child fail sometimes. In our case, the failure to restart the child is always when the "Pushing vcls failed" error appears in the log. I'll be happy to provide whatever other information may be required to help figure this out. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From tfheen at redpill-linpro.com Wed Jan 6 07:31:52 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 06 Jan 2010 08:31:52 +0100 Subject: LostHeader when dealing with RxHeaders In-Reply-To: (Jim Hayter's message of "Tue, 5 Jan 2010 17:03:11 -0500") References: Message-ID: <87bph71yfr.fsf@qurzaw.linpro.no> ]] "Jim Hayter" | I found ticket 455 and increased the HTTP_HDR_MAX_VAL in configure. I think we might want to increase the default somewhat here; you're not the first to run into this problem. | On another item, the man pages for Varnish do not render correctly on my | system. It looks as if anywhere there should be something in bold, or | italics, etc that the text is missing. Any thoughts on what I need to | do to see the man pages? Sounds like man is confused. Does other man pages with bold and italics work correctly? What OS are you on? Cheers, -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 6 07:37:02 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 06 Jan 2010 08:37:02 +0100 Subject: varnish child failing to be restarted In-Reply-To: <20100106020547.GD11017@hinegardner.org> (Jeremy Hinegardner's message of "Tue, 5 Jan 2010 19:05:47 -0700") References: <20100106020547.GD11017@hinegardner.org> Message-ID: <877hrv1y75.fsf@qurzaw.linpro.no> ]] Jeremy Hinegardner | I'm wondering if there are two issues here. The first being, why does | our child process die many times during the day, and the 2nd being, why | does the restarting of the child fail sometimes. It seems to be killed by the management process. If the box is otherwise healthy when this happens, try increasing cli_timeout. If it's quite loaded, I would suggest doing the regular performance tuning such as putting the shmlog on a tmpfs and making sure your working set fits in RAM (or use SSDs). | In our case, the failure to restart the child is always when the | "Pushing vcls failed" error appears in the log. This is an independent bug. I _think_ it is timing-related after a child is killed, but I'm not exactly sure. Cheers, -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From phk at phk.freebsd.dk Wed Jan 6 11:46:07 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 06 Jan 2010 11:46:07 +0000 Subject: Architectural heads-up/call for comments Message-ID: <5877.1262778367@critter.freebsd.dk> This email is sort of an architectural heads-up and a call for comments from the users of varnish, on a number of ideas I have on my Todo list right now. This is not the entire Todo list, but the list of things which significantly change the way Varnish works today. New stuff, new features (such as cookie access) are not on this list, because they have no backwards-compat issues. The items are ordered for dependency and readability, and thus, to some extent is indicative of the order things will happen. 1. Kill the magic default VCL. =============================== What this means for you: ------------------------ You will no longer be able to just give Varnish a subset of the VCL instruction, ie. just a vcl_recv{} function, you will have to copy the default VCL file and modify as needed, and provide varnish all the mandatory VCL functions. Why do we want this change: --------------------------- The current behaviour does not work the way it was intended and confuses a lot of people, because they do not see the full picture. The fact that users can provide only function prefixes (which the default VCL supplements) means that users tend to overlook the order things have to happen. For instance supplying a VCL of just: sub vcl_recv { if {req.url ~ "foobar"} { unset req.http.cookie; } } Will remove cookies from both GET, POST and any other HTTP command, because the check if POST should be pass'ed, happens afterwards in the hidden default VCL. By forcing the user to edit the default VCL, the check for "POST" will be visible in the users editor, prompting the user to think about this aspect. Why did we get it wrong initially ? ----------------------------------- Back in the ancient mists of time, spirits were brave, stakes were high and we thought it would be possible for users to use VCL "libraries" and have a VCL file that looked like: include "typo3.vcl"; include "anti_dos.vcl"; include "anti_malware.vcl"; ... Obviously, that does not work, because of the ordering necessary of the checks.. 2. Client identity =================== What do you mean client identity ? ---------------------------------- Think about a feature like sticky sessions: "we want the same client to hit the same backend all the time". That's easy to understand until you try to find out what people mean with "same client". "Client identity" is the handle I use for the answer to that question. Since different users answer it different ways, client identity needs to be controlled by VCL. For instance, if you have your varnish behind a load-balancer you will want to use the X-Forwarded-For header to identify your client, rather than the remote IP#. But if you are not behind a load-balancer, do you want to pay attention to the X-Forwarded-For header from a random squid proxy in Elbonia ? Probably not. How will it work ? ------------------ I think they way it will work is that we introduce a client.ident variable in VCL, which starts out the same as client.ip. Then in vcl_recv{}, you can choose to use X-F-F instead by: if (req.http.x-forwarded-for) { set client.ident = req.http.x-forwarded-for; } But since client.ident is a string variable, you could also: if (req.cookie[USERNAME] { set client.ident = req.cookie[USERNAME]; } The directors, random/round-robin etc, will then take whatever value you have put in client.ident, and use that to implement session-stickyness, however they decide to do that. The final bit of this, is that the outgoing X-F-F header will be produced in VCL, so you get to decide what to put into it, or if you prefer to adopt the incoming X-F-F instead. 3. Synth replies (and vcl_error{} ?) ==================================== I want to make it possible to produce a synthetic reply anywhere in VCL, with a syntax something like: sub vcl_recv { if {req.http.diediedie) { synth -status 400 -txt "Verdamt!" {" "}; } } I also want to make it possible to suck in the synth body from a file, something like: sub vcl_recv { if {req.http.diediedie) { synth -status 400 -txt "Verdamt!" -file "argh.html"; } } (The file will be read at compile-timer!) I am not 100% sure we have any need for vcl_error{} after this change, that needs to be figured out. 4. VCL conversions ================== In VCL everything is a string, unless it is not. Sometimes we need numbers, sometimes we need IP numbers. I want to make conversions explicit in VCL and it will look something like: sub vcl_recv { if (ip(req.http.x-forwarded-for, 0.0.0.0) ~ acl_badguys)) { synth -status 503 -txt "bugger off!"; } } sub vcl_fetch { beresp.ttl = duration(beresp.http.myttl, 10s); } If the conversion fails because the string value is not a valid IP/time/duration, the second parameter gets used instead. Thanks for listening, now it's your turn to tell me if this is stupid... Poul-Henning -- 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 rtshilston at gmail.com Wed Jan 6 12:25:46 2010 From: rtshilston at gmail.com (Rob S) Date: Wed, 06 Jan 2010 12:25:46 +0000 Subject: Architectural heads-up/call for comments In-Reply-To: <5877.1262778367@critter.freebsd.dk> References: <5877.1262778367@critter.freebsd.dk> Message-ID: <4B44814A.3010602@gmail.com> Poul-Henning Kamp wrote: > 1. Kill the magic default VCL. > This will make life a lot simpler for people starting out with Varnish, and help ensure that those people with advanced configurations don't overlook something. I'd like to mutter something here about adding some form of "return pass", rather than just writing "pass". This will further clear up the fact that execution will, at the time your write "pass" cease. (Please let me know if I've got this wrong). > 2. Client identity > Access to cookies is great, but I don't necessarily think that a client.ident idea is sensible. Is the "client" object going to be persistent between requests? If so, what other properties will it have? If it isn't persistent, then with existing VCL you can create a .ident property of a req, and use that to switch between pools. Is this point really that you want to establish a mechanism for passing information into more advanced directors? > 3. Synth replies (and vcl_error{} ?) > > I want to make it possible to produce a synthetic reply anywhere > in VCL... Great. Definitely useful. A use case we had recently, but which we couldn't implement, was to synthetically generate some information about the backend pool. So, we wanted a request for a particular javascript file to be generated by Varnish and say "randomhealthbackendhostname='"+be.name+"';". We couldn't do this, but it might help guide thinking as to how this might get used. > I also want to make it possible to suck in the synth body from a > file > Make sure we can specify the mime type of the synthetic reply! > (The file will be read at compile-timer!) > Nervous of this. > 4. VCL conversions > This would definitely be worth doing. We've got a few bits of config which could be enormously improved if we could parse header responses and put them as TTL values etc. We use varnish in front of some apps which use session state / cookies / other things that make caching hard. So, for apps we've been through and sanitised for varnish, we specify X-Varnish-Cache-Control which we parse in VCL and use to control Varnish's own data store, and X-External-Cache-Control, which is what we present out to the end requestor. If the response only has X-Cache-Control, we assume that the app hasn't been prepared-for-varnish, and thus mustn't be cached by varnish, regardless of what's specified. This allows us to fail-safe, but has the impact that we currently can't set the ttl to the precise value we want. Your proposed conversions would enable us to improve our config. > Thanks for listening, now it's your turn to tell me if this is > stupid... > Definitely good stuff. Let us know how we can continue to help. There's one other thing that I'd like people to comment / think about. We operate multiple varnish front ends, so that we can cope if one fails. How do people distribute purges between them? Rob From phk at phk.freebsd.dk Wed Jan 6 12:59:44 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 06 Jan 2010 12:59:44 +0000 Subject: Architectural heads-up/call for comments In-Reply-To: Your message of "Wed, 06 Jan 2010 12:25:46 GMT." <4B44814A.3010602@gmail.com> Message-ID: <11678.1262782784@critter.freebsd.dk> In message <4B44814A.3010602 at gmail.com>, Rob S writes: >Poul-Henning Kamp wrote: >I'd like to mutter something here about adding some >form of "return pass", rather than just writing "pass". That is already the syntax in -trunk: return(pass); >> 2. Client identity >> >Access to cookies is great, but I don't necessarily think that a >client.ident idea is sensible. Is the "client" object going to be >persistent between requests? Between requests: yes. Between TCP connections: no. -- 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 jhayter at manta.com Wed Jan 6 15:06:11 2010 From: jhayter at manta.com (Jim Hayter) Date: Wed, 6 Jan 2010 10:06:11 -0500 Subject: LostHeader when dealing with RxHeaders In-Reply-To: <87bph71yfr.fsf@qurzaw.linpro.no> References: <87bph71yfr.fsf@qurzaw.linpro.no> Message-ID: OS is Solaris 10 on intel hardware. Other man pages render fine. Here is what my man page for varnishd looks like. There is no formatting and there seem to be parts of sentences missing. > man varnishd Reformatting page. Please Wait... done The daemon accepts HTTP requests from clients, passes them on to a backend server and caches the returned documents to better satisfy future requests for the same document. The following options are available: Listen for client requests on the speci- fied and The can be a host name an IPv4 dotted-quad or an IPv6 address enclosed in square brackets If is not specified, will listen on all available IPv4 and IPv6 interfaces. If is not specified, the default HTTP port as listed in is used. Multiple listening addresses and ports can be specified as a whitespace- or comma-separated list. Use the specified as backend server. If is not specified, the default is 8080. Enables debugging mode. This causes to fork; the child process daemonizes and runs as usual, while the parent process remains attached to the con- sole and will accept management commands from If the parent pro- cess receives it will terminate, but the child process will con- tinue to run. The child process will not start accepting client connections until the command is given. If the flag is specified twice, the child process will not daemonize, and terminating the parent process will also terminate the child. Run in the fore- ground. Use the specified VCL configuration file instead of the builtin default. See for details on VCL syntax. Specifies the name of an unprivileged group to which the child process should switch before it starts accepting connections. This is a shortcut for specifying the run-time parameter. Specifies the hash algorithm. See for a list of supported algorithms. Specify size of shmlog file. Scaling suffixes like 'k', 'm' can be used up to (e)tabytes. Default is 80 Megabytes. Specifying less than 8 Megabytes is unwise. Specify a name for this instance. Amonst other things, this name is used to construct the name of the directory in which keeps temporary files and persistent state. If the specified name begins with a forward slash, it is inter- --More--(14%) Thanks, Jim -----Original Message----- From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Tollef Fog Heen Sent: Wednesday, January 06, 2010 2:32 AM To: varnish-misc at projects.linpro.no Subject: Re: LostHeader when dealing with RxHeaders ]] "Jim Hayter" | I found ticket 455 and increased the HTTP_HDR_MAX_VAL in configure. I think we might want to increase the default somewhat here; you're not the first to run into this problem. | On another item, the man pages for Varnish do not render correctly on my | system. It looks as if anywhere there should be something in bold, or | italics, etc that the text is missing. Any thoughts on what I need to | do to see the man pages? Sounds like man is confused. Does other man pages with bold and italics work correctly? What OS are you on? Cheers, -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From jeremy at hinegardner.org Wed Jan 6 18:21:30 2010 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Wed, 6 Jan 2010 11:21:30 -0700 Subject: varnish child failing to be restarted In-Reply-To: <877hrv1y75.fsf@qurzaw.linpro.no> References: <20100106020547.GD11017@hinegardner.org> <877hrv1y75.fsf@qurzaw.linpro.no> Message-ID: <20100106182130.GE11017@hinegardner.org> On Wed, Jan 06, 2010 at 08:37:02AM +0100, Tollef Fog Heen wrote: > ]] Jeremy Hinegardner > > | I'm wondering if there are two issues here. The first being, why does > | our child process die many times during the day, and the 2nd being, why > | does the restarting of the child fail sometimes. > > It seems to be killed by the management process. If the box is > otherwise healthy when this happens, try increasing cli_timeout. If > it's quite loaded, I would suggest doing the regular performance tuning > such as putting the shmlog on a tmpfs and making sure your working set > fits in RAM (or use SSDs). Thanks for the suggestions. Right now I'm going with increasing cli_timeout and we'll see if that alleviates the issue. > | In our case, the failure to restart the child is always when the > | "Pushing vcls failed" error appears in the log. > > This is an independent bug. I _think_ it is timing-related after a > child is killed, but I'm not exactly sure. I when looking at the documentation for cli_timeout, I also noticed cli_buffer, I have no clue if it could be related to this issue or not. We do have a fairly extensive VCL with a good bit of inline, so I increased this to be larger than the sum of our .vcl file sizes. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From tfheen at redpill-linpro.com Wed Jan 6 19:36:20 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 06 Jan 2010 20:36:20 +0100 Subject: Architectural heads-up/call for comments In-Reply-To: <4B44814A.3010602@gmail.com> (Rob S.'s message of "Wed, 06 Jan 2010 12:25:46 +0000") References: <5877.1262778367@critter.freebsd.dk> <4B44814A.3010602@gmail.com> Message-ID: <87wrzvuitn.fsf@qurzaw.linpro.no> ]] Rob S | There's one other thing that I'd like people to comment / think about. | We operate multiple varnish front ends, so that we can cope if one | fails. How do people distribute purges between them? I know that wikia uses varnishhtcpd which can be found at https://svn.wikia-code.com/utils/varnishhtcpd/ that uses multicast for it. Another option would be to use rabbitmq or similar. We also have varnish-cc which implements cache channels that we'll quite likely make available once I get around to it and get permission. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From cosimo at streppone.it Thu Jan 7 09:18:14 2010 From: cosimo at streppone.it (Cosimo Streppone) Date: Thu, 07 Jan 2010 10:18:14 +0100 Subject: Architectural heads-up/call for comments In-Reply-To: <5877.1262778367@critter.freebsd.dk> References: <5877.1262778367@critter.freebsd.dk> Message-ID: On 06 january 2010 12:46:07, Poul-Henning Kamp wrote: > [...] call for comments from the users of varnish [...] > 1. Kill the magic default VCL. It's great that you're asking feedback, thanks. > You will no longer be able to just give Varnish a subset of the VCL > instruction, ie. just a vcl_recv{} function I understand and appreciate the motivation for this. However, I must say I find it really easy to just have a default behavior built-in. In one of our deployments, we have a VCL consisting only of a 5 lines vcl_recv(). Very simple and effective. OTOH, it's true that you have to know what you're doing. I would suggest to have several presets files, sort of what mysql does with my-huge.cnf, etc... Say, something like: - default.vcl (the one with the built-in behavior) - simple-static.vcl (for mostly static web servers, strip cookies+basicauth) - webapp-simple.vcl (static + dynamic with 1 backend) - webapp-large.vcl (like simple with a cluster of backends, director, etc...) - ... > The current behaviour does not work the way it was intended and > confuses a lot of people, because they do not see the full picture. Yes, it confused me too when I wanted to just turn the key and get the thing going. Then you realize you have to stop and rftm :) > Back in the ancient mists of time, spirits were brave, stakes were > high and we thought it would be possible for users to use VCL > "libraries" and have a VCL file that looked like: > include "typo3.vcl"; > include "anti_dos.vcl"; > include "anti_malware.vcl"; > ... > Obviously, that does not work, because of the ordering necessary > of the checks.. Please, can you explain? > 2. Client identity That would be great, even if I/we (prefer to) have completely stateless backends, so it doesn't matter on which backend you end up. > 3. Synth replies (and vcl_error{} ?) We currently don't let varnish reply directly to clients, so we don't use this feature for now. > 4. VCL conversions > > if (ip(req.http.x-forwarded-for, 0.0.0.0) ~ acl_badguys)) { I never had the need for this, but I understand it's a good feature to prevent problems. > Thanks for listening, now it's your turn to tell me I hope it's useful feedback, we're just starting with varnish. -- Cosimo From phk at phk.freebsd.dk Thu Jan 7 09:39:40 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 07 Jan 2010 09:39:40 +0000 Subject: Architectural heads-up/call for comments In-Reply-To: Your message of "Thu, 07 Jan 2010 10:18:14 +0100." Message-ID: <1439.1262857180@critter.freebsd.dk> In message , "Cosimo Streppone" writes: >On 06 january 2010 12:46:07, Poul-Henning Kamp wrote: >> 1. Kill the magic default VCL. > >It's great that you're asking feedback, thanks. > >> You will no longer be able to just give Varnish a subset of the VCL >> instruction, ie. just a vcl_recv{} function > >I understand and appreciate the motivation for this. >However, I must say I find it really easy to just have >a default behavior built-in. It will still be, because we are not going to give up on the -b option. Interestingly, after sending that email, I realized that I would be the person who got hit hardest by this change, since I have 187 different VCL programs in the regression test-suite :-/ That is a really bad reason to change, what I think is otherwise a sound decision, but for reasons if sanity, I need to have some kind of workaround. One of the obvious ways to do it, is to offer the default VCL methods as callable functions. Ie something like: sub vcl_recv { if (req.url ~ "[.]exe") { error 503; } call default_recv; } Apart from making the reference to the default code explicit, that is very very close to what we have today. >OTOH, it's true that you have to know what you're doing. >I would suggest to have several presets files, sort of what >mysql does with my-huge.cnf, etc... I'm not sure I have seen sufficiently generic VCL programs to make this make sense. I fear VooDoo configurations that way. >> Back in the ancient mists of time, spirits were brave, stakes were >> high and we thought it would be possible for users to use VCL >> "libraries" and have a VCL file that looked like: >> include "typo3.vcl"; >> include "anti_dos.vcl"; >> include "anti_malware.vcl"; >> ... >> Obviously, that does not work, because of the ordering necessary >> of the checks.. > >Please, can you explain? Well, they all want to do something "first" in vcl_recv{} and there is no way to tell who is "more important" than the others. -- 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 anders at fupp.net Thu Jan 7 15:20:47 2010 From: anders at fupp.net (Anders Nordby) Date: Thu, 7 Jan 2010 16:20:47 +0100 Subject: Architectural heads-up/call for comments In-Reply-To: <5877.1262778367@critter.freebsd.dk> References: <5877.1262778367@critter.freebsd.dk> Message-ID: <20100107152047.GA57853@fupp.net> Hi, On Wed, Jan 06, 2010 at 11:46:07AM +0000, Poul-Henning Kamp wrote: > 3. Synth replies (and vcl_error{} ?) > ==================================== > > I want to make it possible to produce a synthetic reply anywhere > in VCL, with a syntax something like: > > > sub vcl_recv { > if {req.http.diediedie) { > synth -status 400 -txt "Verdamt!" {" > > "}; > } > } > > I also want to make it possible to suck in the synth body from a > file, something like: > > sub vcl_recv { > if {req.http.diediedie) { > synth -status 400 -txt "Verdamt!" -file "argh.html"; > } > } > > (The file will be read at compile-timer!) > > > I am not 100% sure we have any need for vcl_error{} after this change, > that needs to be figured out. It it possible to do this while also: - making it possible to force saint mode without a restart. - catch requests where you have a cache miss and the backend does not respond, is too slow or resets the connection. The combination of these two things, would make me very happy. :) Regards, -- Anders. From anders at fupp.net Thu Jan 7 15:39:41 2010 From: anders at fupp.net (Anders Nordby) Date: Thu, 7 Jan 2010 16:39:41 +0100 Subject: Persistent mode statistics Message-ID: <20100107153941.GB57853@fupp.net> Hi, I'm running Varnish trunk 4434 in FreeBSD/amd64 7.2-RELEASE with persistent mode and data spread on three filesystems: -s persistent,/data00/varnishd.dat,20g -s persistent,/data01/varnishd.dat,20g -s persistent,/data02/varnishd.dat,20g root at cache12:~# varnishstat -1 | egrep ^sm sm_nreq 0 0.00 allocator requests sm_nobj 0 . outstanding allocations sm_balloc 0 . bytes allocated sm_bfree 0 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free sms_nreq 41969 5.71 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 26826511 . SMS bytes allocated sms_bfree 26826511 . SMS bytes freed root at cache12:~# ps axww -o pid,vsz,rss,command | grep varnish 61987 63008980 84844 varnishd: Varnish-Mgr cache12.finn.no (varnishd) 61988 63819396 19615712 varnishd: Varnish-Chld cache12.finn.no (varnishd) As you can see, PID 61988 has allocated 19615712 kilobytes - 18,7 gigabytes of memory resident. This does not show in varnishstat. I can see that sms_balloc grows steadily, but it does not have the number I expect for used memory. How do I check how much memory/space Varnish spent with persistent mode? Cheers, -- Anders. From coolbomb at gmail.com Thu Jan 7 15:42:29 2010 From: coolbomb at gmail.com (Daniel Rodriguez) Date: Thu, 7 Jan 2010 16:42:29 +0100 Subject: Unconditional GETs and 304 from backend servers In-Reply-To: <87d41q42w4.fsf@qurzaw.linpro.no> References: <95ff419c0912230250j401d314dwe33def2826e9d1b3@mail.gmail.com> <87d41q42w4.fsf@qurzaw.linpro.no> Message-ID: <95ff419c1001070742t21d255aal22a160b1d7135573@mail.gmail.com> Hi, Thank you for your reply. I have been talking to our developers and your proposed solution would take too much time and effort, but anyways we have assigned someone to study the implications and how to achieve that. In another line, I see that in the varnish shopping list there is a: "11. Backend revalidation Support using conditional GETs to revalidate objects with the backend. (vcl option)" We may be interested to sponsor/pay the development of this feature. I don't know how this may be handled and in what conditions but its something that the company where I work could do to help the project. Best Regards, On Mon, Jan 4, 2010 at 10:48 AM, Tollef Fog Heen wrote: > ]] Daniel Rodriguez > > | The problem that we are currently having is that varnish will only ask > | unconditional GETs, so every time that varnish ask the web server for > | one of this objects after the age have expired (expecting a 200 and a > | full refresh) our servers have to recreate the whole objects (some of > | them taking a lot of CPU and time) even if this is not needed (in > | normal conditions with conditional GET they will reply 304 with less > | CPU usage). > | > | There is a possible solution to this ? maybe a workaround using VCL ? > > Varnish doesn't do conditional GETs, but you could switch the system > around and do active cache management where you set the TTL of objects > to infinity (well, 2 years or something other, high) and let the backend > use purge to remove objects that should be evicted. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From anders at fupp.net Thu Jan 7 15:55:26 2010 From: anders at fupp.net (Anders Nordby) Date: Thu, 7 Jan 2010 16:55:26 +0100 Subject: Persistent mode statistics In-Reply-To: <20100107153941.GB57853@fupp.net> References: <20100107153941.GB57853@fupp.net> Message-ID: <20100107155526.GA61522@fupp.net> Hi, On the same server, I tried to kill the child process to see how well it reloads the data. In the logs, while restarting: Jan 7 15:44:25 cache12 varnishd[61987]: Child cleanup complete Jan 7 15:45:24 cache12 varnishd[61987]: Manager got SIGINT Jan 7 15:45:24 cache12 varnishd[72808]: child (72809) Started Jan 7 15:45:25 cache12 varnishd[72808]: Child (72809) said Closed fds: 6 7 8 11 12 14 15 Jan 7 15:45:25 cache12 varnishd[72808]: Child (72809) said Child starts Jan 7 15:45:25 cache12 varnishd[72808]: Child (72809) said Dropped 0 segments to make free_reserve Jan 7 15:45:25 cache12 varnishd[72808]: Child (72809) said Ready Jan 7 15:45:27 cache12 varnishd[72808]: Child (72809) said Silo completely loaded On the console (I had auto_restart set to off): # /usr/local/etc/rc.d/varnishd restart Stopping varnishd. Starting varnishd. sizeof(struct smp_ident) = 112 = 0x70 sizeof(struct smp_sign) = 32 = 0x20 sizeof(struct smp_segptr) = 32 = 0x20 sizeof(struct smp_object) = 64 = 0x40 min_nseg = 10, max_segl = 2147063801 max_nseg = 104851, min_segl = 204772 aim_nseg = 1023, aim_segl = 20987915 aim_nobj = 536765 free_reserve = 209879150 sizeof(struct smp_ident) = 112 = 0x70 sizeof(struct smp_sign) = 32 = 0x20 sizeof(struct smp_segptr) = 32 = 0x20 sizeof(struct smp_object) = 64 = 0x40 min_nseg = 10, max_segl = 2147063801 max_nseg = 104851, min_segl = 204772 aim_nseg = 1023, aim_segl = 20987915 aim_nobj = 536765 free_reserve = 209879150 sizeof(struct smp_ident) = 112 = 0x70 sizeof(struct smp_sign) = 32 = 0x20 sizeof(struct smp_segptr) = 32 = 0x20 sizeof(struct smp_object) = 64 = 0x40 min_nseg = 10, max_segl = 2147063801 max_nseg = 104851, min_segl = 204772 aim_nseg = 1023, aim_segl = 20987915 aim_nobj = 536765 free_reserve = 209879150 Classic hash: 500009 buckets Using old SHMFILE Before I killed it: # varnishstat -1 | grep ^n_object n_object 1099549 . N struct object n_objectcore 1100129 . N struct objectcore n_objecthead 1099640 . N struct objecthead After I restarted it: # varnishstat -1 | grep ^n_object n_object 4 . N struct object n_objectcore 1094434 . N struct objectcore n_objecthead 1093945 . N struct objecthead # ps axww -o pid,vsz,rss,command | grep varnish 72808 63008980 85316 varnishd: Varnish-Mgr cache12.finn.no (varnishd) 72809 63712260 821744 varnishd: Varnish-Chld cache12.finn.no (varnishd) So it seems that n_object is emptied, while n_objectcore and n_objecthead is not? Also I notice that resident memory usage is down by around 96%, I don't know if that is to be expected? Anders. On Thu, Jan 07, 2010 at 04:39:41PM +0100, Anders Nordby wrote: > I'm running Varnish trunk 4434 in FreeBSD/amd64 7.2-RELEASE with > persistent mode and data spread on three filesystems: > > -s persistent,/data00/varnishd.dat,20g -s persistent,/data01/varnishd.dat,20g -s persistent,/data02/varnishd.dat,20g > > root at cache12:~# varnishstat -1 | egrep ^sm > sm_nreq 0 0.00 allocator requests > sm_nobj 0 . outstanding allocations > sm_balloc 0 . bytes allocated > sm_bfree 0 . bytes free > sma_nreq 0 0.00 SMA allocator requests > sma_nobj 0 . SMA outstanding allocations > sma_nbytes 0 . SMA outstanding bytes > sma_balloc 0 . SMA bytes allocated > sma_bfree 0 . SMA bytes free > sms_nreq 41969 5.71 SMS allocator requests > sms_nobj 0 . SMS outstanding allocations > sms_nbytes 0 . SMS outstanding bytes > sms_balloc 26826511 . SMS bytes allocated > sms_bfree 26826511 . SMS bytes freed > root at cache12:~# ps axww -o pid,vsz,rss,command | grep varnish > 61987 63008980 84844 varnishd: Varnish-Mgr cache12.finn.no (varnishd) > 61988 63819396 19615712 varnishd: Varnish-Chld cache12.finn.no > (varnishd) > > As you can see, PID 61988 has allocated 19615712 kilobytes - 18,7 > gigabytes of memory resident. This does not show in varnishstat. I can > see that sms_balloc grows steadily, but it does not have the number I > expect for used memory. How do I check how much memory/space Varnish > spent with persistent mode? > > Cheers, > > -- > Anders. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -- Anders. From phk at phk.freebsd.dk Thu Jan 7 16:38:36 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 07 Jan 2010 16:38:36 +0000 Subject: Persistent mode statistics In-Reply-To: Your message of "Thu, 07 Jan 2010 16:55:26 +0100." <20100107155526.GA61522@fupp.net> Message-ID: <38144.1262882316@critter.freebsd.dk> In message <20100107155526.GA61522 at fupp.net>, Anders Nordby writes: >So it seems that n_object is emptied, while n_objectcore and >n_objecthead is not? Also I notice that resident memory usage is down by >around 96%, I don't know if that is to be expected? n_object will increase as the objects are instantiated from the silo. Resident will increase as it gets paged in. -- 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 tfheen at redpill-linpro.com Fri Jan 8 08:34:26 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Fri, 08 Jan 2010 09:34:26 +0100 Subject: Unconditional GETs and 304 from backend servers In-Reply-To: <95ff419c1001070742t21d255aal22a160b1d7135573@mail.gmail.com> (Daniel Rodriguez's message of "Thu, 7 Jan 2010 16:42:29 +0100") References: <95ff419c0912230250j401d314dwe33def2826e9d1b3@mail.gmail.com> <87d41q42w4.fsf@qurzaw.linpro.no> <95ff419c1001070742t21d255aal22a160b1d7135573@mail.gmail.com> Message-ID: <87pr5lq9kd.fsf@qurzaw.linpro.no> ]] Daniel Rodriguez | In another line, I see that in the varnish shopping list there is a: | | "11. Backend revalidation | | Support using conditional GETs to revalidate objects with the backend. | (vcl option)" | | We may be interested to sponsor/pay the development of this feature. I | don't know how this may be handled and in what conditions but its | something that the company where I work could do to help the project. If you're interested in sponsoring development, please get in touch with varnish at redpill-linpro.com and we'll be happy to give you a quote. Cheers, -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From john at 7fff.com Fri Jan 8 21:20:46 2010 From: john at 7fff.com (John Norman) Date: Fri, 8 Jan 2010 16:20:46 -0500 Subject: Question from Dec. 2009: "still using cache when fetching content" Message-ID: Hi. I've just subscribed, and have been reading through the e-mail archives for varnish-misc. In Dec. 2009, Jean-Christophe Petit asked (with subject "still using cache when fetching content"): ----- Is it possible to make Varnish sending the cache content at the same time it is fetching from the backend ? It will be more efficient for slow dynamic content ;) For example, I have a php page taking up to 5sec to run. If Varnish was able to get it while still sending the old cache page, it would be really great. No more unlucky visitor hitting it to update the cache.. ----- There were a couple of replies, but I just wanted to flesh out the "use case": I think the scenario would be: (1) There is a page that takes a very long time to render (say, 90 seconds) (2) It is cached, perhaps to expire after an hour (3) In normal usage, everyone gets the cached page and is very happy (4) An administrator would like to refresh that page in the cache BEFORE the hour is up; but give any user the earlier cached page (6) The admin would like a mechanism: "Please refresh now with this request, but until the request is finished, serve whatever is in the cache." This is different from grace, 'cos no one (except the admin) is incurring the wait; and also the admin is asking for a refresh before the cached page has expired. Is this a feature that can be simulated in Varnish? Or a feature that might be added at some time? What we're concerned about is Google's timing of page download. If we set a cache period to, say, an hour, and Google incurs the "first hit" after cache expiry, then it (Google) has to wait for the finished page. In grace mode, requests after the Google hit would get the earlier cached page; but, still, Google has measured the page as taking, say, 60 seconds to download. In the model above, Google would get the cached page; it would just be stale. Thoughts? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at 7fff.com Fri Jan 8 21:35:47 2010 From: john at 7fff.com (John Norman) Date: Fri, 8 Jan 2010 16:35:47 -0500 Subject: Question from Dec. 2009: "still using cache when fetching content" In-Reply-To: References: Message-ID: I think Chris Davies has straightened me out, and that the scenario I describe *is* covered by grace -- that the first hit would also get stale (as well as others in the grace period), which is exactly what I want. On Fri, Jan 8, 2010 at 4:20 PM, John Norman wrote: > Hi. I've just subscribed, and have been reading through the e-mail archives > for varnish-misc. > > In Dec. 2009, Jean-Christophe Petit asked (with subject "still using cache > when fetching content"): > > ----- > Is it possible to make Varnish sending the cache content at the same > time it is fetching from the backend ? > It will be more efficient for slow dynamic content ;) > For example, I have a php page taking up to 5sec to run. If Varnish was > able to get it while still sending the old cache page, it would be > really great. > No more unlucky visitor hitting it to update the cache.. > ----- > > There were a couple of replies, but I just wanted to flesh out the "use > case": > > I think the scenario would be: > > (1) There is a page that takes a very long time to render (say, 90 seconds) > (2) It is cached, perhaps to expire after an hour > (3) In normal usage, everyone gets the cached page and is very happy > (4) An administrator would like to refresh that page in the cache BEFORE > the hour is up; but give any user the earlier cached page > (6) The admin would like a mechanism: "Please refresh now with this > request, but until the request is finished, serve whatever is in the cache." > > This is different from grace, 'cos no one (except the admin) is incurring > the wait; and also the admin is asking for a refresh before the cached page > has expired. > > Is this a feature that can be simulated in Varnish? Or a feature that might > be added at some time? > > What we're concerned about is Google's timing of page download. If we set a > cache period to, say, an hour, and Google incurs the "first hit" after cache > expiry, then it (Google) has to wait for the finished page. In grace mode, > requests after the Google hit would get the earlier cached page; but, still, > Google has measured the page as taking, say, 60 seconds to download. In the > model above, Google would get the cached page; it would just be stale. > > Thoughts? > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at vanlingen.name Fri Jan 8 21:54:13 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Fri, 8 Jan 2010 22:54:13 +0100 Subject: logging statements in vcl Message-ID: <458a97201001081354s50a74935o2a2d36a8dab44007@mail.gmail.com> Hello, I recently started to use varnish. The installation with the default vcl starts without problems. However if I turn varnish logging on It seems to cache nothing (I see only 'pass' and 'deliver' statements). Is there a way to add logging statements in the vcl file that will be displayed when I turn on varnish logging? I was not able to find anything about this on the varnish pages. It would help analyzing the vcl configurations. Frank. From phk at phk.freebsd.dk Fri Jan 8 22:10:38 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 08 Jan 2010 22:10:38 +0000 Subject: logging statements in vcl In-Reply-To: Your message of "Fri, 08 Jan 2010 22:54:13 +0100." <458a97201001081354s50a74935o2a2d36a8dab44007@mail.gmail.com> Message-ID: <43106.1262988638@critter.freebsd.dk> In message <458a97201001081354s50a74935o2a2d36a8dab44007 at mail.gmail.com>, Frank van Lingen writes: >Hello, > >I recently started to use varnish. The installation with the default >vcl starts without problems. > >However if I turn varnish logging on It seems to cache nothing (I see >only 'pass' and 'deliver' statements). > >Is there a way to add logging statements in the vcl file that will be >displayed when I turn on varnish logging? I was not able to find >anything about this on the varnish pages. It would help analyzing the >vcl configurations. Set the "vcl_trace" parameter, that will add logging entries for every branch taken in your VCL. The number 1 case of not caching is cookies. Poul-Henning -- 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 jhayter at manta.com Fri Jan 8 22:20:28 2010 From: jhayter at manta.com (Jim Hayter) Date: Fri, 8 Jan 2010 17:20:28 -0500 Subject: Bug? Related to ticket 547 Message-ID: I'm sorry, but I'm not sure how/where to report this. I'm running varnish-2.0.6 on Solaris 10. I had the issue noted in http://varnish.projects.linpro.no/ticket/547 when testing 2.0.5, which was fixed in 2.0.6. I just tried 2.0.6 on a production system and ran into the issues noted in the varnishd output below. It appears to be a similar call to setsockopt to the one noted in ticket 547. This error occurred every 3-6 minutes. Any input is welcomed. We had hoped to run this on one of our production web servers all weekend as a prelude to putting it into full production. Thanks, Jim Varnishd output --------------- ... Child (21784) said ", 1, 3) Child (21784) not responding to ping, killing it. Child (21784) not responding to ping, killing it. Child (21784) not responding to ping, killing it. Child (21784) died signal=6 (core dumped) Child (21784) Panic message: Assert error in VCA_Prep(), cache_acceptor.c line 148: Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) == 0) not true. errno = 9 (Bad file number) thread = (cache-worker) sp = 8f29974 { fd = 84, id = 84, xid = 0, client = 66.68.180.213:2086, step = STP_FIRST, handling = error, restarts = 0, esis = 0 ws = 8f299c0 { id = "sess", {s,f,r,e} = {8f2a470,+19,0,+32768}, }, http[req] = { ws = 0[] }, worker = 731cdee0 }, Child cleanup complete child (21816) Started Child (21816) said Closed fds: 4 5 25 26 28 29 ... From frank at vanlingen.name Sat Jan 9 00:32:45 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Sat, 9 Jan 2010 01:32:45 +0100 Subject: logging statements in vcl In-Reply-To: <43106.1262988638@critter.freebsd.dk> References: <458a97201001081354s50a74935o2a2d36a8dab44007@mail.gmail.com> <43106.1262988638@critter.freebsd.dk> Message-ID: <458a97201001081632l407da479r954ebcf56245d2d1@mail.gmail.com> Yeah I noticed that google tracking sets some cookies. After I removed the tracking script the hit ratio went up. -------------------------------------------- Frank van Lingen email : frank at vanlingen.name VOIP (skype) : fvlingen IM (yahoo,hotmail) : fvlingen IM (AIM) : frank at vanlingen.name URL : http://vanlingen.name LinkedIn : fvlingen ------------------------------------------- On Fri, Jan 8, 2010 at 11:10 PM, Poul-Henning Kamp wrote: > In message <458a97201001081354s50a74935o2a2d36a8dab44007 at mail.gmail.com>, Frank > ?van Lingen writes: >>Hello, >> >>I recently started to use varnish. The installation with the default >>vcl starts without problems. >> >>However if I turn varnish logging on It seems to cache nothing (I see >>only 'pass' and 'deliver' ?statements). >> >>Is there a way to add logging statements in the vcl file that will be >>displayed when I turn on varnish logging? I was not able to find >>anything about this on the varnish pages. It would help analyzing the >>vcl configurations. > > Set the "vcl_trace" parameter, that will add logging entries for > every branch taken in your VCL. > > The number 1 case of not caching is cookies. > > Poul-Henning > > -- > 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 pubcrawler.com at gmail.com Sat Jan 9 07:09:36 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 9 Jan 2010 02:09:36 -0500 Subject: VCL config file for specific URLs Message-ID: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> Finally back to looking at Varnish for our overwhelmed site. Working on our default.vcl file. Have a simple, perhaps obvious question. We want to put Varnish in front of our application server. There are cookies coming from the app server, but we have told Varnish to ignore them: unset req.http.cookie That works fine, but we want Varnish to only do this on certain pages. More simply and shorter in number we want Varnish to adhere to the cookies only on certain user customizeable pages. For example (cache these in Varnish): http://www.website.com/Template/index.cfm http://www.website.com/Template/Review.cfm/flat/ID=xxxx DO NOTE CACHE THESE - pipe to backend: http://www.website.com/Template/dsp_addreview.cfm http://www.website.com/Template/mapinput.cfm Any ideas on how to best go about providing a list of URLs to pipe in our default.vcl file? Thanks! From rtshilston at gmail.com Sat Jan 9 10:25:59 2010 From: rtshilston at gmail.com (Rob S) Date: Sat, 09 Jan 2010 10:25:59 +0000 Subject: VCL config file for specific URLs In-Reply-To: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> References: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> Message-ID: <4B4859B7.9040700@gmail.com> pub crawler wrote: > That works fine, but we want Varnish to only do this on certain pages. > > More simply and shorter in number we want Varnish to adhere to the > cookies only on certain user customizeable pages. > > For example (cache these in Varnish): > http://www.website.com/Template/index.cfm > http://www.website.com/Template/Review.cfm/flat/ID=xxxx > > DO NOTE CACHE THESE - pipe to backend: > http://www.website.com/Template/dsp_addreview.cfm > http://www.website.com/Template/mapinput.cfm > > Any ideas on how to best go about providing a list of URLs to pipe in > our default.vcl file? > I'm not sure of the best way to supply a large list of URLs to pipe, but I'd suggest that you think about turning the logic around. I don't know the nature of your site, but presumably it's safe to cache all JPEGs and similar. How much load would be alleviated by caching everything whose content type is not text/html? Then, for text/html, is it possible for you to edit your backend site and add a header such as "X-Is-Cacheable: yes" in your index.cfm and Review.cfm? Then, in vcl_fetch, you'd do something like: if content-type = text/html if X-Is-Cacheable = yes cache this else don't cache end if else cache this end if You might find this approach simpler than writing a big long list of pages not to cache. Rob From pubcrawler.com at gmail.com Sat Jan 9 10:40:07 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 9 Jan 2010 05:40:07 -0500 Subject: VCL config file for specific URLs In-Reply-To: <4B4859B7.9040700@gmail.com> References: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> <4B4859B7.9040700@gmail.com> Message-ID: <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> Thanks for your input Rob. JPEG's, GIFs, etc. are all fine to cache, as they are very static in nature in our environment. Currently we have Varnish setup to cache: ico|html|htm|bmp|png|gif|jpg|jpeg|swf|css|js|rss|xml Our issue is our app servers get overwhelmed, become a large bottleneck and eventually fail under high load. We can add more servers in horizontal scaling mode, but creates more wasted power, more machines to maintain, etc. Our need it to address raised site load mostly due to search spiders that are out of control but necessary. So we thought getting Varnish to cache all these dynamic pages would alleviate load on our application servers. Essentially, it is fine for Varnish to cache all of our ColdFusion pages (.cfm), except a handful of pages like these: http://www.website.com/Template/members/ http://www.website.com/Template/dsp_addreview.cfm/flat/ID=157 etc. Any idea of how to accomplish the cache exception of these handful of pages? > I'm not sure of the best way to supply a large list of URLs to pipe, but I'd > suggest that you think about turning the logic around. ?I don't know the > nature of your site, but presumably it's safe to cache all JPEGs and > similar. ?How much load would be alleviated by caching everything whose > content type is not text/html? > > Then, for text/html, is it possible for you to edit your backend site and > add a header such as "X-Is-Cacheable: yes" in your index.cfm and Review.cfm? > ?Then, in vcl_fetch, you'd do something like: > > if content-type = text/html > ? if X-Is-Cacheable = yes > ? ? ? cache this > ? else > ? ? ? don't cache > ? end if > else > ? cache this > end if > > > You might find this approach simpler than writing a big long list of pages > not to cache. > > > Rob > From phk at phk.freebsd.dk Sat Jan 9 10:49:13 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 09 Jan 2010 10:49:13 +0000 Subject: VCL config file for specific URLs In-Reply-To: Your message of "Sat, 09 Jan 2010 05:40:07 EST." <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> Message-ID: <58139.1263034153@critter.freebsd.dk> In message <4c3149fb1001090240l53a26f5eg9452abdbdd820d45 at mail.gmail.com>, pub c rawler writes: >Any idea of how to accomplish the cache exception of these handful of pages? If you have a short-ish list of URLs, you can simply test for them: sub vcl_recv { if (req.url ~ "(foo.html|bar.html|baz.html)") { pass; } } If the list is long-ish, consider having the webserver mark them as non-cacheable by adding a HTTP header varnish can check for instead. That way the knowledge about cacheability is maintained with the content. Of course, you can also mix the two methods... -- 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 rtshilston at gmail.com Sat Jan 9 10:49:20 2010 From: rtshilston at gmail.com (Rob S) Date: Sat, 09 Jan 2010 10:49:20 +0000 Subject: VCL config file for specific URLs In-Reply-To: <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> References: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> <4B4859B7.9040700@gmail.com> <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> Message-ID: <4B485F30.8010107@gmail.com> In our vcl_recv, we use things like: if (req.url ~ "wp-admin") { pass; } if (req.url ~ "/blog/wp-login.php") { pipe; } // Don't cache from some IPs if (client.ip == "1.2.3.4") { pass; } Is that any help? Rob pub crawler wrote: > Thanks for your input Rob. > > JPEG's, GIFs, etc. are all fine to cache, as they are very static in > nature in our environment. > Currently we have Varnish setup to cache: > ico|html|htm|bmp|png|gif|jpg|jpeg|swf|css|js|rss|xml > > Our issue is our app servers get overwhelmed, become a large > bottleneck and eventually fail under high load. We can add more > servers in horizontal scaling mode, but creates more wasted power, > more machines to maintain, etc. Our need it to address raised site > load mostly due to search spiders that are out of control but > necessary. > > So we thought getting Varnish to cache all these dynamic pages would > alleviate load on our application servers. > > Essentially, it is fine for Varnish to cache all of our ColdFusion > pages (.cfm), except a handful of pages like these: > http://www.website.com/Template/members/ > http://www.website.com/Template/dsp_addreview.cfm/flat/ID=157 > etc. > > Any idea of how to accomplish the cache exception of these handful of pages? > > > >> I'm not sure of the best way to supply a large list of URLs to pipe, but I'd >> suggest that you think about turning the logic around. I don't know the >> nature of your site, but presumably it's safe to cache all JPEGs and >> similar. How much load would be alleviated by caching everything whose >> content type is not text/html? >> >> Then, for text/html, is it possible for you to edit your backend site and >> add a header such as "X-Is-Cacheable: yes" in your index.cfm and Review.cfm? >> Then, in vcl_fetch, you'd do something like: >> >> if content-type = text/html >> if X-Is-Cacheable = yes >> cache this >> else >> don't cache >> end if >> else >> cache this >> end if >> >> >> You might find this approach simpler than writing a big long list of pages >> not to cache. >> >> >> Rob >> >> > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From frank at vanlingen.name Sat Jan 9 13:28:19 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Sat, 9 Jan 2010 14:28:19 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? Message-ID: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> Hello, After setting up varnish and starting it I looked at the statistics using varnsihstat. The timer in the left uppper corner seems to be the uptime since it last started or was flushed. When I loaded some pages, I can see the cache is working But I notice that once every so often the cache seems to either flush itself or restart. During this 2-3 seconds that this happens I can not load any pages. Is there a default 'cash flush' value that makes this (for me undesirable) behavior happen? I added the example described in http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching to my vcl file, but if the cash flushes itself a couple of times per day then it defeats the purpose. I am using varnish-2.0.5-1.el5 on centos5 and use the default.vcl file with the above longer caching example added to it and ignore swf and pdf files. I start varnish with 40 MB of cache and test this with a few html pages and jpgs (less then 15 MB in size). During tests normally not more than 50% of the cache is used. Besides this issue varnish seems to work almost right out of the box. Frank. From pubcrawler.com at gmail.com Sat Jan 9 15:42:54 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 9 Jan 2010 10:42:54 -0500 Subject: Caching pages with URL parameters Message-ID: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> Managed to work though my earlier Varnish issues with help from the list. Thank you! Have another likely obvious question. Most of our pages use a flat - fake non-appearing to be dynamic format. Like this: http://www.website.com/Template/dsp_restaurant_zoom.cfm/flat/ID=460401 For some reason we can't get Varnish to cache these pages. In sub vcl_recv I have this: if (req.url ~ "dsp_restaurant_zoom.cfm") { unset req.http.cookie; lookup; } Anyone have any ideas of how to get these pages cached? Thank you! -Paul From pubcrawler.com at gmail.com Sat Jan 9 18:59:17 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 9 Jan 2010 13:59:17 -0500 Subject: Varnish poisoned cache avoidance Message-ID: <4c3149fb1001091059s6521166ew4a179041f7e0cff@mail.gmail.com> We have some ban / block logic in our application server behind Varnish. For instance, when we have a comment spammer or other repetitive troublemaker messing with our applications we ban their IP in our application server. A person or bot returning after being blocked will still reach our app server, but it just returns a page that says BANNED. We had such a banned IP request a page and subsequently I requested the same page and was given the BANNED message as it was sitting in Varnish cache - even though my IP is not banned. My question here is how best to prevent this and what sort of workaround other folks have for this? I've considered banning at our firewall level, but it's too time consuming to do so and the block lists are so long that it really causes the firewall to take forever to restart from cold reboot. Originally I had blocked at the firewall, so I've been down that road. Any input would be greatly appreciated... -Paul From kb+varnish at slide.com Sun Jan 10 03:27:43 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Sat, 9 Jan 2010 19:27:43 -0800 Subject: Varnish poisoned cache avoidance In-Reply-To: <4c3149fb1001091059s6521166ew4a179041f7e0cff@mail.gmail.com> References: <4c3149fb1001091059s6521166ew4a179041f7e0cff@mail.gmail.com> Message-ID: Have the application emit a cache pragma or expires to make the BANNED page non-cacheable. Alternatively, you could have the app emit an Expires header to cause the browser to cache the result, but also add a header that would trigger Varnish to /not/ cache it. Looking at your previous posts, make sure you don't try to pull app logic up into caches, firewalls, or load balancers -- it will hurt you later, IMHO. The application is the definitive source of cacheability. Varnish/etc offer tools to tweak this, but the logic really belongs in the app and widely supported cache headers. As an alternate IP blocking implementation, you could create a list of banned IPs in a file that your VCL includes; a Varnish reload causes essentially no outage. But then you're adding an extra linear lookup for /every/ hit to Varnish. My US$0.02, -- Ken On Jan 9, 2010, at 10:59 AM, pub crawler wrote: > We have some ban / block logic in our application server behind > Varnish. For instance, when we have a comment spammer or other > repetitive troublemaker messing with our applications we ban their IP > in our application server. > > A person or bot returning after being blocked will still reach our app > server, but it just returns a page that says BANNED. > > We had such a banned IP request a page and subsequently I requested > the same page and was given the BANNED message as it was sitting in > Varnish cache - even though my IP is not banned. > > My question here is how best to prevent this and what sort of > workaround other folks have for this? > > I've considered banning at our firewall level, but it's too time > consuming to do so and the block lists are so long that it really > causes the firewall to take forever to restart from cold reboot. > Originally I had blocked at the firewall, so I've been down that road. > > Any input would be greatly appreciated... > > -Paul > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -- kb From david.birdsong at gmail.com Sun Jan 10 04:00:33 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Sat, 9 Jan 2010 20:00:33 -0800 Subject: varnish suddenly restarting / flushing itself after several hours? In-Reply-To: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> References: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> Message-ID: The parent will restart the child if it becomes unresponsive to pings. This can happen for multiple reasons. Do you have historical metrics for the server that you can examine to see if load goes up or idle cpu goes down or if memory is consumed? (Sorry for the top post, friggin mobile device) On Jan 9, 2010 5:34 AM, "Frank van Lingen" wrote: Hello, After setting up varnish and starting it I looked at the statistics using varnsihstat. The timer in the left uppper corner seems to be the uptime since it last started or was flushed. When I loaded some pages, I can see the cache is working But I notice that once every so often the cache seems to either flush itself or restart. During this 2-3 seconds that this happens I can not load any pages. Is there a default 'cash flush' value that makes this (for me undesirable) behavior happen? I added the example described in http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching to my vcl file, but if the cash flushes itself a couple of times per day then it defeats the purpose. I am using varnish-2.0.5-1.el5 on centos5 and use the default.vcl file with the above longer caching example added to it and ignore swf and pdf files. I start varnish with 40 MB of cache and test this with a few html pages and jpgs (less then 15 MB in size). During tests normally not more than 50% of the cache is used. Besides this issue varnish seems to work almost right out of the box. Frank. _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at makeityourway.de Sun Jan 10 09:59:04 2010 From: info at makeityourway.de (Mike Schiessl) Date: Sun, 10 Jan 2010 10:59:04 +0100 Subject: AW: Varnish poisoned cache avoidance In-Reply-To: References: <4c3149fb1001091059s6521166ew4a179041f7e0cff@mail.gmail.com> Message-ID: <01cf01ca91db$8c29b790$a47d26b0$@de> When I read this messages, theres something I miss, too. Some function in varnishd, similar to the lighty/apache mod_evasive. It enables you the possibility to create dynamic hit/connection rate depending blocking of ips. How can varnishd help me prevent DDOS / DOS attacks ? Regards Mike Schiessl info at makeityourway.de http://makeITyourway.de -----Urspr?ngliche Nachricht----- Von: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] Im Auftrag von Ken Brownfield Gesendet: Sonntag, 10. Januar 2010 04:28 An: pub crawler Cc: varnish-misc at projects.linpro.no Betreff: Re: Varnish poisoned cache avoidance Have the application emit a cache pragma or expires to make the BANNED page non-cacheable. Alternatively, you could have the app emit an Expires header to cause the browser to cache the result, but also add a header that would trigger Varnish to /not/ cache it. Looking at your previous posts, make sure you don't try to pull app logic up into caches, firewalls, or load balancers -- it will hurt you later, IMHO. The application is the definitive source of cacheability. Varnish/etc offer tools to tweak this, but the logic really belongs in the app and widely supported cache headers. As an alternate IP blocking implementation, you could create a list of banned IPs in a file that your VCL includes; a Varnish reload causes essentially no outage. But then you're adding an extra linear lookup for /every/ hit to Varnish. My US$0.02, -- Ken On Jan 9, 2010, at 10:59 AM, pub crawler wrote: > We have some ban / block logic in our application server behind > Varnish. For instance, when we have a comment spammer or other > repetitive troublemaker messing with our applications we ban their IP > in our application server. > > A person or bot returning after being blocked will still reach our app > server, but it just returns a page that says BANNED. > > We had such a banned IP request a page and subsequently I requested > the same page and was given the BANNED message as it was sitting in > Varnish cache - even though my IP is not banned. > > My question here is how best to prevent this and what sort of > workaround other folks have for this? > > I've considered banning at our firewall level, but it's too time > consuming to do so and the block lists are so long that it really > causes the firewall to take forever to restart from cold reboot. > Originally I had blocked at the firewall, so I've been down that road. > > Any input would be greatly appreciated... > > -Paul > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc -- kb _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From phk at phk.freebsd.dk Sun Jan 10 10:12:57 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 10 Jan 2010 10:12:57 +0000 Subject: AW: Varnish poisoned cache avoidance In-Reply-To: Your message of "Sun, 10 Jan 2010 10:59:04 +0100." <01cf01ca91db$8c29b790$a47d26b0$@de> Message-ID: <63344.1263118377@critter.freebsd.dk> In message <01cf01ca91db$8c29b790$a47d26b0$@de>, "Mike Schiessl" writes: >How can varnishd help me prevent DDOS / DOS attacks ? Firstly, by being damn fast. Originally we had some plans for specific antiDoS measures, something like: sub vcl_recv { if (client.bandwidth > 100 mbit/s) { delay 100ms; } if (client.missratio > 20%) { close; } } et cetera... There are some issues and fine details to doing it, amongst other things that we need to have a data structure for the client which survives the individual session long enough for it to make any difference in the above context. The trouble of course is that a DDoS cannot be identified by IP#, prompting ideas long the lines of sub vcl_recv { if (backend.hitrate < 70%) { /* do something... */ } } etc. But before we get anywere, somebody needs to figure out what we can do. Basically any countermeasure has two equally troublesome components: 1. detection. Knowing that you need to do something. 2. mitigation. What are we going to do ? Poul-Henning -- 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 pubcrawler.com at gmail.com Sun Jan 10 10:59:06 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sun, 10 Jan 2010 05:59:06 -0500 Subject: Varnish poisoned cache avoidance In-Reply-To: References: <4c3149fb1001091059s6521166ew4a179041f7e0cff@mail.gmail.com> Message-ID: <4c3149fb1001100259n499dce85w2e0506185f046ee4@mail.gmail.com> Thanks Ken, you input is very valuable to me. There's so much to learn from others using Varnish. Very impressed with Varnish and community. I took the approach of blocking IPs at firewall level to protect our app servers. Lots of these banned IPs are malicious, hack attempts - others are repetitive comment spammer bots. Every request that gets past the firewall consumes resources of our web server, reverse proxy, app server, database, etc. When multiplied the consumption is enormous and unnecessary. I am moving more towards an escalation process where first time you get banned for short time at app server, then it increases and moves up the server stack where finally banned at firewall. It's a dance to keep control and management of this at an application level while feeding block info to various parts of our systems. I have to look at our applications and adding cache pragma or expires information. I am not in control of all aspects of our programs due to third party applications and other folks code in our environment. That's why I thought having Varnish cache everything regardless of cookies and headers was the way to go. Then simply provide a list of URLs to not cache. Can this be done? > As an alternate IP blocking implementation, you could create a list of banned IPs in a file > that your VCL includes; a Varnish reload causes essentially no outage. ?But then you're > adding an extra linear lookup for /every/ hit to Varnish. Does anyone have an example on how to do a VCL include to facilitate this banning of IPs? Thanks so much! From pubcrawler.com at gmail.com Sun Jan 10 11:07:27 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sun, 10 Jan 2010 06:07:27 -0500 Subject: AW: Varnish poisoned cache avoidance In-Reply-To: <63344.1263118377@critter.freebsd.dk> References: <01cf01ca91db$8c29b790$a47d26b0$@de> <63344.1263118377@critter.freebsd.dk> Message-ID: <4c3149fb1001100307s4364a201n9164abbe1095782d@mail.gmail.com> The antiDoS features would be a good enhancement to Varnish. I realize it's a very complex and resource intensive thing to approach. There are likely many other ways some of these functions could be used in other ways for other solutions. In our instance we are not experiencing a true denial of service attack, but rather are being overwhelmed on our app servers by an high sustained per second request rate. The antiDoS features would certainly help us in this situation. Is the "delay 100ms" something that could be made available in Varnish near term? I could use this delay in conjunction with IP range of known bots causing problems or by defining User Agent with this. On Sun, Jan 10, 2010 at 5:12 AM, Poul-Henning Kamp wrote: > In message <01cf01ca91db$8c29b790$a47d26b0$@de>, "Mike Schiessl" writes: > >>How can varnishd help me prevent DDOS / DOS attacks ? > > Firstly, by being damn fast. > > Originally we had some plans for specific antiDoS measures, something > like: > > ? ? ? ?sub vcl_recv { > ? ? ? ? ? ? ? ?if (client.bandwidth > 100 mbit/s) { > ? ? ? ? ? ? ? ? ? ? ? ?delay 100ms; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (client.missratio > 20%) { > ? ? ? ? ? ? ? ? ? ? ? ?close; > ? ? ? ? ? ? ? ?} > ? ? ? ?} > > et cetera... > > There are some issues and fine details to doing it, amongst other things > that we need to have a data structure for the client which survives > the individual session long enough for it to make any difference > in the above context. > > The trouble of course is that a DDoS cannot be identified by IP#, > prompting ideas long the lines of > > ? ? ? ?sub vcl_recv { > ? ? ? ? ? ? ? ?if (backend.hitrate < 70%) { > ? ? ? ? ? ? ? ? ? ? ? ?/* do something... */ > ? ? ? ? ? ? ? ?} > ? ? ? ?} > > etc. > > But before we get anywere, somebody needs to figure out what we > can do. > > Basically any countermeasure has two equally troublesome components: > > 1. detection. ?Knowing that you need to do something. > > 2. mitigation. ?What are we going to do ? > > Poul-Henning > > > -- > 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. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From pubcrawler.com at gmail.com Sun Jan 10 11:31:17 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sun, 10 Jan 2010 06:31:17 -0500 Subject: Caching pages with URL parameters In-Reply-To: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> References: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> Message-ID: <4c3149fb1001100331q3091e82xf17357e930a94856@mail.gmail.com> I wanted to describe this in better degree to see if anyone can recommend a way to get Varnish caching these sorts of pages. This page: http://www.pubcrawler.com/Template/dsp_restaurant_zoom.cfm/flat/ID=460401 If I look at underlying data via curl: HTTP/1.1 200 OK Set-Cookie: CFID=12184891;expires=Tue, 03-Jan-2040 11:08:36 GMT;path=/ Set-Cookie: CFTOKEN=72775ccc0494d2bc-17EBD5E4-BC40-068E-077D1BBD2D49E203;expires=Tue, 03-Jan-2040 11:08:36 GMT;path=/ Set-Cookie: JSESSIONID=e030f11585446e200dcc4980397913a2b777;path=/ Set-Cookie: CFGLOBALS=urltoken%3DCFID%23%3D12184891%26CFTOKEN%23%3D72775ccc0494d2bc%2D17EBD5E4%2DBC40%2D068E%2D077D1BBD2D49E203%26jsessionid%23%3De030f11585446e200dcc4980397913a2b777%23lastvisit%3D%7Bts%20%272010%2D01%2D10%2006%3A08%3A36%27%7D%23timecreated%3D%7Bts%20%272010%2D01%2D10%2006%3A08%3A36%27%7D%23hitcount%3D2%23cftoken%3D72775ccc0494d2bc%2D17EBD5E4%2DBC40%2D068E%2D077D1BBD2D49E203%23cfid%3D12184891%23;expires=Tue, 03-Jan-2040 11:08:36 GMT;path=/ Set-Cookie: CFGLOBALS=urltoken%3DCFID%23%3D12184891%26CFTOKEN%23%3D72775ccc0494d2bc%2D17EBD5E4%2DBC40%2D068E%2D077D1BBD2D49E203%26jsessionid%23%3De030f11585446e200dcc4980397913a2b777%23lastvisit%3D%7Bts%20%272010%2D01%2D10%2006%3A08%3A36%27%7D%23timecreated%3D%7Bts%20%272010%2D01%2D10%2006%3A08%3A36%27%7D%23hitcount%3D2%23cftoken%3D72775ccc0494d2bc%2D17EBD5E4%2DBC40%2D068E%2D077D1BBD2D49E203%23cfid%3D12184891%23;expires=Tue, 03-Jan-2040 11:08:36 GMT;path=/ Content-Type: text/html; charset=UTF-8 Date: Sun, 10 Jan 2010 11:08:36 GMT X-Varnish: 866839940 Age: 0 Via: 1.1 varnish Connection: keep-alive If I look at a page that Varnish does cache successfully: http://www.pubcrawler.com/Template/index.cfm HTTP/1.1 200 OK Keep-Alive: timeout=15 Content-Type: text/html; charset=UTF-8 Content-Length: 84012 Date: Sun, 10 Jan 2010 11:12:50 GMT X-Varnish: 866840383 Age: 10 Via: 1.1 varnish Connection: keep-alive I understand that the first page does have a bunch of cookies that are causing Varnish to not cache this. How do we get Varnish to ignore these cookies and cache it anyways? From pubcrawler.com at gmail.com Sun Jan 10 12:05:36 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sun, 10 Jan 2010 07:05:36 -0500 Subject: Caching pages with URL parameters In-Reply-To: <4c3149fb1001100331q3091e82xf17357e930a94856@mail.gmail.com> References: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> <4c3149fb1001100331q3091e82xf17357e930a94856@mail.gmail.com> Message-ID: <4c3149fb1001100405q1ecd9ed8j26120f6b9fb099f3@mail.gmail.com> I managed to perfect the caching of our pages spitting out cookies through trial and error. So this page for instance now caches in Varnish even though the cookies come along with the page: http://www.pubcrawler.com/Template/dsp_restaurant_zoom.cfm/flat/ID=415517/muma%20restaurant Accomplished this it appears by adding to vcl_fetch: if (obj.http.Set-Cookie) { lookup; } In our webserver we added the headers: Cache-Control "public; max-age=600" Vary "Accept-Encoding" We now get this underlying output: HTTP/1.1 200 OK Keep-Alive: timeout=15 Set-Cookie: CFID=12188767;expires=Tue, 03-Jan-2040 12:02:39 GMT;path=/ Set-Cookie: CFTOKEN=2af59da685f8a0a1-181D504B-B9C8-47B9-5FFC50F14FAF2D99;expires=Tue, 03-Jan-2040 12:02:39 GMT;path=/ Set-Cookie: CFGLOBALS=urltoken%3DCFID%23%3D12188767%26CFTOKEN%23%3D2af59da685f8a0a1%2D181D504B%2DB9C8%2D47B9%2D5FFC50F14FAF2D99%23lastvisit%3D%7Bts%20%272010%2D01%2D10%2007%3A02%3A39%27%7D%23timecreated%3D%7Bts%20%272010%2D01%2D10%2007%3A02%3A39%27%7D%23hitcount%3D2%23cftoken%3D2af59da685f8a0a1%2D181D504B%2DB9C8%2D47B9%2D5FFC50F14FAF2D99%23cfid%3D12188767%23;expires=Tue, 03-Jan-2040 12:02:39 GMT;path=/ Set-Cookie: CFGLOBALS=urltoken%3DCFID%23%3D12188767%26CFTOKEN%23%3D2af59da685f8a0a1%2D181D504B%2DB9C8%2D47B9%2D5FFC50F14FAF2D99%23lastvisit%3D%7Bts%20%272010%2D01%2D10%2007%3A02%3A39%27%7D%23timecreated%3D%7Bts%20%272010%2D01%2D10%2007%3A02%3A39%27%7D%23hitcount%3D2%23cftoken%3D2af59da685f8a0a1%2D181D504B%2DB9C8%2D47B9%2D5FFC50F14FAF2D99%23cfid%3D12188767%23;expires=Tue, 03-Jan-2040 12:02:39 GMT;path=/ Content-Type: text/html; charset=UTF-8 Content-Length: 245747 Date: Sun, 10 Jan 2010 12:02:48 GMT X-Varnish: 1341696448 1341696422 Age: 9 Via: 1.1 varnish Connection: keep-alive Unsure if there is potential here for someone to pickup another user's session since cookies going out to someone other than the person who originally loaded the page. Potential exists, but haven't seen it yet here. How can I get Varnish to strip those Cookies before it puts it into the cache? Thanks! From frank at vanlingen.name Sun Jan 10 12:05:43 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Sun, 10 Jan 2010 13:05:43 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? In-Reply-To: References: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> Message-ID: <458a97201001100405v12778d0fg2e5d6c85d39e6db1@mail.gmail.com> Thanks David, I do monitor the memory and cpu load but there seem to be no apparent increase when this happens. I should point out that I run this in on a hosted VPS but I am well below their memory and cpu requirements. Varnish does restart itself gracefully when this happens. I guess if prefetching would be available in Varnish (from the information on the varnish site I understood this is not yet available), this might alleviate the problem except that for 2-3 seconds the site is unreachable when it restarts itself (or when the child process is restarted. Frank. On Sun, Jan 10, 2010 at 5:00 AM, David Birdsong wrote: > The parent will restart the child if it becomes unresponsive to pings. This > can happen for multiple reasons.? Do you have historical metrics for the > server that you can examine to see if load goes up or idle cpu goes down or > if memory is consumed? > > (Sorry for the top post, friggin mobile device) > > On Jan 9, 2010 5:34 AM, "Frank van Lingen" wrote: > > Hello, > > After setting up varnish and starting it I looked at the statistics > using varnsihstat. The timer in the left uppper corner seems to be the > uptime since it last started or was flushed. When I loaded some pages, > I can see the cache is working > > But I notice that once every so often the cache seems to either flush > itself or restart. During this 2-3 seconds that this happens I can not > load any pages. > > Is there a default 'cash flush' value that makes this (for me > undesirable) behavior happen? > > I added the example described in > http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching to my > vcl file, but if the cash flushes itself a couple of times per day > then it defeats the purpose. > > I am using varnish-2.0.5-1.el5 on centos5 and use the default.vcl file > with the above longer caching example added to it and ignore swf and > pdf files. I start varnish with 40 MB of cache and test this with a > few html pages and jpgs (less then 15 MB in size). During tests > normally not more than 50% of the cache is used. > > Besides this issue varnish seems to work almost right out of the box. > > Frank. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From pubcrawler.com at gmail.com Sun Jan 10 17:19:44 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sun, 10 Jan 2010 12:19:44 -0500 Subject: Caching pages with URL parameters In-Reply-To: <4c3149fb1001100405q1ecd9ed8j26120f6b9fb099f3@mail.gmail.com> References: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> <4c3149fb1001100331q3091e82xf17357e930a94856@mail.gmail.com> <4c3149fb1001100405q1ecd9ed8j26120f6b9fb099f3@mail.gmail.com> Message-ID: <4c3149fb1001100919x66cba23ep8a97808068bbdf9e@mail.gmail.com> Well, again, I believe I've solved my own problem with my VCL through trial and error :) Managed to get Varnish stripping out the cookies on pages we want to cache and don't care about cookies on. Pretty impressed with Varnish. Is there a place to submit bug tracking items and feature requests for Varnish? -Paul From michael at dynamine.net Sun Jan 10 18:24:04 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Sun, 10 Jan 2010 10:24:04 -0800 Subject: AW: Varnish poisoned cache avoidance In-Reply-To: <4c3149fb1001100307s4364a201n9164abbe1095782d@mail.gmail.com> References: <01cf01ca91db$8c29b790$a47d26b0$@de> <63344.1263118377@critter.freebsd.dk> <4c3149fb1001100307s4364a201n9164abbe1095782d@mail.gmail.com> Message-ID: It has been my experience that anti-DoS is usually easiest to implement at the origin server level, where the request handlers are typically more flexible and easiest to program. Even forking servers like Apache can issue 4xx responses lightning fast, without many resources being consumed. --Michael On Jan 10, 2010, at 3:07 AM, pub crawler wrote: > The antiDoS features would be a good enhancement to Varnish. I > realize it's a very complex and resource intensive thing to approach. > There are likely many other ways some of these functions could be used > in other ways for other solutions. > > In our instance we are not experiencing a true denial of service > attack, but rather are being overwhelmed on our app servers by an high > sustained per second request rate. The antiDoS features would > certainly help us in this situation. > > Is the "delay 100ms" something that could be made available in Varnish > near term? > > I could use this delay in conjunction with IP range of known bots > causing problems or by defining User Agent with this. > > On Sun, Jan 10, 2010 at 5:12 AM, Poul-Henning Kamp wrote: >> In message <01cf01ca91db$8c29b790$a47d26b0$@de>, "Mike Schiessl" writes: >> >>> How can varnishd help me prevent DDOS / DOS attacks ? >> >> Firstly, by being damn fast. >> >> Originally we had some plans for specific antiDoS measures, something >> like: >> >> sub vcl_recv { >> if (client.bandwidth > 100 mbit/s) { >> delay 100ms; >> } >> if (client.missratio > 20%) { >> close; >> } >> } >> >> et cetera... >> >> There are some issues and fine details to doing it, amongst other things >> that we need to have a data structure for the client which survives >> the individual session long enough for it to make any difference >> in the above context. >> >> The trouble of course is that a DDoS cannot be identified by IP#, >> prompting ideas long the lines of >> >> sub vcl_recv { >> if (backend.hitrate < 70%) { >> /* do something... */ >> } >> } >> >> etc. >> >> But before we get anywere, somebody needs to figure out what we >> can do. >> >> Basically any countermeasure has two equally troublesome components: >> >> 1. detection. Knowing that you need to do something. >> >> 2. mitigation. What are we going to do ? >> >> Poul-Henning >> >> >> -- >> 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. >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc >> > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From pubcrawler.com at gmail.com Mon Jan 11 06:37:02 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 11 Jan 2010 01:37:02 -0500 Subject: Varnish logging and data merging Message-ID: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> Alright, up and running with Varnish successfully. Quite happy with Varnish. Our app servers no longer are failing / overwhelmed. Here's our new problem... We have a lot of logging going on in our applications. Logs pages, IP info, time date, URL parameters, etc. Since many pages are being served out of Varnish cache, they don't get logged by our application. How is anyone else out there working around this sort of problem with an existing application? Considering a 1x1 graphic file inclusion into our pages to facilitate logging and ensuring Varnish doesn't cache it. Share your ideas. -Paul From michael at dynamine.net Mon Jan 11 06:38:33 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Sun, 10 Jan 2010 22:38:33 -0800 Subject: Varnish logging and data merging In-Reply-To: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> References: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> Message-ID: Varnish does keep a log if you ask it to. On Jan 10, 2010, at 10:37 PM, pub crawler wrote: > Alright, up and running with Varnish successfully. Quite happy with > Varnish. Our app servers no longer are failing / overwhelmed. > > Here's our new problem... > > We have a lot of logging going on in our applications. Logs pages, IP > info, time date, URL parameters, etc. Since many pages are being > served out of Varnish cache, they don't get logged by our > application. > > How is anyone else out there working around this sort of problem with > an existing application? Considering a 1x1 graphic file inclusion > into our pages to facilitate logging and ensuring Varnish doesn't > cache it. > > Share your ideas. > > -Paul > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From plfgoa at gmail.com Mon Jan 11 08:36:03 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Mon, 11 Jan 2010 14:06:03 +0530 Subject: Purging multiple requests Message-ID: <75cf5801001110036r5f3b2347g832e399cbe16f674@mail.gmail.com> Hi, Is it possible to purge a list of urls in varnish ? Thank you. -Paras -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jan 11 08:42:03 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 08:42:03 +0000 Subject: Purging multiple requests In-Reply-To: Your message of "Mon, 11 Jan 2010 14:06:03 +0530." <75cf5801001110036r5f3b2347g832e399cbe16f674@mail.gmail.com> Message-ID: <80260.1263199323@critter.freebsd.dk> In message <75cf5801001110036r5f3b2347g832e399cbe16f674 at mail.gmail.com>, Paras Fadte writes: >Is it possible to purge a list of urls in varnish ? You can purge them as one regexp using (...|...|...|...|...) syntax -- 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 phk at phk.freebsd.dk Mon Jan 11 08:42:52 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 08:42:52 +0000 Subject: Varnish logging and data merging In-Reply-To: Your message of "Mon, 11 Jan 2010 01:37:02 EST." <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> Message-ID: <80280.1263199372@critter.freebsd.dk> In message <4c3149fb1001102237xaf0d732hb22418df4cf21832 at mail.gmail.com>, pub cr awler writes: >We have a lot of logging going on in our applications. Logs pages, IP >info, time date, URL parameters, etc. Since many pages are being >served out of Varnish cache, they don't get logged by our >application. run varnishncsa or varnishlog to collect your loginfo. -- 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 rtshilston at gmail.com Mon Jan 11 08:42:53 2010 From: rtshilston at gmail.com (Rob S) Date: Mon, 11 Jan 2010 08:42:53 +0000 Subject: Varnish logging and data merging In-Reply-To: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> References: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> Message-ID: <4B4AE48D.2000409@gmail.com> pub crawler wrote: > We have a lot of logging going on in our applications. Logs pages, IP > info, time date, URL parameters, etc. Since many pages are being > served out of Varnish cache, they don't get logged by our > application. > > How is anyone else out there working around this sort of problem with > an existing application? Considering a 1x1 graphic file inclusion > into our pages to facilitate logging and ensuring Varnish doesn't > cache it We've not reported analytics based on raw Apache logs for a long time - they're far too polluted by spiders etc. So, instead, for RSS we use Feedburner (who provide stats, and reduce our traffic load), and for general web access we either use Google Analytics (or commercial alternatives). Google Analytics allows you to add and report on custom parameters, so it is very flexible. However, as you suggested, an alternative is to use a tracking pixel. Depending on how you've previously processed your information, you may find it very useful to encourage Varnish to route all hits to your tracking pixel to a specific server (obviously with failover). This'd save you having to aggregate logs across multiple servers. Rob From phk at phk.freebsd.dk Mon Jan 11 08:48:34 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 08:48:34 +0000 Subject: AW: Varnish poisoned cache avoidance In-Reply-To: Your message of "Sun, 10 Jan 2010 06:07:27 EST." <4c3149fb1001100307s4364a201n9164abbe1095782d@mail.gmail.com> Message-ID: <80349.1263199714@critter.freebsd.dk> In message <4c3149fb1001100307s4364a201n9164abbe1095782d at mail.gmail.com>, pub c rawler writes: >Is the "delay 100ms" something that could be made available in Varnish >near term? You can do it with inline C code already, just call usleep(100000) in your inline C. -- 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 phk at phk.freebsd.dk Mon Jan 11 08:49:36 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 08:49:36 +0000 Subject: varnish suddenly restarting / flushing itself after several hours? In-Reply-To: Your message of "Sat, 09 Jan 2010 14:28:19 +0100." <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> Message-ID: <80372.1263199776@critter.freebsd.dk> In message <458a97201001090528g12f87amfdd974e85f00f288 at mail.gmail.com>, Frank v an Lingen writes: >But I notice that once every so often the cache seems to either flush >itself or restart. During this 2-3 seconds that this happens I can not >load any pages. Check your syslog for panic messages from varnish, this should not happen in regular use. -- 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 pubcrawler.com at gmail.com Mon Jan 11 09:08:46 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 11 Jan 2010 04:08:46 -0500 Subject: Varnish logging and data merging In-Reply-To: <4B4AE48D.2000409@gmail.com> References: <4c3149fb1001102237xaf0d732hb22418df4cf21832@mail.gmail.com> <4B4AE48D.2000409@gmail.com> Message-ID: <4c3149fb1001110108j4e65fd87h7bfc3669ba1cfa59@mail.gmail.com> Thanks again Rob! Tracking pixel it is then :) Off to cobble some code together and test. On Mon, Jan 11, 2010 at 3:42 AM, Rob S wrote: > pub crawler wrote: >> >> We have a lot of logging going on in our applications. Logs pages, IP >> info, time date, URL parameters, etc. ?Since many pages are being >> served out of Varnish cache, ?they don't get logged by our >> application. >> >> How is anyone else out there working around this sort of problem with >> an existing application? ?Considering a 1x1 graphic file inclusion >> into our pages to facilitate logging and ensuring Varnish doesn't >> cache it > > We've not reported analytics based on raw Apache logs for a long time - > they're far too polluted by spiders etc. ?So, instead, for RSS we use > Feedburner (who provide stats, and reduce our traffic load), and for general > web access we either use Google Analytics (or commercial alternatives). > ?Google Analytics allows you to add and report on custom parameters, so it > is very flexible. ?However, as you suggested, an alternative is to use a > tracking pixel. ?Depending on how you've previously processed your > information, you may find it very useful to encourage Varnish to route all > hits to your tracking pixel to a specific server (obviously with failover). > ?This'd save you having to aggregate logs across multiple servers. > > Rob > From phk at phk.freebsd.dk Mon Jan 11 09:16:41 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 09:16:41 +0000 Subject: Bug? Related to ticket 547 In-Reply-To: Your message of "Fri, 08 Jan 2010 17:20:28 EST." Message-ID: <93951.1263201401@critter.freebsd.dk> In message , "Ji m Hayter" writes: >I'm sorry, but I'm not sure how/where to report this. > >I'm running varnish-2.0.6 on Solaris 10. I had the issue noted in >http://varnish.projects.linpro.no/ticket/547 when testing 2.0.5, which >was fixed in 2.0.6. I just tried 2.0.6 on a production system and ran >into the issues noted in the varnishd output below. It appears to be a >similar call to setsockopt to the one noted in ticket 547. This error >occurred every 3-6 minutes. It seems to be Solaris returning EBADF if the connection is closed before it gets around to do something to it. Can you open a ticket with this report, I'll try to find a way to add checks for this. Poul-Henning > >Any input is welcomed. We had hoped to run this on one of our >production web servers all weekend as a prelude to putting it into full >production. > >Thanks, >Jim > >Varnishd output >--------------- >... >Child (21784) said ", 1, 3) >Child (21784) not responding to ping, killing it. >Child (21784) not responding to ping, killing it. >Child (21784) not responding to ping, killing it. >Child (21784) died signal=6 (core dumped) >Child (21784) Panic message: Assert error in VCA_Prep(), >cache_acceptor.c line 148: > Condition((setsockopt(sp->fd, 0xffff, 0x0080, &linger, sizeof linger)) >== 0) not true. >errno = 9 (Bad file number) >thread = (cache-worker) >sp = 8f29974 { > fd = 84, id = 84, xid = 0, > client = 66.68.180.213:2086, > step = STP_FIRST, > handling = error, > restarts = 0, esis = 0 > ws = 8f299c0 { > id = "sess", > {s,f,r,e} = {8f2a470,+19,0,+32768}, > }, > http[req] = { > ws = 0[] > }, > worker = 731cdee0 >}, > > >Child cleanup complete >child (21816) Started >Child (21816) said Closed fds: 4 5 25 26 28 29 >... >_______________________________________________ >varnish-misc mailing list >varnish-misc at projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-misc > -- 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 phk at phk.freebsd.dk Mon Jan 11 09:21:17 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 09:21:17 +0000 Subject: Question from Dec. 2009: "still using cache when fetching content" In-Reply-To: Your message of "Fri, 08 Jan 2010 16:20:46 EST." Message-ID: <95553.1263201677@critter.freebsd.dk> In message , John Norman writes: >----- >Is it possible to make Varnish sending the cache content at the same >time it is fetching from the backend ? It's in the plans, but there are some code that needs to be smartend up first, so it will take a bit of time. -- 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 pubcrawler.com at gmail.com Mon Jan 11 09:33:18 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 11 Jan 2010 04:33:18 -0500 Subject: Combining req.url matches Message-ID: <4c3149fb1001110133x2ba524e7j58844b059a29f966@mail.gmail.com> I have a list req.url matches that are duplicative other than the file to match. What is the format to combine these? For instance: if (req.url ~ "photoupload.cfm") {pass;} if (req.url ~ "logoupload.cfm") {pass;} Is there a prescribed way to combine that into one line? -Paul From slink at schokola.de Mon Jan 11 09:59:20 2010 From: slink at schokola.de (Nils Goroll) Date: Mon, 11 Jan 2010 10:59:20 +0100 Subject: Combining req.url matches In-Reply-To: <4c3149fb1001110133x2ba524e7j58844b059a29f966@mail.gmail.com> References: <4c3149fb1001110133x2ba524e7j58844b059a29f966@mail.gmail.com> Message-ID: <4B4AF678.5000401@schokola.de> Hi "Pub Crawler", > For instance: > if (req.url ~ "photoupload.cfm") {pass;} > if (req.url ~ "logoupload.cfm") {pass;} > > Is there a prescribed way to combine that into one line? Firstly, you should note that the argument to the ~ operator is a regexp, so if you mean a literal dot, it's \. . You can also group subexpressions like this: if (req.url ~ "(photo|logo)upload\.cfm") {pass;} Nils From pubcrawler.com at gmail.com Mon Jan 11 10:33:17 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 11 Jan 2010 05:33:17 -0500 Subject: Combining req.url matches In-Reply-To: <4B4AF678.5000401@schokola.de> References: <4c3149fb1001110133x2ba524e7j58844b059a29f966@mail.gmail.com> <4B4AF678.5000401@schokola.de> Message-ID: <4c3149fb1001110233m2209b265g544a45c24a92d8cf@mail.gmail.com> Thanks Nils, The backslash part I hadn't got before this- makes sense. I used a poor example of a list of files for combination. Your solution got me thinking about our filenaming conventions going forward though. Let's try this one - can these somehow be combined into one? if (req.url ~ "systemstatus\.cfm") {lookup;} if (req.url ~ "index\.cfm") {lookup;} -Paul On Mon, Jan 11, 2010 at 4:59 AM, Nils Goroll wrote: > Hi "Pub Crawler", > >> For instance: >> if (req.url ~ "photoupload.cfm") {pass;} >> if (req.url ~ "logoupload.cfm") {pass;} >> >> Is there a prescribed way to combine that into one line? > > Firstly, you should note that the argument to the ~ operator is a regexp, so > if you mean a literal dot, it's \. . You can also group subexpressions like > this: > > if (req.url ~ "(photo|logo)upload\.cfm") {pass;} > > Nils > From robert at shilston.com Sat Jan 9 10:48:27 2010 From: robert at shilston.com (Robert Shilston) Date: Sat, 09 Jan 2010 10:48:27 +0000 Subject: VCL config file for specific URLs In-Reply-To: <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> References: <4c3149fb1001082309j280b7286i5a05ab0be13312a7@mail.gmail.com> <4B4859B7.9040700@gmail.com> <4c3149fb1001090240l53a26f5eg9452abdbdd820d45@mail.gmail.com> Message-ID: <4B485EFB.4050001@shilston.com> In our vcl_recv, we use things like: if (req.url ~ "wp-admin") { pass; } if (req.url ~ "/blog/wp-login.php") { pipe; } // Don't cache from some IPs if (client.ip == "1.2.3.4") { pass; } Is that any help? Rob pub crawler wrote: > Thanks for your input Rob. > > JPEG's, GIFs, etc. are all fine to cache, as they are very static in > nature in our environment. > Currently we have Varnish setup to cache: > ico|html|htm|bmp|png|gif|jpg|jpeg|swf|css|js|rss|xml > > Our issue is our app servers get overwhelmed, become a large > bottleneck and eventually fail under high load. We can add more > servers in horizontal scaling mode, but creates more wasted power, > more machines to maintain, etc. Our need it to address raised site > load mostly due to search spiders that are out of control but > necessary. > > So we thought getting Varnish to cache all these dynamic pages would > alleviate load on our application servers. > > Essentially, it is fine for Varnish to cache all of our ColdFusion > pages (.cfm), except a handful of pages like these: > http://www.website.com/Template/members/ > http://www.website.com/Template/dsp_addreview.cfm/flat/ID=157 > etc. > > Any idea of how to accomplish the cache exception of these handful of pages? > > > >> I'm not sure of the best way to supply a large list of URLs to pipe, but I'd >> suggest that you think about turning the logic around. I don't know the >> nature of your site, but presumably it's safe to cache all JPEGs and >> similar. How much load would be alleviated by caching everything whose >> content type is not text/html? >> >> Then, for text/html, is it possible for you to edit your backend site and >> add a header such as "X-Is-Cacheable: yes" in your index.cfm and Review.cfm? >> Then, in vcl_fetch, you'd do something like: >> >> if content-type = text/html >> if X-Is-Cacheable = yes >> cache this >> else >> don't cache >> end if >> else >> cache this >> end if >> >> >> You might find this approach simpler than writing a big long list of pages >> not to cache. >> >> >> Rob >> >> > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From tfheen at redpill-linpro.com Mon Jan 11 10:56:55 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 11 Jan 2010 11:56:55 +0100 Subject: Caching pages with URL parameters In-Reply-To: <4c3149fb1001100919x66cba23ep8a97808068bbdf9e@mail.gmail.com> (pub crawler's message of "Sun, 10 Jan 2010 12:19:44 -0500") References: <4c3149fb1001090742o44dfcfb0wced87de39e6cf5ef@mail.gmail.com> <4c3149fb1001100331q3091e82xf17357e930a94856@mail.gmail.com> <4c3149fb1001100405q1ecd9ed8j26120f6b9fb099f3@mail.gmail.com> <4c3149fb1001100919x66cba23ep8a97808068bbdf9e@mail.gmail.com> Message-ID: <87hbqsnc3s.fsf@qurzaw.linpro.no> ]] pub crawler | Well, again, I believe I've solved my own problem with my VCL through | trial and error :) :-) sub vcl_fetch { unset req.http.set-cookie; } is what you were looking for, potentially with an appropriate URL check. | Is there a place to submit bug tracking items and feature requests for Varnish? http://varnish.projects.linpro.no/ has a bug tracker. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 11 11:02:05 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 11 Jan 2010 12:02:05 +0100 Subject: Combining req.url matches In-Reply-To: <4c3149fb1001110233m2209b265g544a45c24a92d8cf@mail.gmail.com> (pub crawler's message of "Mon, 11 Jan 2010 05:33:17 -0500") References: <4c3149fb1001110133x2ba524e7j58844b059a29f966@mail.gmail.com> <4B4AF678.5000401@schokola.de> <4c3149fb1001110233m2209b265g544a45c24a92d8cf@mail.gmail.com> Message-ID: <87d41gnbv6.fsf@qurzaw.linpro.no> ]] pub crawler | Let's try this one - can these somehow be combined into one? | | if (req.url ~ "systemstatus\.cfm") {lookup;} | if (req.url ~ "index\.cfm") {lookup;} if (req.url ~ "(index|systemstatus)[.]cfm") { return(lookup);} ? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From frank at vanlingen.name Mon Jan 11 11:22:27 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Mon, 11 Jan 2010 12:22:27 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? In-Reply-To: <80372.1263199776@critter.freebsd.dk> References: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> <80372.1263199776@critter.freebsd.dk> Message-ID: <458a97201001110322i1bab9e54w8f3d84cb47c0142c@mail.gmail.com> Below the last messages. These are two restarts within the hour, but most of the times it seems to run for several hours 4-8 without problems. I could not find any panic messages. I found some messages in the varnish mailing list regarding this but the only ones I found where 'died signal=6' JJan 10 18:17:22 server1 varnishd[14016]: Child (23771) not responding to ping, killing it. Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) not responding to ping, killing it. Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) died signal=3 Jan 10 18:17:23 server1 varnishd[14016]: child (25855) Started Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Closed fds: 4 5 9 10 12 13 Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Child starts Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said managed to mmap 41943040 bytes of 41943040 Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Ready Jan 10 18:49:43 server1 varnishd[14016]: Child (25855) not responding to ping, killing it. Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) not responding to ping, killing it. Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) died signal=3 Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Closed fds: 4 5 9 10 12 13 Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Child starts Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said managed to mmap 41943040 bytes of 41943040 Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Ready Jan 10 20:13:43 server1 varnishd[14016]: Child (5186) not responding to ping, killing it. Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) not responding to ping, killing it. Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) died signal=3 Jan 10 20:13:44 server1 varnishd[14016]: child (13400) Started Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Closed fds: 4 5 9 10 12 13 Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Child starts Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said managed to mmap 41943040 bytes of 41943040 Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Ready Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started -------------------------------------------- Frank van Lingen email : frank at vanlingen.name VOIP (skype) : fvlingen IM (yahoo,hotmail) : fvlingen IM (AIM) : frank at vanlingen.name URL : http://vanlingen.name LinkedIn : fvlingen ------------------------------------------- On Mon, Jan 11, 2010 at 9:49 AM, Poul-Henning Kamp wrote: > In message <458a97201001090528g12f87amfdd974e85f00f288 at mail.gmail.com>, Frank v > an Lingen writes: > >>But I notice that once every so often the cache seems to either flush >>itself or restart. During this 2-3 seconds that this happens I can not >>load any pages. > > Check your syslog for panic messages from varnish, this should not > happen in regular use. > > -- > 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 frank at vanlingen.name Mon Jan 11 11:38:28 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Mon, 11 Jan 2010 12:38:28 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? In-Reply-To: <458a97201001110322i1bab9e54w8f3d84cb47c0142c@mail.gmail.com> References: <458a97201001090528g12f87amfdd974e85f00f288@mail.gmail.com> <80372.1263199776@critter.freebsd.dk> <458a97201001110322i1bab9e54w8f3d84cb47c0142c@mail.gmail.com> Message-ID: <458a97201001110338j587526fei848a9168b148eacb@mail.gmail.com> >From the varnish documentation I see that the threadpool max has a default of 1000 as I am doing some test on a (smal) VPS I reduced this number to 40 just to see if this might cause the problem. Frank. On Mon, Jan 11, 2010 at 12:22 PM, Frank van Lingen wrote: > Below the last messages. These are two restarts within the hour, but > most of the times it seems to run for several hours 4-8 without > problems. ?I could not find any panic messages. I found some messages > in the varnish mailing list regarding this but the only ones I found > where 'died signal=6' > > JJan 10 18:17:22 server1 varnishd[14016]: Child (23771) not responding > to ping, killing it. > Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) not responding > to ping, killing it. > Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) died signal=3 > Jan 10 18:17:23 server1 varnishd[14016]: child (25855) Started > Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Closed > fds: 4 5 9 10 12 13 > Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Child starts > Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said managed to > mmap 41943040 bytes of 41943040 > Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Ready > Jan 10 18:49:43 server1 varnishd[14016]: Child (25855) not responding > to ping, killing it. > Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) not responding > to ping, killing it. > Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) died signal=3 > Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started > Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Closed fds: > 4 5 9 10 12 13 > Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Child starts > Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said managed to > mmap 41943040 bytes of 41943040 > Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Ready > Jan 10 20:13:43 server1 varnishd[14016]: Child (5186) not responding > to ping, killing it. > Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) not responding > to ping, killing it. > Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) died signal=3 > Jan 10 20:13:44 server1 varnishd[14016]: child (13400) Started > Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Closed > fds: 4 5 9 10 12 13 > Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Child starts > Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said managed to > mmap 41943040 bytes of 41943040 > Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Ready > > Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started > > -------------------------------------------- > Frank van Lingen > email : frank at vanlingen.name > VOIP (skype) : fvlingen > IM (yahoo,hotmail) : fvlingen > IM (AIM) : frank at vanlingen.name > URL : http://vanlingen.name > LinkedIn : fvlingen > ------------------------------------------- > > > > On Mon, Jan 11, 2010 at 9:49 AM, Poul-Henning Kamp wrote: >> In message <458a97201001090528g12f87amfdd974e85f00f288 at mail.gmail.com>, Frank v >> an Lingen writes: >> >>>But I notice that once every so often the cache seems to either flush >>>itself or restart. During this 2-3 seconds that this happens I can not >>>load any pages. >> >> Check your syslog for panic messages from varnish, this should not >> happen in regular use. >> >> -- >> 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 maurice.ro at gmail.com Mon Jan 11 11:57:27 2010 From: maurice.ro at gmail.com (Maurice) Date: Mon, 11 Jan 2010 13:57:27 +0200 Subject: Strange 302 redirect to google.com Message-ID: <41fe27a21001110357m3ac09688vdc4269bb16147715@mail.gmail.com> hello all, i have a problem with a strange 302 redirect to google.(com|ro) just by visiting http://dir.acasa.ro on google chrome and ie, on firefox everything works fine. the strange part is that on certain ips (not listed in the vcl so nothing fancy) the page works on all browsers. is it possible that varnish caches the 302 redirects and on a "get index" request and spits out 302? but why redirect to google? here are a few lines from the access_log: ... 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:03:52 +0200] "GET /redirect?id=16360 HTTP/1.1" 302 62 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:04:20 +0200] "GET /Educatie/Referate--397.html HTTP/1.1" 200 49755 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:04:58 +0200] "GET /redirect?id=13843 HTTP/1.1" 302 65 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:08:35 +0200] "GET /redirect?id=19857 HTTP/1.1" 302 62 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 89.34.231.41, 127.0.0.1 - - [11/Jan/2010:04:09:33 +0200] "GET /Sanatate/Clinici/Stomatologie--420.html HTTP/1.1" 200 79553 " http://www.google.ro/search?hl=ro&q=tratament+stomatologic+laser+pret&btnG=C%C4%83utare&meta=&aq=null&oq=tratament+stomatologic+laser" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; SIMBAR={785649A2-9974-4B8F-89B5-20803AAF8568}; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; FDM; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:10:26 +0200] "GET /redirect?id=2329 HTTP/1.1" 302 63 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:12:17 +0200] "GET /redirect?id=12157 HTTP/1.1" 302 58 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:13:15 +0200] "GET /redirect?id=23277 HTTP/1.1" 302 60 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 65.55.51.112, 127.0.0.1 - - [11/Jan/2010:04:13:33 +0200] "GET /redirect?id=11030 HTTP/1.1" 302 67 "-" "msnbot/2.0b (+ http://search.msn.com/msnbot.htm)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:15:07 +0200] "GET /redirect?id=19226 HTTP/1.1" 302 74 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:15:07 +0200] "GET /redirect?id=11889 HTTP/1.1" 302 68 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 65.55.207.78, 127.0.0.1 - - [11/Jan/2010:04:17:15 +0200] "GET /redirect?id=5437 HTTP/1.1" 302 56 "-" "msnbot/2.0b (+ http://search.msn.com/msnbot.htm)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:17:26 +0200] "GET /redirect?id=16888 HTTP/1.1" 302 73 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:17:46 +0200] "GET /Regional/Diaspora--84.html HTTP/1.1" 200 55174 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:17:49 +0200] "GET /redirect?id=18681 HTTP/1.1" 302 63 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:18:06 +0200] "GET /redirect?id=18606 HTTP/1.1" 302 65 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 66.249.65.54, 127.0.0.1 - - [11/Jan/2010:04:19:11 +0200] "GET /Afaceri_si_economie/Financiar_si_investitii/Asigurari--291.html HTTP/1.1" 200 63381 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; + http://www.google.com/bot.html)" 91.64.166.114, 127.0.0.1 - - [11/Jan/2010:04:19:33 +0200] "GET /Afaceri_si_economie/Forum_uri--367.html HTTP/1.0" 200 73821 " http://dir.acasa.ro/Afaceri_si_economie/Forum_uri--367.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Avant Browser [avantbrowser.com]; Hotbar 4.4.5.0)" 91.64.166.114, 127.0.0.1 - - [11/Jan/2010:04:19:34 +0200] "GET /Afaceri_si_economie/Forum_uri--367/propune.html HTTP/1.0" 200 19848 " http://dir.acasa.ro/Afaceri_si_economie/Forum_uri--367/propune.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Avant Browser [ avantbrowser.com]; Hotbar 4.4.5.0)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:20:27 +0200] "GET /redirect?id=8144 HTTP/1.1" 302 60 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" ... 77.209.46.58, 127.0.0.1 - - [11/Jan/2010:04:40:10 +0200] "GET /Regional/Ardeal--79.html HTTP/1.1" 200 128013 " http://search.conduit.com/Results.aspx?q=bicaz+maramures+video&hl=es&SelfSearch=1&ctid=CT1854633&octid=CT1854633&start=110" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)" 65.55.106.230, 127.0.0.1 - - [11/Jan/2010:04:41:43 +0200] "GET /redirect?id=17672 HTTP/1.1" 302 65 "-" "msnbot/2.0b (+ http://search.msn.com/msnbot.htm)" .249.65.54, 127.0.0.1 - - [11/Jan/2010:04:42:07 +0200] "GET /redirect?id=10057 HTTP/1.1" 302 64 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:42:20 +0200] "GET /Institutii--24.html HTTP/1.1" 200 18600 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" 67.195.111.158, 127.0.0.1 - - [11/Jan/2010:04:42:38 +0200] "GET /redirect?id=3511 HTTP/1.1" 302 63 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)" ... i've attached my default.vcl and "a few" lines from varnishlog centos 5.4 - 2.6.18-164.9.1.el5 httpd-2.2.3-31.el5.centos.2 resin-3.1.9 varnish-2.0.5-1.el5 varnish-libs-2.0.5-1.el5 thanks! -- Maurice -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ##### varnishlog -d -c -o TxStatus 302 42 SessionOpen c 194.60.106.5 13618 :80 42 ReqStart c 194.60.106.5 13618 366310326 42 RxRequest c GET 42 RxURL c /post?id=-1&zi=2&buton=Afiseaza 42 RxProtocol c HTTP/1.0 42 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, applicati 42 RxHeader c Referer: http://tv.acasa.ro/post?id=66&zi=3&buton=Afiseaza 42 RxHeader c Accept-Language: en-us 42 RxHeader c Accept-Encoding: gzip, deflate 42 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 3.0.04506.30; .NET CLR 2.0.5 0727; MS-RTC EA 2) 42 RxHeader c Host: tv.acasa.ro 42 RxHeader c Cookie: POPUPCHECK=1263294371928; trafic_h=668a2ff70l6fbe4a6dff7dea14f58330*1263207988*acasa.ro*1263207988*1263207988*1; trafic_v=1; __ut ma=240209555.189825096.1263207988.1263207988.1263207988.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.126320 42 RxHeader c Via: 1.1 cgli129a.eu.unilever.com:8080 (squid/2.6.STABLE21) 42 RxHeader c Cache-Control: max-age=259200 42 VCL_call c recv 42 VCL_acl c NO_MATCH nocache 42 VCL_return c pass 42 VCL_call c pass pass 42 Backend c 118 default default 42 ObjProtocol c HTTP/1.1 42 ObjStatus c 302 42 ObjResponse c Found 42 ObjHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 42 ObjHeader c Server: Apache 42 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 42 ObjHeader c Expires: 0 42 ObjHeader c Cache-Control: no-cache 42 ObjHeader c Pragma: no-cache 42 ObjHeader c Content-Language: ro 42 ObjHeader c Location: http://tv.acasa.ro/tv/error 42 ObjHeader c Content-Type: text/html; charset=UTF-8 42 TTL c 366310326 RFC 120 1263208903 0 0 0 0 42 VCL_call c fetch pass 42 Length c 65 42 VCL_call c deliver deliver 42 TxProtocol c HTTP/1.1 42 TxStatus c 302 42 TxResponse c Found 42 TxHeader c Server: Apache 42 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 42 TxHeader c Expires: 0 42 TxHeader c Cache-Control: no-cache 42 TxHeader c Pragma: no-cache 42 TxHeader c Content-Language: ro 42 TxHeader c Location: http://tv.acasa.ro/tv/error 42 TxHeader c Content-Type: text/html; charset=UTF-8 42 TxHeader c Content-Length: 65 42 TxHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 42 TxHeader c X-Varnish: 366310326 42 TxHeader c Age: 0 42 TxHeader c Connection: close 42 TxHeader c Via: varnish 42 TxHeader c X-Cache: MISS 42 ReqEnd c 366310326 1263208903.838655949 1263208903.969909906 0.002033949 0.131188154 0.000065804 120 SessionOpen c 216.129.119.11 40089 :80 120 ReqStart c 216.129.119.11 40089 366311845 120 RxRequest c GET 120 RxURL c /program-Cartoon_Network/2008-07-31/The-Amazing-Adrenalini-Brothers-4195409-r53.html 120 RxProtocol c HTTP/1.0 120 RxHeader c Connection: close 120 RxHeader c Host: tv.acasa.ro 120 RxHeader c Accept-Encoding: gzip 120 RxHeader c User-Agent: Mozilla/5.0 (Twiceler-0.9 http://www.cuil.com/twiceler/robot.html) 120 RxHeader c Accept: text/html, */* 120 VCL_call c recv 120 VCL_acl c NO_MATCH nocache 120 VCL_return c lookup 120 VCL_call c hash hash 120 VCL_call c miss fetch 120 Backend c 121 default default 120 ObjProtocol c HTTP/1.1 120 ObjStatus c 302 120 ObjResponse c Found 120 ObjHeader c Date: Mon, 11 Jan 2010 11:22:12 GMT 120 ObjHeader c Server: Apache 120 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 120 ObjHeader c Expires: 0 120 ObjHeader c Cache-Control: no-cache 120 ObjHeader c Pragma: no-cache 120 ObjHeader c Content-Language: ro 120 ObjHeader c Location: http://tv.acasa.ro/tv/index 120 ObjHeader c Content-Type: text/html; charset=UTF-8 120 TTL c 366311845 RFC 120 1263208932 0 0 0 0 120 VCL_call c fetch pass 120 Length c 65 120 VCL_call c deliver deliver 120 TxProtocol c HTTP/1.1 120 TxStatus c 302 120 TxResponse c Found 120 TxHeader c Server: Apache 120 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 120 TxHeader c Expires: 0 120 TxHeader c Cache-Control: no-cache 120 TxHeader c Pragma: no-cache 120 TxHeader c Content-Language: ro 120 TxHeader c Location: http://tv.acasa.ro/tv/index 120 TxHeader c Content-Type: text/html; charset=UTF-8 120 TxHeader c Content-Length: 65 120 TxHeader c Date: Mon, 11 Jan 2010 11:22:12 GMT 120 TxHeader c X-Varnish: 366311845 120 TxHeader c Age: 0 120 TxHeader c Connection: close 120 TxHeader c Via: varnish 120 TxHeader c X-Cache: MISS 120 ReqEnd c 366311845 1263208932.224442959 1263208932.402268887 0.000064850 0.177715063 0.000110865 88 SessionOpen c 67.195.115.177 57795 :80 88 ReqStart c 67.195.115.177 57795 366311992 88 RxRequest c GET 88 RxURL c /program-Antena1/2008-12-15/Scene-de-caznicie-5223267-r17.html 88 RxProtocol c HTTP/1.0 88 RxHeader c Host: tv.acasa.ro 88 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 88 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 88 RxHeader c Accept-Language: en-us,en;q=0.5 88 RxHeader c Accept-Encoding: gzip,deflate 88 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 88 RxHeader c X-LLF-Mime-Type: true 88 VCL_call c recv 88 VCL_acl c NO_MATCH nocache 88 VCL_return c lookup 88 VCL_call c hash hash 88 VCL_call c miss fetch 88 Backend c 91 default default 88 ObjProtocol c HTTP/1.1 88 ObjStatus c 302 88 ObjResponse c Found 88 ObjHeader c Date: Mon, 11 Jan 2010 11:22:13 GMT 88 ObjHeader c Server: Apache 88 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 ObjHeader c Expires: 0 88 ObjHeader c Cache-Control: no-cache 88 ObjHeader c Pragma: no-cache 88 ObjHeader c Content-Language: ro 88 ObjHeader c Location: http://tv.acasa.ro/tv/index 88 ObjHeader c Content-Type: text/html; charset=UTF-8 88 TTL c 366311992 RFC 120 1263208936 0 0 0 0 88 VCL_call c fetch pass 88 Length c 65 88 VCL_call c deliver deliver 88 TxProtocol c HTTP/1.1 88 TxStatus c 302 88 TxResponse c Found 88 TxHeader c Server: Apache 88 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 TxHeader c Expires: 0 88 TxHeader c Cache-Control: no-cache 88 TxHeader c Pragma: no-cache 88 TxHeader c Content-Language: ro 88 TxHeader c Location: http://tv.acasa.ro/tv/index 88 TxHeader c Content-Type: text/html; charset=UTF-8 88 TxHeader c Content-Length: 65 88 TxHeader c Date: Mon, 11 Jan 2010 11:22:16 GMT 88 TxHeader c X-Varnish: 366311992 88 TxHeader c Age: 0 88 TxHeader c Connection: close 88 TxHeader c Via: varnish 88 TxHeader c X-Cache: MISS 88 ReqEnd c 366311992 1263208933.540297031 1263208936.291946888 0.000045061 2.751549006 0.000100851 37 SessionOpen c 67.195.115.177 57937 :80 37 ReqStart c 67.195.115.177 57937 366312171 37 RxRequest c GET 37 RxURL c /program-TVR_International/2009-12-04/Tu-decizi-pentru-Romania-8547994-r15.html 37 RxProtocol c HTTP/1.0 37 RxHeader c Host: tv.acasa.ro 37 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 37 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 37 RxHeader c Accept-Language: en-us,en;q=0.5 37 RxHeader c Accept-Encoding: gzip,deflate 37 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 37 RxHeader c X-LLF-Mime-Type: true 37 VCL_call c recv 37 VCL_acl c NO_MATCH nocache 37 VCL_return c lookup 37 VCL_call c hash hash 37 VCL_call c miss fetch 37 Backend c 120 default default 37 ObjProtocol c HTTP/1.1 37 ObjStatus c 302 37 ObjResponse c Found 37 ObjHeader c Date: Mon, 11 Jan 2010 11:22:15 GMT 37 ObjHeader c Server: Apache 37 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 ObjHeader c Expires: 0 37 ObjHeader c Cache-Control: no-cache 37 ObjHeader c Pragma: no-cache 37 ObjHeader c Content-Language: ro 37 ObjHeader c Location: http://tv.acasa.ro/tv/index 37 ObjHeader c Content-Type: text/html; charset=UTF-8 37 TTL c 366312171 RFC 120 1263208936 0 0 0 0 37 VCL_call c fetch pass 37 Length c 65 37 VCL_call c deliver deliver 37 TxProtocol c HTTP/1.1 37 TxStatus c 302 37 TxResponse c Found 37 TxHeader c Server: Apache 37 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 TxHeader c Expires: 0 37 TxHeader c Cache-Control: no-cache 37 TxHeader c Pragma: no-cache 37 TxHeader c Content-Language: ro 37 TxHeader c Location: http://tv.acasa.ro/tv/index 37 TxHeader c Content-Type: text/html; charset=UTF-8 37 TxHeader c Content-Length: 65 37 TxHeader c Date: Mon, 11 Jan 2010 11:22:16 GMT 37 TxHeader c X-Varnish: 366312171 37 TxHeader c Age: 0 37 TxHeader c Connection: close 37 TxHeader c Via: varnish 37 TxHeader c X-Cache: MISS 37 ReqEnd c 366312171 1263208935.506747007 1263208936.349788904 0.000027895 0.842972040 0.000069857 100 SessionOpen c 67.195.115.177 58940 :80 100 ReqStart c 67.195.115.177 58940 366312985 100 RxRequest c GET 100 RxURL c /tv/film?id=5441832&newsletter=1 100 RxProtocol c HTTP/1.0 100 RxHeader c Host: tv.acasa.ro 100 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 100 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 100 RxHeader c Accept-Language: en-us,en;q=0.5 100 RxHeader c Accept-Encoding: gzip,deflate 100 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 100 RxHeader c X-LLF-Mime-Type: true 100 VCL_call c recv 100 VCL_acl c NO_MATCH nocache 100 VCL_return c lookup 100 VCL_call c hash hash 100 VCL_call c miss fetch 100 Backend c 153 default default 100 ObjProtocol c HTTP/1.1 100 ObjStatus c 302 100 ObjResponse c Found 100 ObjHeader c Date: Mon, 11 Jan 2010 11:22:27 GMT 100 ObjHeader c Server: Apache 100 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 ObjHeader c Expires: 0 100 ObjHeader c Cache-Control: no-cache 100 ObjHeader c Pragma: no-cache 100 ObjHeader c Content-Language: ro 100 ObjHeader c Location: http://tv.acasa.ro/tv/index 100 ObjHeader c Content-Type: text/html; charset=UTF-8 100 TTL c 366312985 RFC 120 1263208950 0 0 0 0 100 VCL_call c fetch pass 100 Length c 65 100 VCL_call c deliver deliver 100 TxProtocol c HTTP/1.1 100 TxStatus c 302 100 TxResponse c Found 100 TxHeader c Server: Apache 100 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 TxHeader c Expires: 0 100 TxHeader c Cache-Control: no-cache 100 TxHeader c Pragma: no-cache 100 TxHeader c Content-Language: ro 100 TxHeader c Location: http://tv.acasa.ro/tv/index 100 TxHeader c Content-Type: text/html; charset=UTF-8 100 TxHeader c Content-Length: 65 100 TxHeader c Date: Mon, 11 Jan 2010 11:22:30 GMT 100 TxHeader c X-Varnish: 366312985 100 TxHeader c Age: 0 100 TxHeader c Connection: close 100 TxHeader c Via: varnish 100 TxHeader c X-Cache: MISS 100 ReqEnd c 366312985 1263208947.814032078 1263208950.822393894 0.000048161 3.008318901 0.000042915 20 SessionOpen c 67.195.115.177 59716 :80 20 ReqStart c 67.195.115.177 59716 366313640 20 RxRequest c GET 20 RxURL c /program-Viasat_History/2010-01-07/Reinventatorii-8699251-r40.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 59 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:22:37 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366313640 RFC 120 1263208957 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:22:37 GMT 20 TxHeader c X-Varnish: 366313640 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366313640 1263208957.484276056 1263208957.635644913 0.000074148 0.151289940 0.000078917 99 ReqStart c 66.249.65.57 53321 366314180 99 RxRequest c GET 99 RxURL c /program-Minimax/2009-08-03/Koala-Brothers-7336748-r23.html 99 RxProtocol c HTTP/1.1 99 RxHeader c Host: tv.acasa.ro 99 RxHeader c Connection: Keep-alive 99 RxHeader c Accept: */* 99 RxHeader c From: googlebot(at)googlebot.com 99 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 99 RxHeader c Accept-Encoding: gzip,deflate 99 VCL_call c recv 99 VCL_acl c NO_MATCH nocache 99 VCL_return c lookup 99 VCL_call c hash hash 99 VCL_call c miss fetch 99 Backend c 131 default default 99 ObjProtocol c HTTP/1.1 99 ObjStatus c 302 99 ObjResponse c Found 99 ObjHeader c Date: Mon, 11 Jan 2010 11:22:45 GMT 99 ObjHeader c Server: Apache 99 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 99 ObjHeader c Expires: 0 99 ObjHeader c Cache-Control: no-cache 99 ObjHeader c Pragma: no-cache 99 ObjHeader c Content-Language: ro 99 ObjHeader c Location: http://tv.acasa.ro/tv/index 99 ObjHeader c Content-Type: text/html; charset=UTF-8 99 TTL c 366314180 RFC 120 1263208967 0 0 0 0 99 VCL_call c fetch pass 99 Length c 65 99 VCL_call c deliver deliver 99 TxProtocol c HTTP/1.1 99 TxStatus c 302 99 TxResponse c Found 99 TxHeader c Server: Apache 99 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 99 TxHeader c Expires: 0 99 TxHeader c Cache-Control: no-cache 99 TxHeader c Pragma: no-cache 99 TxHeader c Content-Language: ro 99 TxHeader c Location: http://tv.acasa.ro/tv/index 99 TxHeader c Content-Type: text/html; charset=UTF-8 99 TxHeader c Content-Length: 65 99 TxHeader c Date: Mon, 11 Jan 2010 11:22:47 GMT 99 TxHeader c X-Varnish: 366314180 99 TxHeader c Age: 0 99 TxHeader c Connection: keep-alive 99 TxHeader c Via: varnish 99 TxHeader c X-Cache: MISS 99 ReqEnd c 366314180 1263208965.381400108 1263208967.220005989 3.494348049 1.838551998 0.000053883 48 SessionOpen c 66.249.65.54 33653 :80 48 ReqStart c 66.249.65.54 33653 366314365 48 RxRequest c GET 48 RxURL c /redirect?id=3424 48 RxProtocol c HTTP/1.1 48 RxHeader c Host: dir.acasa.ro 48 RxHeader c Connection: Keep-alive 48 RxHeader c Accept: */* 48 RxHeader c From: googlebot(at)googlebot.com 48 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 48 RxHeader c Accept-Encoding: gzip,deflate 48 VCL_call c recv 48 VCL_acl c NO_MATCH nocache 48 VCL_return c lookup 48 VCL_call c hash hash 48 VCL_call c miss fetch 48 Backend c 49 default default 48 ObjProtocol c HTTP/1.1 48 ObjStatus c 302 48 ObjResponse c Found 48 ObjHeader c Date: Mon, 11 Jan 2010 11:22:47 GMT 48 ObjHeader c Server: Apache 48 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 48 ObjHeader c Expires: 0 48 ObjHeader c Cache-Control: no-cache 48 ObjHeader c Pragma: no-cache 48 ObjHeader c Content-Language: ro 48 ObjHeader c Location: http://www.hemelbeauty.com 48 ObjHeader c Set-Cookie: void=qepd8-UNFGeNnFAV; domain=.acasa.ro; path=/ 48 ObjHeader c Content-Type: text/html; charset=utf-8 48 TTL c 366314365 RFC 120 1263208968 0 0 0 0 48 VCL_call c fetch pass 48 Length c 64 48 VCL_call c deliver deliver 48 TxProtocol c HTTP/1.1 48 TxStatus c 302 48 TxResponse c Found 48 TxHeader c Server: Apache 48 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 48 TxHeader c Expires: 0 48 TxHeader c Cache-Control: no-cache 48 TxHeader c Pragma: no-cache 48 TxHeader c Content-Language: ro 48 TxHeader c Location: http://www.hemelbeauty.com 48 TxHeader c Set-Cookie: void=qepd8-UNFGeNnFAV; domain=.acasa.ro; path=/ 48 TxHeader c Content-Type: text/html; charset=utf-8 48 TxHeader c Content-Length: 64 48 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 48 TxHeader c X-Varnish: 366314365 48 TxHeader c Age: 0 48 TxHeader c Connection: keep-alive 48 TxHeader c Via: varnish 48 TxHeader c X-Cache: MISS 48 ReqEnd c 366314365 1263208967.902776957 1263208968.090610981 0.000072956 0.187798977 0.000035048 49 SessionOpen c 212.93.136.105 36020 :80 49 ReqStart c 212.93.136.105 36020 366314387 49 RxRequest c GET 49 RxURL c /program-Prima_TV/2009-12-31/Fete-de-maritat-8682717.html 49 RxProtocol c HTTP/1.0 49 RxHeader c Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-gsarcade-launch, */* 49 RxHeader c Referer: http://www.google.ro/search?client=qsb-win&rlz=1R3GGLL_roRO347RO349&hl=ro&q=fete+de+maritat 49 RxHeader c Accept-Language: en-us 49 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.3) 49 RxHeader c Accept-Encoding: gzip, deflate 49 RxHeader c Host: tv.acasa.ro 49 RxHeader c Via: 1.1 Nova-Communication (squid/3.0.STABLE13) 49 RxHeader c X-Forwarded-For: unknown 49 RxHeader c Cache-Control: max-age=259200 49 RxHeader c Connection: keep-alive 49 VCL_call c recv 49 VCL_acl c NO_MATCH nocache 49 VCL_return c lookup 49 VCL_call c hash hash 49 VCL_call c miss fetch 49 Backend c 60 default default 49 ObjProtocol c HTTP/1.1 49 ObjStatus c 302 49 ObjResponse c Found 49 ObjHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 49 ObjHeader c Server: Apache 49 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 ObjHeader c Expires: 0 49 ObjHeader c Cache-Control: no-cache 49 ObjHeader c Pragma: no-cache 49 ObjHeader c Content-Language: ro 49 ObjHeader c Location: http://tv.acasa.ro/tv/index 49 ObjHeader c Content-Type: text/html; charset=UTF-8 49 TTL c 366314387 RFC 120 1263208968 0 0 0 0 49 VCL_call c fetch pass 49 Length c 65 49 VCL_call c deliver deliver 49 TxProtocol c HTTP/1.1 49 TxStatus c 302 49 TxResponse c Found 49 TxHeader c Server: Apache 49 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 TxHeader c Expires: 0 49 TxHeader c Cache-Control: no-cache 49 TxHeader c Pragma: no-cache 49 TxHeader c Content-Language: ro 49 TxHeader c Location: http://tv.acasa.ro/tv/index 49 TxHeader c Content-Type: text/html; charset=UTF-8 49 TxHeader c Content-Length: 65 49 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 49 TxHeader c X-Varnish: 366314387 49 TxHeader c Age: 0 49 TxHeader c Connection: keep-alive 49 TxHeader c Via: varnish 49 TxHeader c X-Cache: MISS 49 ReqEnd c 366314387 1263208968.221381903 1263208968.360692978 0.000059843 0.139232159 0.000078917 28 SessionOpen c 86.122.56.146 48109 :80 28 ReqStart c 86.122.56.146 48109 366314399 28 RxRequest c GET 28 RxURL c /program-Prima_TV/2009-12-31/Fete-de-maritat-8682717.html 28 RxProtocol c HTTP/1.1 28 RxHeader c Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-gsarcade-launch, */* 28 RxHeader c Referer: http://www.google.ro/search?client=qsb-win&rlz=1R3GGLL_roRO347RO349&hl=ro&q=fete+de+maritat 28 RxHeader c Accept-Language: en-us 28 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.3) 28 RxHeader c Accept-Encoding: gzip, deflate 28 RxHeader c Host: tv.acasa.ro 28 RxHeader c X-Proxy-ID: 1182211944 28 RxHeader c X-Forwarded-For: 212.93.136.122 28 RxHeader c Via: 1.1 86.122.56.146 (Mikrotik HttpProxy) 28 VCL_call c recv 28 VCL_acl c NO_MATCH nocache 28 VCL_return c lookup 28 VCL_call c hash hash 28 HitPass c 366314387 28 VCL_call c pass pass 28 Backend c 60 default default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 302 28 ObjResponse c Found 28 ObjHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 28 ObjHeader c Server: Apache 28 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 ObjHeader c Expires: 0 28 ObjHeader c Cache-Control: no-cache 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Content-Language: ro 28 ObjHeader c Location: http://tv.acasa.ro/tv/index 28 ObjHeader c Content-Type: text/html; charset=UTF-8 28 TTL c 366314399 RFC 120 1263208968 0 0 0 0 28 VCL_call c fetch pass 28 Length c 65 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 302 28 TxResponse c Found 28 TxHeader c Server: Apache 28 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 TxHeader c Expires: 0 28 TxHeader c Cache-Control: no-cache 28 TxHeader c Pragma: no-cache 28 TxHeader c Content-Language: ro 28 TxHeader c Location: http://tv.acasa.ro/tv/index 28 TxHeader c Content-Type: text/html; charset=UTF-8 28 TxHeader c Content-Length: 65 28 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 28 TxHeader c X-Varnish: 366314399 28 TxHeader c Age: 0 28 TxHeader c Connection: keep-alive 28 TxHeader c Via: varnish 28 TxHeader c X-Cache: MISS 28 ReqEnd c 366314399 1263208968.373939991 1263208968.525717974 0.000257969 0.151699066 0.000078917 137 SessionOpen c 67.195.115.177 32897 :80 137 ReqStart c 67.195.115.177 32897 366314936 137 RxRequest c GET 137 RxURL c /program-HBO/2009-10-12/Cu-totii-la-surf--7942275.html 137 RxProtocol c HTTP/1.0 137 RxHeader c Host: tv.acasa.ro 137 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 137 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 137 RxHeader c Accept-Language: en-us,en;q=0.5 137 RxHeader c Accept-Encoding: gzip,deflate 137 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 137 RxHeader c X-LLF-Mime-Type: true 137 VCL_call c recv 137 VCL_acl c NO_MATCH nocache 137 VCL_return c lookup 137 VCL_call c hash hash 137 VCL_call c miss fetch 137 Backend c 139 default default 137 ObjProtocol c HTTP/1.1 137 ObjStatus c 302 137 ObjResponse c Found 137 ObjHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 137 ObjHeader c Server: Apache 137 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 ObjHeader c Expires: 0 137 ObjHeader c Cache-Control: no-cache 137 ObjHeader c Pragma: no-cache 137 ObjHeader c Content-Language: ro 137 ObjHeader c Location: http://tv.acasa.ro/tv/index 137 ObjHeader c Content-Type: text/html; charset=UTF-8 137 TTL c 366314936 RFC 120 1263208975 0 0 0 0 137 VCL_call c fetch pass 137 Length c 65 137 VCL_call c deliver deliver 137 TxProtocol c HTTP/1.1 137 TxStatus c 302 137 TxResponse c Found 137 TxHeader c Server: Apache 137 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 TxHeader c Expires: 0 137 TxHeader c Cache-Control: no-cache 137 TxHeader c Pragma: no-cache 137 TxHeader c Content-Language: ro 137 TxHeader c Location: http://tv.acasa.ro/tv/index 137 TxHeader c Content-Type: text/html; charset=UTF-8 137 TxHeader c Content-Length: 65 137 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 137 TxHeader c X-Varnish: 366314936 137 TxHeader c Age: 0 137 TxHeader c Connection: close 137 TxHeader c Via: varnish 137 TxHeader c X-Cache: MISS 137 ReqEnd c 366314936 1263208975.568783045 1263208975.872977018 0.000031948 0.304157019 0.000036955 145 SessionOpen c 84.223.183.79 60794 :80 145 ReqStart c 84.223.183.79 60794 366314919 145 RxRequest c GET 145 RxURL c /poze_Sexy_--s5.html 145 RxProtocol c HTTP/1.1 145 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; ro) Presto/2.2.15 Version/10.10 145 RxHeader c Host: poze.acasa.ro 145 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 145 RxHeader c Accept-Language: en-US,en;q=0.9 145 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 145 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 145 RxHeader c Referer: http://poze.acasa.ro/ 145 RxHeader c Cookie: POPUPCHECK=1263295357495; trafic_h=f1aba1acc6bd31dlbe216cfc3a5fe920*1263208814*acasa.ro*1263208814*1263208814*1; __utma=240209555 .1155727859.1263208814.1263208814.1263208814.1; __utmc=240209555; __utmz=240209555.1263208814.1.1.utmccn=(organic)|utm 145 RxHeader c Cookie2: $Version=1 145 RxHeader c Connection: Keep-Alive, TE 145 RxHeader c TE: deflate, gzip, chunked, identity, trailers 145 VCL_call c recv 145 VCL_acl c NO_MATCH nocache 145 VCL_return c pass 145 VCL_call c pass pass 145 Backend c 132 default default 145 ObjProtocol c HTTP/1.1 145 ObjStatus c 302 145 ObjResponse c Found 145 ObjHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 145 ObjHeader c Server: Apache 145 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 145 ObjHeader c Expires: 0 145 ObjHeader c Cache-Control: no-cache 145 ObjHeader c Pragma: no-cache 145 ObjHeader c Content-Language: ro 145 ObjHeader c Location: http://poze.acasa.ro/poze/ask 145 ObjHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 145 ObjHeader c Content-Type: text/html; charset=utf-8 145 TTL c 366314919 RFC 120 1263208975 0 0 0 0 145 VCL_call c fetch pass 145 Length c 67 145 VCL_call c deliver deliver 145 TxProtocol c HTTP/1.1 145 TxStatus c 302 145 TxResponse c Found 145 TxHeader c Server: Apache 145 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 145 TxHeader c Expires: 0 145 TxHeader c Cache-Control: no-cache 145 TxHeader c Pragma: no-cache 145 TxHeader c Content-Language: ro 145 TxHeader c Location: http://poze.acasa.ro/poze/ask 145 TxHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 145 TxHeader c Content-Type: text/html; charset=utf-8 145 TxHeader c Content-Length: 67 145 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 145 TxHeader c X-Varnish: 366314919 145 TxHeader c Age: 0 145 TxHeader c Connection: keep-alive 145 TxHeader c Via: varnish 145 TxHeader c X-Cache: MISS 145 ReqEnd c 366314919 1263208975.382122993 1263208975.889678955 0.000909090 0.507517099 0.000038862 20 SessionOpen c 67.195.115.177 60918 :80 20 ReqStart c 67.195.115.177 60918 366314793 20 RxRequest c GET 20 RxURL c /program-MTV_Rom_nia/2010-01-02/MTV-The-Movies-8711660.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 23 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:22:53 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366314793 RFC 120 1263208975 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 20 TxHeader c X-Varnish: 366314793 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366314793 1263208973.286572933 1263208975.890410900 0.000128984 2.603799105 0.000038862 60 SessionOpen c 92.86.133.2 1996 :80 60 ReqStart c 92.86.133.2 1996 366315356 60 RxRequest c GET 60 RxURL c /redirect?id=6392 60 RxProtocol c HTTP/1.1 60 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.10 60 RxHeader c Host: dir.acasa.ro 60 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 60 RxHeader c Accept-Language: ro,en-US;q=0.9,en;q=0.8 60 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 60 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 60 RxHeader c Referer: http://dir.acasa.ro/Sanatate/Clinici/Stomatologie--420.html 60 RxHeader c Cookie: POPUPCHECK=1263295388703; trafic_h=7led5054a4bc052d2c0f778376c41b9a*1261326231*acasa.ro*1261326231*1263208955*2; __utma=240209555 .1745029308.1261326231.1261326231.1263208955.2; __utmc=240209555; __utmz=240209555.1263208955.2.2.utmccn=(organic)|utm 60 RxHeader c Cookie2: $Version=1 60 RxHeader c Connection: Keep-Alive, TE 60 RxHeader c TE: deflate, gzip, chunked, identity, trailers 60 VCL_call c recv 60 VCL_acl c NO_MATCH nocache 60 VCL_return c pass 60 VCL_call c pass pass 60 Backend c 157 default default 60 ObjProtocol c HTTP/1.1 60 ObjStatus c 302 60 ObjResponse c Found 60 ObjHeader c Date: Mon, 11 Jan 2010 11:23:00 GMT 60 ObjHeader c Server: Apache 60 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 60 ObjHeader c Expires: 0 60 ObjHeader c Cache-Control: no-cache 60 ObjHeader c Pragma: no-cache 60 ObjHeader c Content-Language: ro 60 ObjHeader c Location: http://www.stoma-urgent.ro 60 ObjHeader c Set-Cookie: void=Yw4Df-ATltcluTzzE; domain=.acasa.ro; path=/ 60 ObjHeader c Content-Type: text/html; charset=utf-8 60 TTL c 366315356 RFC 120 1263208980 0 0 0 0 60 VCL_call c fetch pass 60 Length c 64 60 VCL_call c deliver deliver 60 TxProtocol c HTTP/1.1 60 TxStatus c 302 60 TxResponse c Found 60 TxHeader c Server: Apache 60 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 60 TxHeader c Expires: 0 60 TxHeader c Cache-Control: no-cache 60 TxHeader c Pragma: no-cache 60 TxHeader c Content-Language: ro 60 TxHeader c Location: http://www.stoma-urgent.ro 60 TxHeader c Set-Cookie: void=Yw4Df-ATltcluTzzE; domain=.acasa.ro; path=/ 60 TxHeader c Content-Type: text/html; charset=utf-8 60 TxHeader c Content-Length: 64 60 TxHeader c Date: Mon, 11 Jan 2010 11:23:00 GMT 60 TxHeader c X-Varnish: 366315356 60 TxHeader c Age: 0 60 TxHeader c Connection: keep-alive 60 TxHeader c Via: varnish 60 TxHeader c X-Cache: MISS 60 ReqEnd c 366315356 1263208980.480185032 1263208980.654925108 0.000219107 0.174679995 0.000060081 66 SessionOpen c 84.223.183.79 60817 :80 66 ReqStart c 84.223.183.79 60817 366315921 66 RxRequest c POST 66 RxURL c /poze/ask 66 RxProtocol c HTTP/1.1 66 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; ro) Presto/2.2.15 Version/10.10 66 RxHeader c Host: poze.acasa.ro 66 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 66 RxHeader c Accept-Language: en-US,en;q=0.9 66 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 66 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 66 RxHeader c Referer: http://poze.acasa.ro/poze/ask 66 RxHeader c Cookie: POPUPCHECK=1263295357495; trafic_h=f1aba1acc6bd31dlbe216cfc3a5fe920*1263208814*acasa.ro*1263208814*1263208814*1; __utma=240209555 .1155727859.1263208814.1263208814.1263208814.1; __utmc=240209555; __utmz=240209555.1263208814.1.1.utmccn=(organic)|utm 66 RxHeader c Cookie2: $Version=1 66 RxHeader c Connection: Keep-Alive, TE 66 RxHeader c TE: deflate, gzip, chunked, identity, trailers 66 RxHeader c Content-Length: 16 66 RxHeader c Content-Type: application/x-www-form-urlencoded 66 VCL_call c recv 66 VCL_acl c NO_MATCH nocache 66 VCL_return c pass 66 VCL_call c pass pass 66 Backend c 128 default default 66 ObjProtocol c HTTP/1.1 66 ObjStatus c 302 66 ObjResponse c Found 66 ObjHeader c Date: Mon, 11 Jan 2010 11:23:05 GMT 66 ObjHeader c Server: Apache 66 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 ObjHeader c Expires: 0 66 ObjHeader c Cache-Control: no-cache 66 ObjHeader c Pragma: no-cache 66 ObjHeader c Content-Language: ro 66 ObjHeader c Location: http://poze.acasa.ro/poze/top?categ=5 66 ObjHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 66 ObjHeader c Content-Type: text/html; charset=utf-8 66 TTL c 366315921 RFC 120 1263208985 0 0 0 0 66 VCL_call c fetch pass 66 Length c 75 66 VCL_call c deliver deliver 66 TxProtocol c HTTP/1.1 66 TxStatus c 302 66 TxResponse c Found 66 TxHeader c Server: Apache 66 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 TxHeader c Expires: 0 66 TxHeader c Cache-Control: no-cache 66 TxHeader c Pragma: no-cache 66 TxHeader c Content-Language: ro 66 TxHeader c Location: http://poze.acasa.ro/poze/top?categ=5 66 TxHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 66 TxHeader c Content-Type: text/html; charset=utf-8 66 TxHeader c Content-Length: 75 66 TxHeader c Date: Mon, 11 Jan 2010 11:23:05 GMT 66 TxHeader c X-Varnish: 366315921 66 TxHeader c Age: 0 66 TxHeader c Connection: keep-alive 66 TxHeader c Via: varnish 66 TxHeader c X-Cache: MISS 66 ReqEnd c 366315921 1263208985.546696901 1263208985.818258047 0.000101805 0.271466017 0.000095129 49 SessionOpen c 95.108.156.251 59155 :80 49 ReqStart c 95.108.156.251 59155 366316143 49 RxRequest c GET 49 RxURL c /program-Free_X_TV/2010-01-13/I-Swallow-Six-Part-1-8949460-r87.html 49 RxProtocol c HTTP/1.1 49 RxHeader c Host: tv.acasa.ro 49 RxHeader c Connection: Keep-Alive 49 RxHeader c Accept: */* 49 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 49 RxHeader c Accept-Encoding: gzip,deflate 49 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 49 RxHeader c From: webadmin at yandex.ru 49 VCL_call c recv 49 VCL_acl c NO_MATCH nocache 49 VCL_return c lookup 49 VCL_call c hash hash 49 VCL_call c miss fetch 49 Backend c 50 default default 49 ObjProtocol c HTTP/1.1 49 ObjStatus c 302 49 ObjResponse c Found 49 ObjHeader c Date: Mon, 11 Jan 2010 11:23:10 GMT 49 ObjHeader c Server: Apache 49 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 ObjHeader c Expires: 0 49 ObjHeader c Cache-Control: no-cache 49 ObjHeader c Pragma: no-cache 49 ObjHeader c Content-Language: ro 49 ObjHeader c Location: http://tv.acasa.ro/tv/index 49 ObjHeader c Content-Type: text/html; charset=UTF-8 49 TTL c 366316143 RFC 120 1263208990 0 0 0 0 49 VCL_call c fetch pass 49 Length c 65 49 VCL_call c deliver deliver 49 TxProtocol c HTTP/1.1 49 TxStatus c 302 49 TxResponse c Found 49 TxHeader c Server: Apache 49 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 TxHeader c Expires: 0 49 TxHeader c Cache-Control: no-cache 49 TxHeader c Pragma: no-cache 49 TxHeader c Content-Language: ro 49 TxHeader c Location: http://tv.acasa.ro/tv/index 49 TxHeader c Content-Type: text/html; charset=UTF-8 49 TxHeader c Content-Length: 65 49 TxHeader c Date: Mon, 11 Jan 2010 11:23:10 GMT 49 TxHeader c X-Varnish: 366316143 49 TxHeader c Age: 0 49 TxHeader c Connection: keep-alive 49 TxHeader c Via: varnish 49 TxHeader c X-Cache: MISS 49 ReqEnd c 366316143 1263208990.798176050 1263208990.954207897 0.000100136 0.155927896 0.000103951 44 SessionOpen c 79.118.206.91 2094 :80 44 ReqStart c 79.118.206.91 2094 366316258 44 RxRequest c GET 44 RxURL c /post?id=-1&zi=6&buton=Afiseaza 44 RxProtocol c HTTP/1.1 44 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, */* 44 RxHeader c Referer: http://tv.acasa.ro/program_Antena_1_--p17.html 44 RxHeader c Accept-Language: ro 44 RxHeader c Accept-Encoding: gzip, deflate 44 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) 44 RxHeader c Host: tv.acasa.ro 44 RxHeader c Connection: Keep-Alive 44 RxHeader c Cookie: POPUPCHECK=1263295370846; trafic_h=7f7dd489e8e29elad208401f069d065b*1263208980*acasa.ro*1263208980*1263208980*1; trafic_v=1; __ut ma=240209555.964185069.1263208980.1263208980.1263208980.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.126320 44 VCL_call c recv 44 VCL_acl c NO_MATCH nocache 44 VCL_return c pass 44 VCL_call c pass pass 44 Backend c 80 default default 44 ObjProtocol c HTTP/1.1 44 ObjStatus c 302 44 ObjResponse c Found 44 ObjHeader c Date: Mon, 11 Jan 2010 11:23:13 GMT 44 ObjHeader c Server: Apache 44 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 44 ObjHeader c Expires: 0 44 ObjHeader c Cache-Control: no-cache 44 ObjHeader c Pragma: no-cache 44 ObjHeader c Content-Language: ro 44 ObjHeader c Location: http://tv.acasa.ro/tv/error 44 ObjHeader c Content-Type: text/html; charset=UTF-8 44 TTL c 366316258 RFC 120 1263208993 0 0 0 0 44 VCL_call c fetch pass 44 Length c 65 44 VCL_call c deliver deliver 44 TxProtocol c HTTP/1.1 44 TxStatus c 302 44 TxResponse c Found 44 TxHeader c Server: Apache 44 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 44 TxHeader c Expires: 0 44 TxHeader c Cache-Control: no-cache 44 TxHeader c Pragma: no-cache 44 TxHeader c Content-Language: ro 44 TxHeader c Location: http://tv.acasa.ro/tv/error 44 TxHeader c Content-Type: text/html; charset=UTF-8 44 TxHeader c Content-Length: 65 44 TxHeader c Date: Mon, 11 Jan 2010 11:23:13 GMT 44 TxHeader c X-Varnish: 366316258 44 TxHeader c Age: 0 44 TxHeader c Connection: keep-alive 44 TxHeader c Via: varnish 44 TxHeader c X-Cache: MISS 44 ReqEnd c 366316258 1263208993.198345900 1263208993.321660042 0.000089884 0.123182058 0.000132084 122 SessionOpen c 216.129.119.11 57673 :80 122 ReqStart c 216.129.119.11 57673 366316404 122 RxRequest c GET 122 RxURL c /program-Cartoon_Network/2008-07-14/Dexter-s-Laboratory-4118211-r53.html 122 RxProtocol c HTTP/1.0 122 RxHeader c Connection: close 122 RxHeader c Host: tv.acasa.ro 122 RxHeader c Accept-Encoding: gzip 122 RxHeader c User-Agent: Mozilla/5.0 (Twiceler-0.9 http://www.cuil.com/twiceler/robot.html) 122 RxHeader c Accept: text/html, */* 122 VCL_call c recv 122 VCL_acl c NO_MATCH nocache 122 VCL_return c lookup 122 VCL_call c hash hash 122 VCL_call c miss fetch 122 Backend c 123 default default 122 ObjProtocol c HTTP/1.1 122 ObjStatus c 302 122 ObjResponse c Found 122 ObjHeader c Date: Mon, 11 Jan 2010 11:23:16 GMT 122 ObjHeader c Server: Apache 122 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 ObjHeader c Expires: 0 122 ObjHeader c Cache-Control: no-cache 122 ObjHeader c Pragma: no-cache 122 ObjHeader c Content-Language: ro 122 ObjHeader c Location: http://tv.acasa.ro/tv/index 122 ObjHeader c Content-Type: text/html; charset=UTF-8 122 TTL c 366316404 RFC 120 1263208997 0 0 0 0 122 VCL_call c fetch pass 122 Length c 65 122 VCL_call c deliver deliver 122 TxProtocol c HTTP/1.1 122 TxStatus c 302 122 TxResponse c Found 122 TxHeader c Server: Apache 122 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 TxHeader c Expires: 0 122 TxHeader c Cache-Control: no-cache 122 TxHeader c Pragma: no-cache 122 TxHeader c Content-Language: ro 122 TxHeader c Location: http://tv.acasa.ro/tv/index 122 TxHeader c Content-Type: text/html; charset=UTF-8 122 TxHeader c Content-Length: 65 122 TxHeader c Date: Mon, 11 Jan 2010 11:23:17 GMT 122 TxHeader c X-Varnish: 366316404 122 TxHeader c Age: 0 122 TxHeader c Connection: close 122 TxHeader c Via: varnish 122 TxHeader c X-Cache: MISS 122 ReqEnd c 366316404 1263208996.941240072 1263208997.059401989 0.000029087 0.118115902 0.000046015 61 SessionOpen c 67.195.111.158 34343 :80 61 ReqStart c 67.195.111.158 34343 366317722 61 RxRequest c GET 61 RxURL c /redirect?id=19222 61 RxProtocol c HTTP/1.0 61 RxHeader c Host: dir.acasa.ro 61 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 61 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 61 RxHeader c Accept-Language: en-us,en;q=0.5 61 RxHeader c Accept-Encoding: gzip,deflate 61 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 61 RxHeader c X-LLF-Mime-Type: true 61 VCL_call c recv 61 VCL_acl c NO_MATCH nocache 61 VCL_return c lookup 61 VCL_call c hash hash 61 VCL_call c miss fetch 61 Backend c 83 default default 61 ObjProtocol c HTTP/1.1 61 ObjStatus c 302 61 ObjResponse c Found 61 ObjHeader c Date: Mon, 11 Jan 2010 11:23:34 GMT 61 ObjHeader c Server: Apache 61 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 61 ObjHeader c Expires: 0 61 ObjHeader c Cache-Control: no-cache 61 ObjHeader c Pragma: no-cache 61 ObjHeader c Content-Language: ro 61 ObjHeader c Location: http://www.evamendes-pics.com 61 ObjHeader c Set-Cookie: void=1r6eo88m9oUDVQrlY; domain=.acasa.ro; path=/ 61 ObjHeader c Content-Type: text/html; charset=utf-8 61 TTL c 366317722 RFC 120 1263209014 0 0 0 0 61 VCL_call c fetch pass 61 Length c 67 61 VCL_call c deliver deliver 61 TxProtocol c HTTP/1.1 61 TxStatus c 302 61 TxResponse c Found 61 TxHeader c Server: Apache 61 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 61 TxHeader c Expires: 0 61 TxHeader c Cache-Control: no-cache 61 TxHeader c Pragma: no-cache 61 TxHeader c Content-Language: ro 61 TxHeader c Location: http://www.evamendes-pics.com 61 TxHeader c Set-Cookie: void=1r6eo88m9oUDVQrlY; domain=.acasa.ro; path=/ 61 TxHeader c Content-Type: text/html; charset=utf-8 61 TxHeader c Content-Length: 67 61 TxHeader c Date: Mon, 11 Jan 2010 11:23:34 GMT 61 TxHeader c X-Varnish: 366317722 61 TxHeader c Age: 0 61 TxHeader c Connection: close 61 TxHeader c Via: varnish 61 TxHeader c X-Cache: MISS 61 ReqEnd c 366317722 1263209014.604552984 1263209014.849833965 0.000097990 0.245194912 0.000086069 122 SessionOpen c 217.10.213.126 1600 :80 122 ReqStart c 217.10.213.126 1600 366317877 122 RxRequest c GET 122 RxURL c /program-Prima_TV/2010-01-04/Fermier-Caut-nevasta--8759315.html 122 RxProtocol c HTTP/1.1 122 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-m s-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-silverlight, */* 122 RxHeader c Referer: http://www.google.ro/search?hl=ro&source=hp&q=fermier+caut+nevasta&meta=&aq=0&oq=fermier 122 RxHeader c Accept-Language: en-us 122 RxHeader c Accept-Encoding: gzip, deflate 122 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET C LR 3.5.30729) 122 RxHeader c Host: tv.acasa.ro 122 RxHeader c Connection: Keep-Alive 122 RxHeader c Cookie: POPUPCHECK=1261143965421; trafic_h=05dba28ffda3e46l10837189cc8f7189*1250985859*acasa.ro*1262264880*1262849575*11; __utma=24020955 5.1771099526.1250985859.1262264880.1262849575.12; __utmz=240209555.1262849575.12.12.utmccn=(organic)|utmcsr=google|utm 122 VCL_call c recv 122 VCL_acl c NO_MATCH nocache 122 VCL_return c pass 122 VCL_call c pass pass 122 Backend c 125 default default 122 ObjProtocol c HTTP/1.1 122 ObjStatus c 302 122 ObjResponse c Found 122 ObjHeader c Date: Mon, 11 Jan 2010 11:23:38 GMT 122 ObjHeader c Server: Apache 122 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 ObjHeader c Expires: 0 122 ObjHeader c Cache-Control: no-cache 122 ObjHeader c Pragma: no-cache 122 ObjHeader c Content-Language: ro 122 ObjHeader c Location: http://tv.acasa.ro/tv/index 122 ObjHeader c Content-Type: text/html; charset=UTF-8 122 TTL c 366317877 RFC 120 1263209018 0 0 0 0 122 VCL_call c fetch pass 122 Length c 65 122 VCL_call c deliver deliver 122 TxProtocol c HTTP/1.1 122 TxStatus c 302 122 TxResponse c Found 122 TxHeader c Server: Apache 122 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 TxHeader c Expires: 0 122 TxHeader c Cache-Control: no-cache 122 TxHeader c Pragma: no-cache 122 TxHeader c Content-Language: ro 122 TxHeader c Location: http://tv.acasa.ro/tv/index 122 TxHeader c Content-Type: text/html; charset=UTF-8 122 TxHeader c Content-Length: 65 122 TxHeader c Date: Mon, 11 Jan 2010 11:23:38 GMT 122 TxHeader c X-Varnish: 366317877 122 TxHeader c Age: 0 122 TxHeader c Connection: keep-alive 122 TxHeader c Via: varnish 122 TxHeader c X-Cache: MISS 122 ReqEnd c 366317877 1263209018.077413082 1263209018.414202929 0.000061035 0.336716890 0.000072956 84 SessionOpen c 95.108.156.251 51915 :80 84 ReqStart c 95.108.156.251 51915 366318200 84 RxRequest c GET 84 RxURL c /program-Free_X_TV/2010-01-11/We-Swallow-12-Part-2-8894997-r87.html 84 RxProtocol c HTTP/1.1 84 RxHeader c Host: tv.acasa.ro 84 RxHeader c Connection: Keep-Alive 84 RxHeader c Accept: */* 84 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 84 RxHeader c Accept-Encoding: gzip,deflate 84 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 84 RxHeader c From: webadmin at yandex.ru 84 VCL_call c recv 84 VCL_acl c NO_MATCH nocache 84 VCL_return c lookup 84 VCL_call c hash hash 84 VCL_call c miss fetch 84 Backend c 86 default default 84 ObjProtocol c HTTP/1.1 84 ObjStatus c 302 84 ObjResponse c Found 84 ObjHeader c Date: Mon, 11 Jan 2010 11:23:44 GMT 84 ObjHeader c Server: Apache 84 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 84 ObjHeader c Expires: 0 84 ObjHeader c Cache-Control: no-cache 84 ObjHeader c Pragma: no-cache 84 ObjHeader c Content-Language: ro 84 ObjHeader c Location: http://tv.acasa.ro/tv/index 84 ObjHeader c Content-Type: text/html; charset=UTF-8 84 TTL c 366318200 RFC 120 1263209024 0 0 0 0 84 VCL_call c fetch pass 84 Length c 65 84 VCL_call c deliver deliver 84 TxProtocol c HTTP/1.1 84 TxStatus c 302 84 TxResponse c Found 84 TxHeader c Server: Apache 84 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 84 TxHeader c Expires: 0 84 TxHeader c Cache-Control: no-cache 84 TxHeader c Pragma: no-cache 84 TxHeader c Content-Language: ro 84 TxHeader c Location: http://tv.acasa.ro/tv/index 84 TxHeader c Content-Type: text/html; charset=UTF-8 84 TxHeader c Content-Length: 65 84 TxHeader c Date: Mon, 11 Jan 2010 11:23:44 GMT 84 TxHeader c X-Varnish: 366318200 84 TxHeader c Age: 0 84 TxHeader c Connection: keep-alive 84 TxHeader c Via: varnish 84 TxHeader c X-Cache: MISS 84 ReqEnd c 366318200 1263209024.067236900 1263209024.220580101 0.000073910 0.153258085 0.000085115 89 SessionOpen c 89.36.221.240 2805 :80 89 ReqStart c 89.36.221.240 2805 366318967 89 RxRequest c GET 89 RxURL c /post?id=-1&zi=-1&buton=Afiseaza 89 RxProtocol c HTTP/1.1 89 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, */* 89 RxHeader c Referer: http://tv.acasa.ro/post?id=97&zi=-1&buton=Afiseaza 89 RxHeader c Accept-Language: en-US 89 RxHeader c UA-CPU: x86 89 RxHeader c Accept-Encoding: gzip, deflate 89 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts) 89 RxHeader c Host: tv.acasa.ro 89 RxHeader c Connection: Keep-Alive 89 RxHeader c Cookie: POPUPCHECK=1263294670062; trafic_h=56fd9cc3a73al35f0934098a84024bb2*1260962519*acasa.ro*1262766245*1263208279*5; trafic_v=1; __ut ma=240209555.2116266143.1260962520.1263208641.1263209020.8; __utmb=240209555; __utmz=240209555.1263208641.7.6.utmccn=( 89 VCL_call c recv 89 VCL_acl c NO_MATCH nocache 89 VCL_return c pass 89 VCL_call c pass pass 89 Backend c 90 default default 89 ObjProtocol c HTTP/1.1 89 ObjStatus c 302 89 ObjResponse c Found 89 ObjHeader c Date: Mon, 11 Jan 2010 11:23:58 GMT 89 ObjHeader c Server: Apache 89 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 89 ObjHeader c Expires: 0 89 ObjHeader c Cache-Control: no-cache 89 ObjHeader c Pragma: no-cache 89 ObjHeader c Content-Language: ro 89 ObjHeader c Location: http://tv.acasa.ro/tv/error 89 ObjHeader c Content-Type: text/html; charset=UTF-8 89 TTL c 366318967 RFC 120 1263209039 0 0 0 0 89 VCL_call c fetch pass 89 Length c 65 89 VCL_call c deliver deliver 89 TxProtocol c HTTP/1.1 89 TxStatus c 302 89 TxResponse c Found 89 TxHeader c Server: Apache 89 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 89 TxHeader c Expires: 0 89 TxHeader c Cache-Control: no-cache 89 TxHeader c Pragma: no-cache 89 TxHeader c Content-Language: ro 89 TxHeader c Location: http://tv.acasa.ro/tv/error 89 TxHeader c Content-Type: text/html; charset=UTF-8 89 TxHeader c Content-Length: 65 89 TxHeader c Date: Mon, 11 Jan 2010 11:23:59 GMT 89 TxHeader c X-Varnish: 366318967 89 TxHeader c Age: 0 89 TxHeader c Connection: keep-alive 89 TxHeader c Via: varnish 89 TxHeader c X-Cache: MISS 89 ReqEnd c 366318967 1263209038.969425917 1263209039.157500029 0.000106812 0.187976122 0.000097990 23 SessionOpen c 65.55.216.32 55026 :80 23 ReqStart c 65.55.216.32 55026 366320162 23 RxRequest c GET 23 RxURL c /redirect?id=6857 23 RxProtocol c HTTP/1.1 23 RxHeader c Accept: */* 23 RxHeader c Host: dir.acasa.ro 23 RxHeader c Accept-Encoding: gzip, deflate 23 RxHeader c User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm) 23 RxHeader c Connection: Keep-Alive 23 RxHeader c Cache-Control: no-cache 23 RxHeader c Pragma: no-cache 23 VCL_call c recv 23 VCL_acl c NO_MATCH nocache 23 VCL_return c lookup 23 VCL_call c hash hash 23 VCL_call c miss fetch 23 Backend c 26 default default 23 ObjProtocol c HTTP/1.1 23 ObjStatus c 302 23 ObjResponse c Found 23 ObjHeader c Date: Mon, 11 Jan 2010 11:24:12 GMT 23 ObjHeader c Server: Apache 23 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 ObjHeader c Expires: 0 23 ObjHeader c Cache-Control: no-cache 23 ObjHeader c Pragma: no-cache 23 ObjHeader c Content-Language: ro 23 ObjHeader c Location: http://www.calion.ro 23 ObjHeader c Set-Cookie: void=3w60B3c8lUVS4qSi; domain=.acasa.ro; path=/ 23 ObjHeader c Content-Type: text/html; charset=utf-8 23 TTL c 366320162 RFC 120 1263209052 0 0 0 0 23 VCL_call c fetch pass 23 Length c 58 23 VCL_call c deliver deliver 23 TxProtocol c HTTP/1.1 23 TxStatus c 302 23 TxResponse c Found 23 TxHeader c Server: Apache 23 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 TxHeader c Expires: 0 23 TxHeader c Cache-Control: no-cache 23 TxHeader c Pragma: no-cache 23 TxHeader c Content-Language: ro 23 TxHeader c Location: http://www.calion.ro 23 TxHeader c Set-Cookie: void=3w60B3c8lUVS4qSi; domain=.acasa.ro; path=/ 23 TxHeader c Content-Type: text/html; charset=utf-8 23 TxHeader c Content-Length: 58 23 TxHeader c Date: Mon, 11 Jan 2010 11:24:12 GMT 23 TxHeader c X-Varnish: 366320162 23 TxHeader c Age: 0 23 TxHeader c Connection: keep-alive 23 TxHeader c Via: varnish 23 TxHeader c X-Cache: MISS 23 ReqEnd c 366320162 1263209052.389780045 1263209052.577569008 0.000031948 0.187749863 0.000039101 102 SessionOpen c 66.249.65.57 42137 :80 102 ReqStart c 66.249.65.57 42137 366320259 102 RxRequest c GET 102 RxURL c /program-TCM/2008-09-02/Arena-4421981-r54.html 102 RxProtocol c HTTP/1.1 102 RxHeader c Host: tv.acasa.ro 102 RxHeader c Connection: Keep-alive 102 RxHeader c Accept: text/html,*/*;q=0.9 102 RxHeader c From: googlebot(at)googlebot.com 102 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 102 RxHeader c Accept-Encoding: gzip,deflate 102 VCL_call c recv 102 VCL_acl c NO_MATCH nocache 102 VCL_return c lookup 102 VCL_call c hash hash 102 VCL_call c miss fetch 102 Backend c 104 default default 102 ObjProtocol c HTTP/1.1 102 ObjStatus c 302 102 ObjResponse c Found 102 ObjHeader c Date: Mon, 11 Jan 2010 11:24:13 GMT 102 ObjHeader c Server: Apache 102 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 102 ObjHeader c Expires: 0 102 ObjHeader c Cache-Control: no-cache 102 ObjHeader c Pragma: no-cache 102 ObjHeader c Content-Language: ro 102 ObjHeader c Location: http://tv.acasa.ro/tv/index 102 ObjHeader c Content-Type: text/html; charset=UTF-8 102 TTL c 366320259 RFC 120 1263209053 0 0 0 0 102 VCL_call c fetch pass 102 Length c 65 102 VCL_call c deliver deliver 102 TxProtocol c HTTP/1.1 102 TxStatus c 302 102 TxResponse c Found 102 TxHeader c Server: Apache 102 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 102 TxHeader c Expires: 0 102 TxHeader c Cache-Control: no-cache 102 TxHeader c Pragma: no-cache 102 TxHeader c Content-Language: ro 102 TxHeader c Location: http://tv.acasa.ro/tv/index 102 TxHeader c Content-Type: text/html; charset=UTF-8 102 TxHeader c Content-Length: 65 102 TxHeader c Date: Mon, 11 Jan 2010 11:24:13 GMT 102 TxHeader c X-Varnish: 366320259 102 TxHeader c Age: 0 102 TxHeader c Connection: keep-alive 102 TxHeader c Via: varnish 102 TxHeader c X-Cache: MISS 102 ReqEnd c 366320259 1263209053.499264002 1263209053.714293003 0.000061035 0.214950085 0.000078917 55 SessionOpen c 65.55.209.55 22092 :80 55 ReqStart c 65.55.209.55 22092 366320354 55 RxRequest c GET 55 RxURL c /program-Cinemax_2/2009-12-03/Nu-ti-face-griji-pentru-mine-8502298-r83.html 55 RxProtocol c HTTP/1.1 55 RxHeader c Accept: */* 55 RxHeader c Host: tv.acasa.ro 55 RxHeader c Accept-Encoding: gzip, deflate 55 RxHeader c From: msnbote(at)microsoft.com 55 RxHeader c User-Agent: msnbot/1.1 (+http://search.msn.com/msnbot.htm) 55 RxHeader c Connection: Close 55 VCL_call c recv 55 VCL_acl c NO_MATCH nocache 55 VCL_return c lookup 55 VCL_call c hash hash 55 VCL_call c miss fetch 55 Backend c 68 default default 55 ObjProtocol c HTTP/1.1 55 ObjStatus c 302 55 ObjResponse c Found 55 ObjHeader c Date: Mon, 11 Jan 2010 11:24:14 GMT 55 ObjHeader c Server: Apache 55 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 55 ObjHeader c Expires: 0 55 ObjHeader c Cache-Control: no-cache 55 ObjHeader c Pragma: no-cache 55 ObjHeader c Content-Language: ro 55 ObjHeader c Location: http://tv.acasa.ro/tv/index 55 ObjHeader c Content-Type: text/html; charset=UTF-8 55 TTL c 366320354 RFC 120 1263209054 0 0 0 0 55 VCL_call c fetch pass 55 Length c 65 55 VCL_call c deliver deliver 55 TxProtocol c HTTP/1.1 55 TxStatus c 302 55 TxResponse c Found 55 TxHeader c Server: Apache 55 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 55 TxHeader c Expires: 0 55 TxHeader c Cache-Control: no-cache 55 TxHeader c Pragma: no-cache 55 TxHeader c Content-Language: ro 55 TxHeader c Location: http://tv.acasa.ro/tv/index 55 TxHeader c Content-Type: text/html; charset=UTF-8 55 TxHeader c Content-Length: 65 55 TxHeader c Date: Mon, 11 Jan 2010 11:24:14 GMT 55 TxHeader c X-Varnish: 366320354 55 TxHeader c Age: 0 55 TxHeader c Connection: close 55 TxHeader c Via: varnish 55 TxHeader c X-Cache: MISS 55 ReqEnd c 366320354 1263209054.080161095 1263209054.266928911 0.000113010 0.186687946 0.000079870 51 SessionOpen c 95.108.156.251 59364 :80 51 ReqStart c 95.108.156.251 59364 366320418 51 RxRequest c GET 51 RxURL c /vremea_arad.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: vremea.acasa.ro 51 RxHeader c Connection: Keep-Alive 51 RxHeader c Accept: */* 51 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 51 RxHeader c Accept-Encoding: gzip,deflate 51 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 51 RxHeader c From: webadmin at yandex.ru 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 52 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:24:15 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://vremea.acasa.ro/vremea/vremea_romania_Arad.html 51 ObjHeader c Content-Type: text/html; charset=utf-8 51 TTL c 366320418 RFC 120 1263209055 0 0 0 0 51 VCL_call c fetch pass 51 Length c 92 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://vremea.acasa.ro/vremea/vremea_romania_Arad.html 51 TxHeader c Content-Type: text/html; charset=utf-8 51 TxHeader c Content-Length: 92 51 TxHeader c Date: Mon, 11 Jan 2010 11:24:15 GMT 51 TxHeader c X-Varnish: 366320418 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366320418 1263209055.066158056 1263209055.201777935 0.000059128 0.135572910 0.000046968 32 SessionOpen c 66.249.65.57 55738 :80 32 ReqStart c 66.249.65.57 55738 366320575 32 RxRequest c GET 32 RxURL c /program-TCM/2008-09-03/Arena-4421993-r54.html 32 RxProtocol c HTTP/1.1 32 RxHeader c Host: tv.acasa.ro 32 RxHeader c Connection: Keep-alive 32 RxHeader c Accept: text/html,*/*;q=0.9 32 RxHeader c From: googlebot(at)googlebot.com 32 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 32 RxHeader c Accept-Encoding: gzip,deflate 32 VCL_call c recv 32 VCL_acl c NO_MATCH nocache 32 VCL_return c lookup 32 VCL_call c hash hash 32 VCL_call c miss fetch 32 Backend c 44 default default 32 ObjProtocol c HTTP/1.1 32 ObjStatus c 302 32 ObjResponse c Found 32 ObjHeader c Date: Mon, 11 Jan 2010 11:24:19 GMT 32 ObjHeader c Server: Apache 32 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 32 ObjHeader c Expires: 0 32 ObjHeader c Cache-Control: no-cache 32 ObjHeader c Pragma: no-cache 32 ObjHeader c Content-Language: ro 32 ObjHeader c Location: http://tv.acasa.ro/tv/index 32 ObjHeader c Content-Type: text/html; charset=UTF-8 32 TTL c 366320575 RFC 120 1263209060 0 0 0 0 32 VCL_call c fetch pass 32 Length c 65 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 302 32 TxResponse c Found 32 TxHeader c Server: Apache 32 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 32 TxHeader c Expires: 0 32 TxHeader c Cache-Control: no-cache 32 TxHeader c Pragma: no-cache 32 TxHeader c Content-Language: ro 32 TxHeader c Location: http://tv.acasa.ro/tv/index 32 TxHeader c Content-Type: text/html; charset=UTF-8 32 TxHeader c Content-Length: 65 32 TxHeader c Date: Mon, 11 Jan 2010 11:24:20 GMT 32 TxHeader c X-Varnish: 366320575 32 TxHeader c Age: 0 32 TxHeader c Connection: keep-alive 32 TxHeader c Via: varnish 32 TxHeader c X-Cache: MISS 32 ReqEnd c 366320575 1263209059.224613905 1263209060.154719114 0.000033855 0.930052042 0.000053167 23 SessionOpen c 67.195.115.177 39009 :80 23 ReqStart c 67.195.115.177 39009 366320537 23 RxRequest c GET 23 RxURL c /program-Boomerang/2008-09-18/Ratonii-4559202-r81.html 23 RxProtocol c HTTP/1.0 23 RxHeader c Host: tv.acasa.ro 23 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 23 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 23 RxHeader c Accept-Language: en-us,en;q=0.5 23 RxHeader c Accept-Encoding: gzip,deflate 23 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 23 RxHeader c X-LLF-Mime-Type: true 23 VCL_call c recv 23 VCL_acl c NO_MATCH nocache 23 VCL_return c lookup 23 VCL_call c hash hash 23 VCL_call c miss fetch 23 Backend c 37 default default 23 ObjProtocol c HTTP/1.1 23 ObjStatus c 302 23 ObjResponse c Found 23 ObjHeader c Date: Mon, 11 Jan 2010 11:24:17 GMT 23 ObjHeader c Server: Apache 23 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 ObjHeader c Expires: 0 23 ObjHeader c Cache-Control: no-cache 23 ObjHeader c Pragma: no-cache 23 ObjHeader c Content-Language: ro 23 ObjHeader c Location: http://tv.acasa.ro/tv/index 23 ObjHeader c Content-Type: text/html; charset=UTF-8 23 TTL c 366320537 RFC 120 1263209060 0 0 0 0 23 VCL_call c fetch pass 23 Length c 65 23 VCL_call c deliver deliver 23 TxProtocol c HTTP/1.1 23 TxStatus c 302 23 TxResponse c Found 23 TxHeader c Server: Apache 23 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 TxHeader c Expires: 0 23 TxHeader c Cache-Control: no-cache 23 TxHeader c Pragma: no-cache 23 TxHeader c Content-Language: ro 23 TxHeader c Location: http://tv.acasa.ro/tv/index 23 TxHeader c Content-Type: text/html; charset=UTF-8 23 TxHeader c Content-Length: 65 23 TxHeader c Date: Mon, 11 Jan 2010 11:24:20 GMT 23 TxHeader c X-Varnish: 366320537 23 TxHeader c Age: 0 23 TxHeader c Connection: close 23 TxHeader c Via: varnish 23 TxHeader c X-Cache: MISS 23 ReqEnd c 366320537 1263209057.988310099 1263209060.248225927 0.000087023 2.259871960 0.000043869 75 SessionOpen c 89.122.141.96 14745 :80 75 ReqStart c 89.122.141.96 14745 366320804 75 RxRequest c GET 75 RxURL c /content?box=horoscop&op=link&sid=-1 75 RxProtocol c HTTP/1.1 75 RxHeader c Accept: */* 75 RxHeader c Referer: http://webcontent.acasa.ro/content?box=horoscop&op=show&sid=-1&fcolor=%231573D0&bcolor=%231573D0&hfcolor=%23000000&hbcolor=%23E1 F3FF&width=200&height=180 75 RxHeader c Accept-Language: ro 75 RxHeader c Accept-Encoding: gzip, deflate 75 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) 75 RxHeader c Host: webcontent.acasa.ro 75 RxHeader c Connection: Keep-Alive 75 RxHeader c Cookie: trafic_h=adl4b946daad6981e5fec3b1adcc28b1*1206384937*acasa.ro*1214516367*1232666946*17; __utma=240209555.335816389.1206384937.121 4517375.1232666947.20 75 VCL_call c recv 75 VCL_acl c NO_MATCH nocache 75 VCL_return c pass 75 VCL_call c pass pass 75 Backend c 82 default default 75 ObjProtocol c HTTP/1.1 75 ObjStatus c 302 75 ObjResponse c Found 75 ObjHeader c Date: Mon, 11 Jan 2010 11:24:23 GMT 75 ObjHeader c Server: Apache 75 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 75 ObjHeader c Expires: 0 75 ObjHeader c Cache-Control: no-cache 75 ObjHeader c Pragma: no-cache 75 ObjHeader c Content-Language: ro 75 ObjHeader c Location: http://horoscop.acasa.ro 75 ObjHeader c Set-Cookie: acasa_horoscop=true; domain=.acasa.ro; path=/ 75 ObjHeader c Content-Type: text/html; charset=utf-8 75 TTL c 366320804 RFC 120 1263209063 0 0 0 0 75 VCL_call c fetch pass 75 Length c 62 75 VCL_call c deliver deliver 75 TxProtocol c HTTP/1.1 75 TxStatus c 302 75 TxResponse c Found 75 TxHeader c Server: Apache 75 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 75 TxHeader c Expires: 0 75 TxHeader c Cache-Control: no-cache 75 TxHeader c Pragma: no-cache 75 TxHeader c Content-Language: ro 75 TxHeader c Location: http://horoscop.acasa.ro 75 TxHeader c Set-Cookie: acasa_horoscop=true; domain=.acasa.ro; path=/ 75 TxHeader c Content-Type: text/html; charset=utf-8 75 TxHeader c Content-Length: 62 75 TxHeader c Date: Mon, 11 Jan 2010 11:24:23 GMT 75 TxHeader c X-Varnish: 366320804 75 TxHeader c Age: 0 75 TxHeader c Connection: keep-alive 75 TxHeader c Via: varnish 75 TxHeader c X-Cache: MISS 75 ReqEnd c 366320804 1263209063.790033102 1263209063.830733061 0.000087023 0.040612936 0.000087023 87 SessionOpen c 66.249.65.57 51343 :80 87 ReqStart c 66.249.65.57 51343 366321008 87 RxRequest c GET 87 RxURL c /program-TCM/2008-09-03/Colina-4421994-r54.html 87 RxProtocol c HTTP/1.1 87 RxHeader c Host: tv.acasa.ro 87 RxHeader c Connection: Keep-alive 87 RxHeader c Accept: text/html,*/*;q=0.9 87 RxHeader c From: googlebot(at)googlebot.com 87 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 87 RxHeader c Accept-Encoding: gzip,deflate 87 VCL_call c recv 87 VCL_acl c NO_MATCH nocache 87 VCL_return c lookup 87 VCL_call c hash hash 87 VCL_call c miss fetch 87 Backend c 93 default default 87 ObjProtocol c HTTP/1.1 87 ObjStatus c 302 87 ObjResponse c Found 87 ObjHeader c Date: Mon, 11 Jan 2010 11:24:27 GMT 87 ObjHeader c Server: Apache 87 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 87 ObjHeader c Expires: 0 87 ObjHeader c Cache-Control: no-cache 87 ObjHeader c Pragma: no-cache 87 ObjHeader c Content-Language: ro 87 ObjHeader c Location: http://tv.acasa.ro/tv/index 87 ObjHeader c Content-Type: text/html; charset=UTF-8 87 TTL c 366321008 RFC 120 1263209068 0 0 0 0 87 VCL_call c fetch pass 87 Length c 65 87 VCL_call c deliver deliver 87 TxProtocol c HTTP/1.1 87 TxStatus c 302 87 TxResponse c Found 87 TxHeader c Server: Apache 87 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 87 TxHeader c Expires: 0 87 TxHeader c Cache-Control: no-cache 87 TxHeader c Pragma: no-cache 87 TxHeader c Content-Language: ro 87 TxHeader c Location: http://tv.acasa.ro/tv/index 87 TxHeader c Content-Type: text/html; charset=UTF-8 87 TxHeader c Content-Length: 65 87 TxHeader c Date: Mon, 11 Jan 2010 11:24:28 GMT 87 TxHeader c X-Varnish: 366321008 87 TxHeader c Age: 0 87 TxHeader c Connection: keep-alive 87 TxHeader c Via: varnish 87 TxHeader c X-Cache: MISS 87 ReqEnd c 366321008 1263209067.314116955 1263209068.922231913 0.000027895 1.608065128 0.000049829 72 SessionOpen c 67.195.115.177 39796 :80 72 ReqStart c 67.195.115.177 39796 366321140 72 RxRequest c GET 72 RxURL c /program-Pro_Cinema/2009-11-12/Expertul-8239611.html 72 RxProtocol c HTTP/1.0 72 RxHeader c Host: tv.acasa.ro 72 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 72 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 72 RxHeader c Accept-Language: en-us,en;q=0.5 72 RxHeader c Accept-Encoding: gzip,deflate 72 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 72 RxHeader c X-LLF-Mime-Type: true 72 VCL_call c recv 72 VCL_acl c NO_MATCH nocache 72 VCL_return c lookup 72 VCL_call c hash hash 72 VCL_call c miss fetch 72 Backend c 73 default default 72 ObjProtocol c HTTP/1.1 72 ObjStatus c 302 72 ObjResponse c Found 72 ObjHeader c Date: Mon, 11 Jan 2010 11:24:29 GMT 72 ObjHeader c Server: Apache 72 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 72 ObjHeader c Expires: 0 72 ObjHeader c Cache-Control: no-cache 72 ObjHeader c Pragma: no-cache 72 ObjHeader c Content-Language: ro 72 ObjHeader c Location: http://tv.acasa.ro/tv/index 72 ObjHeader c Content-Type: text/html; charset=UTF-8 72 TTL c 366321140 RFC 120 1263209069 0 0 0 0 72 VCL_call c fetch pass 72 Length c 65 72 VCL_call c deliver deliver 72 TxProtocol c HTTP/1.1 72 TxStatus c 302 72 TxResponse c Found 72 TxHeader c Server: Apache 72 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 72 TxHeader c Expires: 0 72 TxHeader c Cache-Control: no-cache 72 TxHeader c Pragma: no-cache 72 TxHeader c Content-Language: ro 72 TxHeader c Location: http://tv.acasa.ro/tv/index 72 TxHeader c Content-Type: text/html; charset=UTF-8 72 TxHeader c Content-Length: 65 72 TxHeader c Date: Mon, 11 Jan 2010 11:24:29 GMT 72 TxHeader c X-Varnish: 366321140 72 TxHeader c Age: 0 72 TxHeader c Connection: close 72 TxHeader c Via: varnish 72 TxHeader c X-Cache: MISS 72 ReqEnd c 366321140 1263209069.289582968 1263209069.413225889 0.000048876 0.123615980 0.000026941 30 SessionOpen c 66.219.58.34 59751 :80 30 ReqStart c 66.219.58.34 59751 366321073 30 RxRequest c GET 30 RxURL c /trimite?id=1599&action=8 30 RxProtocol c HTTP/1.1 30 RxHeader c User-Agent: MLBot (www.metadatalabs.com/mlbot) 30 RxHeader c Host: filme.acasa.ro 30 RxHeader c Accept-Encoding: gzip, deflate 30 RxHeader c Connection: Close 30 VCL_call c recv 30 VCL_acl c NO_MATCH nocache 30 VCL_return c lookup 30 VCL_call c hash hash 30 VCL_call c miss fetch 30 Backend c 44 default default 30 ObjProtocol c HTTP/1.1 30 ObjStatus c 302 30 ObjResponse c Found 30 ObjHeader c Date: Mon, 11 Jan 2010 11:24:28 GMT 30 ObjHeader c Server: Apache 30 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 30 ObjHeader c Expires: 0 30 ObjHeader c Cache-Control: no-cache 30 ObjHeader c Pragma: no-cache 30 ObjHeader c Content-Language: ro 30 ObjHeader c Location: http://filme.acasa.ro/ 30 ObjHeader c Content-Type: text/html; charset=UTF-8 30 TTL c 366321073 RFC 120 1263209069 0 0 0 0 30 VCL_call c fetch pass 30 Length c 60 30 VCL_call c deliver deliver 30 TxProtocol c HTTP/1.1 30 TxStatus c 302 30 TxResponse c Found 30 TxHeader c Server: Apache 30 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 30 TxHeader c Expires: 0 30 TxHeader c Cache-Control: no-cache 30 TxHeader c Pragma: no-cache 30 TxHeader c Content-Language: ro 30 TxHeader c Location: http://filme.acasa.ro/ 30 TxHeader c Content-Type: text/html; charset=UTF-8 30 TxHeader c Content-Length: 60 30 TxHeader c Date: Mon, 11 Jan 2010 11:24:29 GMT 30 TxHeader c X-Varnish: 366321073 30 TxHeader c Age: 0 30 TxHeader c Connection: close 30 TxHeader c Via: varnish 30 TxHeader c X-Cache: MISS 30 ReqEnd c 366321073 1263209068.610984087 1263209069.800822020 0.000030994 1.189785004 0.000052929 32 SessionOpen c 67.195.115.177 39915 :80 32 ReqStart c 67.195.115.177 39915 366321342 32 RxRequest c GET 32 RxURL c /program-Free_X_TV/2009-08-26/Young-Bung-Part-2-7595120.html 32 RxProtocol c HTTP/1.0 32 RxHeader c Host: tv.acasa.ro 32 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 32 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 32 RxHeader c Accept-Language: en-us,en;q=0.5 32 RxHeader c Accept-Encoding: gzip,deflate 32 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 32 RxHeader c X-LLF-Mime-Type: true 32 VCL_call c recv 32 VCL_acl c NO_MATCH nocache 32 VCL_return c lookup 32 VCL_call c hash hash 32 VCL_call c miss fetch 32 Backend c 40 default default 32 ObjProtocol c HTTP/1.1 32 ObjStatus c 302 32 ObjResponse c Found 32 ObjHeader c Date: Mon, 11 Jan 2010 11:24:30 GMT 32 ObjHeader c Server: Apache 32 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 32 ObjHeader c Expires: 0 32 ObjHeader c Cache-Control: no-cache 32 ObjHeader c Pragma: no-cache 32 ObjHeader c Content-Language: ro 32 ObjHeader c Location: http://tv.acasa.ro/tv/index 32 ObjHeader c Content-Type: text/html; charset=UTF-8 32 TTL c 366321342 RFC 120 1263209071 0 0 0 0 32 VCL_call c fetch pass 32 Length c 65 32 VCL_call c deliver deliver 32 TxProtocol c HTTP/1.1 32 TxStatus c 302 32 TxResponse c Found 32 TxHeader c Server: Apache 32 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 32 TxHeader c Expires: 0 32 TxHeader c Cache-Control: no-cache 32 TxHeader c Pragma: no-cache 32 TxHeader c Content-Language: ro 32 TxHeader c Location: http://tv.acasa.ro/tv/index 32 TxHeader c Content-Type: text/html; charset=UTF-8 32 TxHeader c Content-Length: 65 32 TxHeader c Date: Mon, 11 Jan 2010 11:24:31 GMT 32 TxHeader c X-Varnish: 366321342 32 TxHeader c Age: 0 32 TxHeader c Connection: close 32 TxHeader c Via: varnish 32 TxHeader c X-Cache: MISS 32 ReqEnd c 366321342 1263209070.736852884 1263209071.098532915 0.000047922 0.361602068 0.000077963 17 SessionOpen c 67.195.115.177 40320 :80 17 ReqStart c 67.195.115.177 40320 366321761 17 RxRequest c GET 17 RxURL c /program-Antena_1/2010-01-03/Bubuiala-in-Bronx-8710953.html 17 RxProtocol c HTTP/1.0 17 RxHeader c Host: tv.acasa.ro 17 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 17 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 17 RxHeader c Accept-Language: en-us,en;q=0.5 17 RxHeader c Accept-Encoding: gzip,deflate 17 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 17 RxHeader c X-LLF-Mime-Type: true 17 VCL_call c recv 17 VCL_acl c NO_MATCH nocache 17 VCL_return c lookup 17 VCL_call c hash hash 17 VCL_call c miss fetch 17 Backend c 49 default default 17 ObjProtocol c HTTP/1.1 17 ObjStatus c 302 17 ObjResponse c Found 17 ObjHeader c Date: Mon, 11 Jan 2010 11:24:36 GMT 17 ObjHeader c Server: Apache 17 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 ObjHeader c Expires: 0 17 ObjHeader c Cache-Control: no-cache 17 ObjHeader c Pragma: no-cache 17 ObjHeader c Content-Language: ro 17 ObjHeader c Location: http://tv.acasa.ro/tv/index 17 ObjHeader c Content-Type: text/html; charset=UTF-8 17 TTL c 366321761 RFC 120 1263209076 0 0 0 0 17 VCL_call c fetch pass 17 Length c 65 17 VCL_call c deliver deliver 17 TxProtocol c HTTP/1.1 17 TxStatus c 302 17 TxResponse c Found 17 TxHeader c Server: Apache 17 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 TxHeader c Expires: 0 17 TxHeader c Cache-Control: no-cache 17 TxHeader c Pragma: no-cache 17 TxHeader c Content-Language: ro 17 TxHeader c Location: http://tv.acasa.ro/tv/index 17 TxHeader c Content-Type: text/html; charset=UTF-8 17 TxHeader c Content-Length: 65 17 TxHeader c Date: Mon, 11 Jan 2010 11:24:36 GMT 17 TxHeader c X-Varnish: 366321761 17 TxHeader c Age: 0 17 TxHeader c Connection: close 17 TxHeader c Via: varnish 17 TxHeader c X-Cache: MISS 17 ReqEnd c 366321761 1263209076.188973904 1263209076.328357935 0.002816916 0.139302015 0.000082016 25 SessionOpen c 95.108.156.251 49483 :80 25 ReqStart c 95.108.156.251 49483 366321906 25 RxRequest c GET 25 RxURL c /program-Viasat_History/2009-05-11/Adev-ratul-hobbit-6524391-r40.html 25 RxProtocol c HTTP/1.1 25 RxHeader c Host: tv.acasa.ro 25 RxHeader c Connection: Keep-Alive 25 RxHeader c Accept: */* 25 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 25 RxHeader c Accept-Encoding: gzip,deflate 25 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 25 RxHeader c From: webadmin at yandex.ru 25 VCL_call c recv 25 VCL_acl c NO_MATCH nocache 25 VCL_return c lookup 25 VCL_call c hash hash 25 VCL_call c miss fetch 25 Backend c 27 default default 25 ObjProtocol c HTTP/1.1 25 ObjStatus c 302 25 ObjResponse c Found 25 ObjHeader c Date: Mon, 11 Jan 2010 11:24:40 GMT 25 ObjHeader c Server: Apache 25 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 25 ObjHeader c Expires: 0 25 ObjHeader c Cache-Control: no-cache 25 ObjHeader c Pragma: no-cache 25 ObjHeader c Content-Language: ro 25 ObjHeader c Location: http://tv.acasa.ro/tv/index 25 ObjHeader c Content-Type: text/html; charset=UTF-8 25 TTL c 366321906 RFC 120 1263209080 0 0 0 0 25 VCL_call c fetch pass 25 Length c 65 25 VCL_call c deliver deliver 25 TxProtocol c HTTP/1.1 25 TxStatus c 302 25 TxResponse c Found 25 TxHeader c Server: Apache 25 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 25 TxHeader c Expires: 0 25 TxHeader c Cache-Control: no-cache 25 TxHeader c Pragma: no-cache 25 TxHeader c Content-Language: ro 25 TxHeader c Location: http://tv.acasa.ro/tv/index 25 TxHeader c Content-Type: text/html; charset=UTF-8 25 TxHeader c Content-Length: 65 25 TxHeader c Date: Mon, 11 Jan 2010 11:24:40 GMT 25 TxHeader c X-Varnish: 366321906 25 TxHeader c Age: 0 25 TxHeader c Connection: keep-alive 25 TxHeader c Via: varnish 25 TxHeader c X-Cache: MISS 25 ReqEnd c 366321906 1263209080.366153955 1263209080.536679983 0.000063896 0.170443058 0.000082970 65 SessionOpen c 89.121.228.98 26181 :80 65 ReqStart c 89.121.228.98 26181 366322237 65 RxRequest c GET 65 RxURL c /post?id=-1&zi=0&buton=Afiseaza 65 RxProtocol c HTTP/1.1 65 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsd ocument, application/x-ms-xbap, application/x-ms-application, */* 65 RxHeader c Referer: http://tv.acasa.ro/program_Eurosport_2_--p65.html 65 RxHeader c Accept-Language: en-us 65 RxHeader c Accept-Encoding: gzip, deflate 65 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) 65 RxHeader c Host: tv.acasa.ro 65 RxHeader c Connection: Keep-Alive 65 RxHeader c Cookie: trafic_h=2fadcc0dd820lf4a91244336e93f91dc*1245752081*acasa.ro*1261047943*1263210598*7; __utma=240209555.493689617.1245752081.1261 047944.1263210598.7; __utmz=240209555.1261047944.6.5.utmccn=(organic)|utmcsr=google|utmctr=program+tvr1|utmcmd=organic 65 VCL_call c recv 65 VCL_acl c NO_MATCH nocache 65 VCL_return c pass 65 VCL_call c pass pass 65 Backend c 76 default default 65 ObjProtocol c HTTP/1.1 65 ObjStatus c 302 65 ObjResponse c Found 65 ObjHeader c Date: Mon, 11 Jan 2010 11:24:47 GMT 65 ObjHeader c Server: Apache 65 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 65 ObjHeader c Expires: 0 65 ObjHeader c Cache-Control: no-cache 65 ObjHeader c Pragma: no-cache 65 ObjHeader c Content-Language: ro 65 ObjHeader c Location: http://tv.acasa.ro/tv/error 65 ObjHeader c Content-Type: text/html; charset=UTF-8 65 TTL c 366322237 RFC 120 1263209087 0 0 0 0 65 VCL_call c fetch pass 65 Length c 65 65 VCL_call c deliver deliver 65 TxProtocol c HTTP/1.1 65 TxStatus c 302 65 TxResponse c Found 65 TxHeader c Server: Apache 65 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 65 TxHeader c Expires: 0 65 TxHeader c Cache-Control: no-cache 65 TxHeader c Pragma: no-cache 65 TxHeader c Content-Language: ro 65 TxHeader c Location: http://tv.acasa.ro/tv/error 65 TxHeader c Content-Type: text/html; charset=UTF-8 65 TxHeader c Content-Length: 65 65 TxHeader c Date: Mon, 11 Jan 2010 11:24:47 GMT 65 TxHeader c X-Varnish: 366322237 65 TxHeader c Age: 0 65 TxHeader c Connection: keep-alive 65 TxHeader c Via: varnish 65 TxHeader c X-Cache: MISS 65 ReqEnd c 366322237 1263209087.247160912 1263209087.421528101 0.000051022 0.174306154 0.000061035 41 ReqStart c 67.195.115.177 41450 366322562 41 RxRequest c GET 41 RxURL c /program-Boomerang/2010-01-11/Time-Squad-8874908-r81.html 41 RxProtocol c HTTP/1.0 41 RxHeader c Host: tv.acasa.ro 41 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 41 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 41 RxHeader c Accept-Language: en-us,en;q=0.5 41 RxHeader c Accept-Encoding: gzip,deflate 41 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 41 RxHeader c X-LLF-Mime-Type: true 41 VCL_call c recv 41 VCL_acl c NO_MATCH nocache 41 VCL_return c lookup 41 VCL_call c hash hash 41 VCL_call c miss fetch 41 Backend c 71 default default 41 ObjProtocol c HTTP/1.1 41 ObjStatus c 302 41 ObjResponse c Found 41 ObjHeader c Date: Mon, 11 Jan 2010 11:24:52 GMT 41 ObjHeader c Server: Apache 41 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 ObjHeader c Expires: 0 41 ObjHeader c Cache-Control: no-cache 41 ObjHeader c Pragma: no-cache 41 ObjHeader c Content-Language: ro 41 ObjHeader c Location: http://tv.acasa.ro/tv/index 41 ObjHeader c Content-Type: text/html; charset=UTF-8 41 TTL c 366322562 RFC 120 1263209092 0 0 0 0 41 VCL_call c fetch pass 41 Length c 65 41 VCL_call c deliver deliver 41 TxProtocol c HTTP/1.1 41 TxStatus c 302 41 TxResponse c Found 41 TxHeader c Server: Apache 41 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 TxHeader c Expires: 0 41 TxHeader c Cache-Control: no-cache 41 TxHeader c Pragma: no-cache 41 TxHeader c Content-Language: ro 41 TxHeader c Location: http://tv.acasa.ro/tv/index 41 TxHeader c Content-Type: text/html; charset=UTF-8 41 TxHeader c Content-Length: 65 41 TxHeader c Date: Mon, 11 Jan 2010 11:24:52 GMT 41 TxHeader c X-Varnish: 366322562 41 TxHeader c Age: 0 41 TxHeader c Connection: close 41 TxHeader c Via: varnish 41 TxHeader c X-Cache: MISS 41 ReqEnd c 366322562 1263209092.061244011 1263209092.187077999 0.000054121 0.125745058 0.000088930 47 SessionOpen c 67.195.115.177 41823 :80 47 ReqStart c 67.195.115.177 41823 366322791 47 RxRequest c GET 47 RxURL c /program-Free_X_TV/2009-12-10/Perversions-Part-1-8625061-r87.html 47 RxProtocol c HTTP/1.0 47 RxHeader c Host: tv.acasa.ro 47 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 47 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 47 RxHeader c Accept-Language: en-us,en;q=0.5 47 RxHeader c Accept-Encoding: gzip,deflate 47 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 47 RxHeader c X-LLF-Mime-Type: true 47 VCL_call c recv 47 VCL_acl c NO_MATCH nocache 47 VCL_return c lookup 47 VCL_call c hash hash 47 VCL_call c miss fetch 47 Backend c 51 default default 47 ObjProtocol c HTTP/1.1 47 ObjStatus c 302 47 ObjResponse c Found 47 ObjHeader c Date: Mon, 11 Jan 2010 11:24:57 GMT 47 ObjHeader c Server: Apache 47 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 47 ObjHeader c Expires: 0 47 ObjHeader c Cache-Control: no-cache 47 ObjHeader c Pragma: no-cache 47 ObjHeader c Content-Language: ro 47 ObjHeader c Location: http://tv.acasa.ro/tv/index 47 ObjHeader c Content-Type: text/html; charset=UTF-8 47 TTL c 366322791 RFC 120 1263209097 0 0 0 0 47 VCL_call c fetch pass 47 Length c 65 47 VCL_call c deliver deliver 47 TxProtocol c HTTP/1.1 47 TxStatus c 302 47 TxResponse c Found 47 TxHeader c Server: Apache 47 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 47 TxHeader c Expires: 0 47 TxHeader c Cache-Control: no-cache 47 TxHeader c Pragma: no-cache 47 TxHeader c Content-Language: ro 47 TxHeader c Location: http://tv.acasa.ro/tv/index 47 TxHeader c Content-Type: text/html; charset=UTF-8 47 TxHeader c Content-Length: 65 47 TxHeader c Date: Mon, 11 Jan 2010 11:24:57 GMT 47 TxHeader c X-Varnish: 366322791 47 TxHeader c Age: 0 47 TxHeader c Connection: close 47 TxHeader c Via: varnish 47 TxHeader c X-Cache: MISS 47 ReqEnd c 366322791 1263209097.134958982 1263209097.305356979 0.004021883 0.170340061 0.000057936 28 SessionOpen c 66.249.65.57 33090 :80 28 ReqStart c 66.249.65.57 33090 366322843 28 RxRequest c GET 28 RxURL c /program-TCM/2008-09-04/Fetele-4422007-r54.html 28 RxProtocol c HTTP/1.1 28 RxHeader c Host: tv.acasa.ro 28 RxHeader c Connection: Keep-alive 28 RxHeader c Accept: text/html,*/*;q=0.9 28 RxHeader c From: googlebot(at)googlebot.com 28 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 28 RxHeader c Accept-Encoding: gzip,deflate 28 VCL_call c recv 28 VCL_acl c NO_MATCH nocache 28 VCL_return c lookup 28 VCL_call c hash hash 28 VCL_call c miss fetch 28 Backend c 30 default default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 302 28 ObjResponse c Found 28 ObjHeader c Date: Mon, 11 Jan 2010 11:24:57 GMT 28 ObjHeader c Server: Apache 28 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 ObjHeader c Expires: 0 28 ObjHeader c Cache-Control: no-cache 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Content-Language: ro 28 ObjHeader c Location: http://tv.acasa.ro/tv/index 28 ObjHeader c Content-Type: text/html; charset=UTF-8 28 TTL c 366322843 RFC 120 1263209098 0 0 0 0 28 VCL_call c fetch pass 28 Length c 65 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 302 28 TxResponse c Found 28 TxHeader c Server: Apache 28 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 TxHeader c Expires: 0 28 TxHeader c Cache-Control: no-cache 28 TxHeader c Pragma: no-cache 28 TxHeader c Content-Language: ro 28 TxHeader c Location: http://tv.acasa.ro/tv/index 28 TxHeader c Content-Type: text/html; charset=UTF-8 28 TxHeader c Content-Length: 65 28 TxHeader c Date: Mon, 11 Jan 2010 11:24:58 GMT 28 TxHeader c X-Varnish: 366322843 28 TxHeader c Age: 0 28 TxHeader c Connection: keep-alive 28 TxHeader c Via: varnish 28 TxHeader c X-Cache: MISS 28 ReqEnd c 366322843 1263209097.941236973 1263209098.080569029 0.000041008 0.139258146 0.000073910 31 SessionOpen c 66.249.65.57 52171 :80 31 ReqStart c 66.249.65.57 52171 366323123 31 RxRequest c GET 31 RxURL c /program-TCM/2008-09-04/Colina-4422005-r54.html 31 RxProtocol c HTTP/1.1 31 RxHeader c Host: tv.acasa.ro 31 RxHeader c Connection: Keep-alive 31 RxHeader c Accept: text/html,*/*;q=0.9 31 RxHeader c From: googlebot(at)googlebot.com 31 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 31 RxHeader c Accept-Encoding: gzip,deflate 31 VCL_call c recv 31 VCL_acl c NO_MATCH nocache 31 VCL_return c lookup 31 VCL_call c hash hash 31 VCL_call c miss fetch 31 Backend c 37 default default 31 ObjProtocol c HTTP/1.1 31 ObjStatus c 302 31 ObjResponse c Found 31 ObjHeader c Date: Mon, 11 Jan 2010 11:25:06 GMT 31 ObjHeader c Server: Apache 31 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 ObjHeader c Expires: 0 31 ObjHeader c Cache-Control: no-cache 31 ObjHeader c Pragma: no-cache 31 ObjHeader c Content-Language: ro 31 ObjHeader c Location: http://tv.acasa.ro/tv/index 31 ObjHeader c Content-Type: text/html; charset=UTF-8 31 TTL c 366323123 RFC 120 1263209107 0 0 0 0 31 VCL_call c fetch pass 31 Length c 65 31 VCL_call c deliver deliver 31 TxProtocol c HTTP/1.1 31 TxStatus c 302 31 TxResponse c Found 31 TxHeader c Server: Apache 31 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 TxHeader c Expires: 0 31 TxHeader c Cache-Control: no-cache 31 TxHeader c Pragma: no-cache 31 TxHeader c Content-Language: ro 31 TxHeader c Location: http://tv.acasa.ro/tv/index 31 TxHeader c Content-Type: text/html; charset=UTF-8 31 TxHeader c Content-Length: 65 31 TxHeader c Date: Mon, 11 Jan 2010 11:25:07 GMT 31 TxHeader c X-Varnish: 366323123 31 TxHeader c Age: 0 31 TxHeader c Connection: keep-alive 31 TxHeader c Via: varnish 31 TxHeader c X-Cache: MISS 31 ReqEnd c 366323123 1263209106.994518995 1263209107.116590977 0.000027895 0.122020960 0.000051022 31 ReqStart c 66.249.65.57 52171 366323290 31 RxRequest c GET 31 RxURL c /program-TCM/2008-09-02/Femei--4421977-r54.html 31 RxProtocol c HTTP/1.1 31 RxHeader c Host: tv.acasa.ro 31 RxHeader c Connection: Keep-alive 31 RxHeader c Accept: text/html,*/*;q=0.9 31 RxHeader c From: googlebot(at)googlebot.com 31 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 31 RxHeader c Accept-Encoding: gzip,deflate 31 VCL_call c recv 31 VCL_acl c NO_MATCH nocache 31 VCL_return c lookup 31 VCL_call c hash hash 31 VCL_call c miss fetch 31 Backend c 64 default default 31 ObjProtocol c HTTP/1.1 31 ObjStatus c 302 31 ObjResponse c Found 31 ObjHeader c Date: Mon, 11 Jan 2010 11:25:09 GMT 31 ObjHeader c Server: Apache 31 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 ObjHeader c Expires: 0 31 ObjHeader c Cache-Control: no-cache 31 ObjHeader c Pragma: no-cache 31 ObjHeader c Content-Language: ro 31 ObjHeader c Location: http://tv.acasa.ro/tv/index 31 ObjHeader c Content-Type: text/html; charset=UTF-8 31 TTL c 366323290 RFC 120 1263209109 0 0 0 0 31 VCL_call c fetch pass 31 Length c 65 31 VCL_call c deliver deliver 31 TxProtocol c HTTP/1.1 31 TxStatus c 302 31 TxResponse c Found 31 TxHeader c Server: Apache 31 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 TxHeader c Expires: 0 31 TxHeader c Cache-Control: no-cache 31 TxHeader c Pragma: no-cache 31 TxHeader c Content-Language: ro 31 TxHeader c Location: http://tv.acasa.ro/tv/index 31 TxHeader c Content-Type: text/html; charset=UTF-8 31 TxHeader c Content-Length: 65 31 TxHeader c Date: Mon, 11 Jan 2010 11:25:09 GMT 31 TxHeader c X-Varnish: 366323290 31 TxHeader c Age: 0 31 TxHeader c Connection: keep-alive 31 TxHeader c Via: varnish 31 TxHeader c X-Cache: MISS 31 ReqEnd c 366323290 1263209109.468569040 1263209109.588176012 2.351978064 0.119526863 0.000080109 62 SessionOpen c 83.202.143.198 2068 :80 62 ReqStart c 83.202.143.198 2068 366323644 62 RxRequest c GET 62 RxURL c /program-B1/2010-01-01/Lombarzilor-8-8670073.html 62 RxProtocol c HTTP/1.1 62 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsd ocument, application/x-ms-xbap, application/x-ms-application, */* 62 RxHeader c Referer: http://www.google.fr/search?sourceid=navclient&hl=ro&ie=UTF-8&rlz=1T4GGLL_roFR354FR354&q=8+ianuarie+program+tv 62 RxHeader c Accept-Language: en-us 62 RxHeader c Accept-Encoding: gzip, deflate 62 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6.3; SIMBAR={50F0B6ED-271E-43AC-8522-3906734F492D}; .NET CLR 2.0.5 0727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM) 62 RxHeader c Host: tv.acasa.ro 62 RxHeader c Connection: Keep-Alive 62 RxHeader c Cookie: trafic_h=8e475b77l4ddb2b3397d23c81cfdd91a*1260745347*acasa.ro*1260745347*1263208909*2; __utma=240209555.303919325.1260745347.1260 745347.1263208909.2; __utmz=240209555.1263208909.2.2.utmccn=(organic)|utmcsr=google|utmctr=program+tv+8+ianuarie+kanal 62 VCL_call c recv 62 VCL_acl c NO_MATCH nocache 62 VCL_return c pass 62 VCL_call c pass pass 62 Backend c 98 default default 62 ObjProtocol c HTTP/1.1 62 ObjStatus c 302 62 ObjResponse c Found 62 ObjHeader c Date: Mon, 11 Jan 2010 11:25:15 GMT 62 ObjHeader c Server: Apache 62 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 62 ObjHeader c Expires: 0 62 ObjHeader c Cache-Control: no-cache 62 ObjHeader c Pragma: no-cache 62 ObjHeader c Content-Language: ro 62 ObjHeader c Location: http://tv.acasa.ro/tv/index 62 ObjHeader c Content-Type: text/html; charset=UTF-8 62 TTL c 366323644 RFC 120 1263209115 0 0 0 0 62 VCL_call c fetch pass 62 Length c 65 62 VCL_call c deliver deliver 62 TxProtocol c HTTP/1.1 62 TxStatus c 302 62 TxResponse c Found 62 TxHeader c Server: Apache 62 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 62 TxHeader c Expires: 0 62 TxHeader c Cache-Control: no-cache 62 TxHeader c Pragma: no-cache 62 TxHeader c Content-Language: ro 62 TxHeader c Location: http://tv.acasa.ro/tv/index 62 TxHeader c Content-Type: text/html; charset=UTF-8 62 TxHeader c Content-Length: 65 62 TxHeader c Date: Mon, 11 Jan 2010 11:25:15 GMT 62 TxHeader c X-Varnish: 366323644 62 TxHeader c Age: 0 62 TxHeader c Connection: keep-alive 62 TxHeader c Via: varnish 62 TxHeader c X-Cache: MISS 62 ReqEnd c 366323644 1263209115.258220911 1263209115.392110109 0.000057936 0.133855104 0.000034094 51 SessionOpen c 66.249.65.57 42130 :80 51 ReqStart c 66.249.65.57 42130 366324028 51 RxRequest c GET 51 RxURL c /program-TCM/2008-09-04/Topkapi-4422006-r54.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c Connection: Keep-alive 51 RxHeader c Accept: text/html,*/*;q=0.9 51 RxHeader c From: googlebot(at)googlebot.com 51 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 51 RxHeader c Accept-Encoding: gzip,deflate 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 54 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:25:22 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366324028 RFC 120 1263209122 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:25:22 GMT 51 TxHeader c X-Varnish: 366324028 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366324028 1263209122.813987970 1263209122.936837912 0.000052929 0.122811079 0.000038862 18 SessionOpen c 67.195.115.177 43833 :80 18 ReqStart c 67.195.115.177 43833 366324159 18 RxRequest c GET 18 RxURL c /program-TVR_International/2009-05-16/Un-doctor-pentru-dumneavoastra-6624228-r15.html 18 RxProtocol c HTTP/1.0 18 RxHeader c Host: tv.acasa.ro 18 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 18 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 18 RxHeader c Accept-Language: en-us,en;q=0.5 18 RxHeader c Accept-Encoding: gzip,deflate 18 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 18 RxHeader c X-LLF-Mime-Type: true 18 VCL_call c recv 18 VCL_acl c NO_MATCH nocache 18 VCL_return c lookup 18 VCL_call c hash hash 18 VCL_call c miss fetch 18 Backend c 42 default default 18 ObjProtocol c HTTP/1.1 18 ObjStatus c 302 18 ObjResponse c Found 18 ObjHeader c Date: Mon, 11 Jan 2010 11:25:24 GMT 18 ObjHeader c Server: Apache 18 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 18 ObjHeader c Expires: 0 18 ObjHeader c Cache-Control: no-cache 18 ObjHeader c Pragma: no-cache 18 ObjHeader c Content-Language: ro 18 ObjHeader c Location: http://tv.acasa.ro/tv/index 18 ObjHeader c Content-Type: text/html; charset=UTF-8 18 TTL c 366324159 RFC 120 1263209125 0 0 0 0 18 VCL_call c fetch pass 18 Length c 65 18 VCL_call c deliver deliver 18 TxProtocol c HTTP/1.1 18 TxStatus c 302 18 TxResponse c Found 18 TxHeader c Server: Apache 18 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 18 TxHeader c Expires: 0 18 TxHeader c Cache-Control: no-cache 18 TxHeader c Pragma: no-cache 18 TxHeader c Content-Language: ro 18 TxHeader c Location: http://tv.acasa.ro/tv/index 18 TxHeader c Content-Type: text/html; charset=UTF-8 18 TxHeader c Content-Length: 65 18 TxHeader c Date: Mon, 11 Jan 2010 11:25:25 GMT 18 TxHeader c X-Varnish: 366324159 18 TxHeader c Age: 0 18 TxHeader c Connection: close 18 TxHeader c Via: varnish 18 TxHeader c X-Cache: MISS 18 ReqEnd c 366324159 1263209124.903454065 1263209125.039822102 0.000048161 0.136313915 0.000054121 37 SessionOpen c 67.195.115.177 43988 :80 37 ReqStart c 67.195.115.177 43988 366324350 37 RxRequest c GET 37 RxURL c /program-Zone_Club/2009-12-04/Un-bucatar-in-jurul-lumii-8417254-r99.html 37 RxProtocol c HTTP/1.0 37 RxHeader c Host: tv.acasa.ro 37 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 37 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 37 RxHeader c Accept-Language: en-us,en;q=0.5 37 RxHeader c Accept-Encoding: gzip,deflate 37 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 37 RxHeader c X-LLF-Mime-Type: true 37 VCL_call c recv 37 VCL_acl c NO_MATCH nocache 37 VCL_return c lookup 37 VCL_call c hash hash 37 VCL_call c miss fetch 37 Backend c 125 default default 37 ObjProtocol c HTTP/1.1 37 ObjStatus c 302 37 ObjResponse c Found 37 ObjHeader c Date: Mon, 11 Jan 2010 11:25:27 GMT 37 ObjHeader c Server: Apache 37 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 ObjHeader c Expires: 0 37 ObjHeader c Cache-Control: no-cache 37 ObjHeader c Pragma: no-cache 37 ObjHeader c Content-Language: ro 37 ObjHeader c Location: http://tv.acasa.ro/tv/index 37 ObjHeader c Content-Type: text/html; charset=UTF-8 37 TTL c 366324350 RFC 120 1263209127 0 0 0 0 37 VCL_call c fetch pass 37 Length c 65 37 VCL_call c deliver deliver 37 TxProtocol c HTTP/1.1 37 TxStatus c 302 37 TxResponse c Found 37 TxHeader c Server: Apache 37 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 TxHeader c Expires: 0 37 TxHeader c Cache-Control: no-cache 37 TxHeader c Pragma: no-cache 37 TxHeader c Content-Language: ro 37 TxHeader c Location: http://tv.acasa.ro/tv/index 37 TxHeader c Content-Type: text/html; charset=UTF-8 37 TxHeader c Content-Length: 65 37 TxHeader c Date: Mon, 11 Jan 2010 11:25:27 GMT 37 TxHeader c X-Varnish: 366324350 37 TxHeader c Age: 0 37 TxHeader c Connection: close 37 TxHeader c Via: varnish 37 TxHeader c X-Cache: MISS 37 ReqEnd c 366324350 1263209127.364691973 1263209127.498023987 0.000066996 0.133258104 0.000073910 51 ReqStart c 66.249.65.57 42130 366324642 51 RxRequest c GET 51 RxURL c /program-Antena_3/2008-07-14/Jay-Leno-Show-4119473-r55.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c Connection: Keep-alive 51 RxHeader c Accept: */* 51 RxHeader c From: googlebot(at)googlebot.com 51 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 51 RxHeader c Accept-Encoding: gzip,deflate 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 25 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:25:32 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366324642 RFC 120 1263209132 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:25:32 GMT 51 TxHeader c X-Varnish: 366324642 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366324642 1263209132.320846081 1263209132.442967892 1.579298019 0.122030973 0.000090837 51 ReqStart c 66.249.65.57 42130 366324803 51 RxRequest c GET 51 RxURL c /program-TCM/2008-09-09/Flipper-4431773-r54.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c Connection: Keep-alive 51 RxHeader c Accept: text/html,*/*;q=0.9 51 RxHeader c From: googlebot(at)googlebot.com 51 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 51 RxHeader c Accept-Encoding: gzip,deflate 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 120 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:25:34 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366324803 RFC 120 1263209134 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:25:34 GMT 51 TxHeader c X-Varnish: 366324803 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366324803 1263209134.229955912 1263209134.350137949 1.786988020 0.118399143 0.001782894 124 SessionOpen c 67.195.115.177 44544 :80 124 ReqStart c 67.195.115.177 44544 366324843 124 RxRequest c GET 124 RxURL c /tv/film?return=3&zi=13&id=4092516&newsletter=1 124 RxProtocol c HTTP/1.0 124 RxHeader c Host: tv.acasa.ro 124 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 124 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 124 RxHeader c Accept-Language: en-us,en;q=0.5 124 RxHeader c Accept-Encoding: gzip,deflate 124 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 124 RxHeader c X-LLF-Mime-Type: true 124 VCL_call c recv 124 VCL_acl c NO_MATCH nocache 124 VCL_return c lookup 124 VCL_call c hash hash 124 VCL_call c miss fetch 124 Backend c 125 default default 124 ObjProtocol c HTTP/1.1 124 ObjStatus c 302 124 ObjResponse c Found 124 ObjHeader c Date: Mon, 11 Jan 2010 11:25:35 GMT 124 ObjHeader c Server: Apache 124 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 124 ObjHeader c Expires: 0 124 ObjHeader c Cache-Control: no-cache 124 ObjHeader c Pragma: no-cache 124 ObjHeader c Content-Language: ro 124 ObjHeader c Location: http://tv.acasa.ro/tv/index 124 ObjHeader c Content-Type: text/html; charset=UTF-8 124 TTL c 366324843 RFC 120 1263209137 0 0 0 0 124 VCL_call c fetch pass 124 Length c 65 124 VCL_call c deliver deliver 124 TxProtocol c HTTP/1.1 124 TxStatus c 302 124 TxResponse c Found 124 TxHeader c Server: Apache 124 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 124 TxHeader c Expires: 0 124 TxHeader c Cache-Control: no-cache 124 TxHeader c Pragma: no-cache 124 TxHeader c Content-Language: ro 124 TxHeader c Location: http://tv.acasa.ro/tv/index 124 TxHeader c Content-Type: text/html; charset=UTF-8 124 TxHeader c Content-Length: 65 124 TxHeader c Date: Mon, 11 Jan 2010 11:25:37 GMT 124 TxHeader c X-Varnish: 366324843 124 TxHeader c Age: 0 124 TxHeader c Connection: close 124 TxHeader c Via: varnish 124 TxHeader c X-Cache: MISS 124 ReqEnd c 366324843 1263209135.015202045 1263209137.932734013 0.000077009 2.917487860 0.000044107 35 SessionOpen c 67.195.115.177 44815 :80 35 ReqStart c 67.195.115.177 44815 366325130 35 RxRequest c GET 35 RxURL c /program-B1/2010-01-05/Stiri-8759383-r22.html 35 RxProtocol c HTTP/1.0 35 RxHeader c Host: tv.acasa.ro 35 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 35 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 35 RxHeader c Accept-Language: en-us,en;q=0.5 35 RxHeader c Accept-Encoding: gzip,deflate 35 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 35 RxHeader c X-LLF-Mime-Type: true 35 VCL_call c recv 35 VCL_acl c NO_MATCH nocache 35 VCL_return c lookup 35 VCL_call c hash hash 35 VCL_call c miss fetch 35 Backend c 44 default default 35 ObjProtocol c HTTP/1.1 35 ObjStatus c 302 35 ObjResponse c Found 35 ObjHeader c Date: Mon, 11 Jan 2010 11:25:38 GMT 35 ObjHeader c Server: Apache 35 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 35 ObjHeader c Expires: 0 35 ObjHeader c Cache-Control: no-cache 35 ObjHeader c Pragma: no-cache 35 ObjHeader c Content-Language: ro 35 ObjHeader c Location: http://tv.acasa.ro/tv/index 35 ObjHeader c Content-Type: text/html; charset=UTF-8 35 TTL c 366325130 RFC 120 1263209139 0 0 0 0 35 VCL_call c fetch pass 35 Length c 65 35 VCL_call c deliver deliver 35 TxProtocol c HTTP/1.1 35 TxStatus c 302 35 TxResponse c Found 35 TxHeader c Server: Apache 35 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 35 TxHeader c Expires: 0 35 TxHeader c Cache-Control: no-cache 35 TxHeader c Pragma: no-cache 35 TxHeader c Content-Language: ro 35 TxHeader c Location: http://tv.acasa.ro/tv/index 35 TxHeader c Content-Type: text/html; charset=UTF-8 35 TxHeader c Content-Length: 65 35 TxHeader c Date: Mon, 11 Jan 2010 11:25:39 GMT 35 TxHeader c X-Varnish: 366325130 35 TxHeader c Age: 0 35 TxHeader c Connection: close 35 TxHeader c Via: varnish 35 TxHeader c X-Cache: MISS 35 ReqEnd c 366325130 1263209138.842056036 1263209139.085685015 0.000082016 0.243470907 0.000158072 51 ReqStart c 66.249.65.57 42130 366325171 51 RxRequest c GET 51 RxURL c /program-Acas_TV/2010-01-11/Vremea-de-ACASA-8834016.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c Connection: Keep-alive 51 RxHeader c Accept: */* 51 RxHeader c From: googlebot(at)googlebot.com 51 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 51 RxHeader c Accept-Encoding: gzip,deflate 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 35 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:25:39 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366325171 RFC 120 1263209139 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:25:39 GMT 51 TxHeader c X-Varnish: 366325171 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366325171 1263209139.370296955 1263209139.506752014 5.020159006 0.136399031 0.000056028 113 SessionOpen c 95.108.156.251 49421 :80 113 ReqStart c 95.108.156.251 49421 366325525 113 RxRequest c GET 113 RxURL c /program-TVR_1/2010-01-12/Jocurile-Olimpice-de-Iarna-Vancouver-2010-8849561-r1.html 113 RxProtocol c HTTP/1.1 113 RxHeader c Host: tv.acasa.ro 113 RxHeader c Connection: Keep-Alive 113 RxHeader c Accept: */* 113 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 113 RxHeader c Accept-Encoding: gzip,deflate 113 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 113 RxHeader c From: webadmin at yandex.ru 113 VCL_call c recv 113 VCL_acl c NO_MATCH nocache 113 VCL_return c lookup 113 VCL_call c hash hash 113 VCL_call c miss fetch 113 Backend c 120 default default 113 ObjProtocol c HTTP/1.1 113 ObjStatus c 302 113 ObjResponse c Found 113 ObjHeader c Date: Mon, 11 Jan 2010 11:25:42 GMT 113 ObjHeader c Server: Apache 113 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 113 ObjHeader c Expires: 0 113 ObjHeader c Cache-Control: no-cache 113 ObjHeader c Pragma: no-cache 113 ObjHeader c Content-Language: ro 113 ObjHeader c Location: http://tv.acasa.ro/tv/index 113 ObjHeader c Content-Type: text/html; charset=UTF-8 113 TTL c 366325525 RFC 120 1263209142 0 0 0 0 113 VCL_call c fetch pass 113 Length c 65 113 VCL_call c deliver deliver 113 TxProtocol c HTTP/1.1 113 TxStatus c 302 113 TxResponse c Found 113 TxHeader c Server: Apache 113 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 113 TxHeader c Expires: 0 113 TxHeader c Cache-Control: no-cache 113 TxHeader c Pragma: no-cache 113 TxHeader c Content-Language: ro 113 TxHeader c Location: http://tv.acasa.ro/tv/index 113 TxHeader c Content-Type: text/html; charset=UTF-8 113 TxHeader c Content-Length: 65 113 TxHeader c Date: Mon, 11 Jan 2010 11:25:42 GMT 113 TxHeader c X-Varnish: 366325525 113 TxHeader c Age: 0 113 TxHeader c Connection: keep-alive 113 TxHeader c Via: varnish 113 TxHeader c X-Cache: MISS 113 ReqEnd c 366325525 1263209142.453358889 1263209142.607198000 0.000050783 0.153777122 0.000061989 66 SessionOpen c 66.249.65.2 49730 :80 66 ReqStart c 66.249.65.2 49730 366325892 66 RxRequest c GET 66 RxURL c /referate_Biologie_p_-398958616.html 66 RxProtocol c HTTP/1.1 66 RxHeader c Host: referate.acasa.ro 66 RxHeader c Connection: Keep-alive 66 RxHeader c Accept: */* 66 RxHeader c From: googlebot(at)googlebot.com 66 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 66 RxHeader c Accept-Encoding: gzip,deflate 66 VCL_call c recv 66 VCL_acl c NO_MATCH nocache 66 VCL_return c lookup 66 VCL_call c hash hash 66 VCL_call c miss fetch 66 Backend c 74 default default 66 ObjProtocol c HTTP/1.1 66 ObjStatus c 302 66 ObjResponse c Found 66 ObjHeader c Date: Mon, 11 Jan 2010 11:25:46 GMT 66 ObjHeader c Server: Apache 66 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 ObjHeader c Expires: 0 66 ObjHeader c Cache-Control: no-cache 66 ObjHeader c Pragma: no-cache 66 ObjHeader c Content-Language: ro 66 ObjHeader c Location: http://referate.acasa.ro/referate/index 66 ObjHeader c Content-Type: text/html; charset=utf-8 66 TTL c 366325892 RFC 120 1263209146 0 0 0 0 66 VCL_call c fetch pass 66 Length c 77 66 VCL_call c deliver deliver 66 TxProtocol c HTTP/1.1 66 TxStatus c 302 66 TxResponse c Found 66 TxHeader c Server: Apache 66 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 TxHeader c Expires: 0 66 TxHeader c Cache-Control: no-cache 66 TxHeader c Pragma: no-cache 66 TxHeader c Content-Language: ro 66 TxHeader c Location: http://referate.acasa.ro/referate/index 66 TxHeader c Content-Type: text/html; charset=utf-8 66 TxHeader c Content-Length: 77 66 TxHeader c Date: Mon, 11 Jan 2010 11:25:46 GMT 66 TxHeader c X-Varnish: 366325892 66 TxHeader c Age: 0 66 TxHeader c Connection: keep-alive 66 TxHeader c Via: varnish 66 TxHeader c X-Cache: MISS 66 ReqEnd c 366325892 1263209146.802685022 1263209146.875360012 0.000060081 0.072617054 0.000057936 51 ReqStart c 66.249.65.57 42130 366326304 51 RxRequest c GET 51 RxURL c /program-TCM/2008-09-02/Ultrajul-4421984-r54.html 51 RxProtocol c HTTP/1.1 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c Connection: Keep-alive 51 RxHeader c Accept: text/html,*/*;q=0.9 51 RxHeader c From: googlebot(at)googlebot.com 51 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 51 RxHeader c Accept-Encoding: gzip,deflate 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 21 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:25:52 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366326304 RFC 120 1263209152 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:25:52 GMT 51 TxHeader c X-Varnish: 366326304 51 TxHeader c Age: 0 51 TxHeader c Connection: keep-alive 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366326304 1263209152.068058968 1263209152.323867083 1.707427025 0.255728960 0.000079155 41 SessionOpen c 79.115.81.147 51189 :80 41 ReqStart c 79.115.81.147 51189 366327172 41 RxRequest c GET 41 RxURL c /program-Acasa-TV/2009-12-28/Tequila-cu-suflet-de-femeie-mexican-serial-2007-45-Ultimul-episod-8700049.html 41 RxProtocol c HTTP/1.1 41 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xa ml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, applicatio 41 RxHeader c Referer: http://www.google.ro/search?hl=ro&source=hp&q=tequila+cu+suflet+de+femeie&meta=&aq=f&oq= 41 RxHeader c Accept-Language: ro 41 RxHeader c UA-CPU: x86 41 RxHeader c Accept-Encoding: gzip, deflate 41 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.30729) 41 RxHeader c Host: tv.acasa.ro 41 RxHeader c Connection: Keep-Alive 41 RxHeader c Cookie: POPUPCHECK=1263293112049; trafic_h=d1f71b3bfddlde9cf1e08d7f786de1de*1263206716*acasa.ro*1263206716*1263206716*1; __utma=240209555 .827528656.1263206716.1263206716.1263206716.1; __utmc=240209555; __utmz=240209555.1263206716.1.1.utmccn=(organic)|utmc 41 VCL_call c recv 41 VCL_acl c NO_MATCH nocache 41 VCL_return c pass 41 VCL_call c pass pass 41 Backend c 49 default default 41 ObjProtocol c HTTP/1.1 41 ObjStatus c 302 41 ObjResponse c Found 41 ObjHeader c Date: Mon, 11 Jan 2010 11:26:05 GMT 41 ObjHeader c Server: Apache 41 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 ObjHeader c Expires: 0 41 ObjHeader c Cache-Control: no-cache 41 ObjHeader c Pragma: no-cache 41 ObjHeader c Content-Language: ro 41 ObjHeader c Location: http://tv.acasa.ro/tv/index 41 ObjHeader c Content-Type: text/html; charset=UTF-8 41 TTL c 366327172 RFC 120 1263209166 0 0 0 0 41 VCL_call c fetch pass 41 Length c 65 41 VCL_call c deliver deliver 41 TxProtocol c HTTP/1.1 41 TxStatus c 302 41 TxResponse c Found 41 TxHeader c Server: Apache 41 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 TxHeader c Expires: 0 41 TxHeader c Cache-Control: no-cache 41 TxHeader c Pragma: no-cache 41 TxHeader c Content-Language: ro 41 TxHeader c Location: http://tv.acasa.ro/tv/index 41 TxHeader c Content-Type: text/html; charset=UTF-8 41 TxHeader c Content-Length: 65 41 TxHeader c Date: Mon, 11 Jan 2010 11:26:06 GMT 41 TxHeader c X-Varnish: 366327172 41 TxHeader c Age: 0 41 TxHeader c Connection: keep-alive 41 TxHeader c Via: varnish 41 TxHeader c X-Cache: MISS 41 ReqEnd c 366327172 1263209165.953711987 1263209166.095284939 0.000065088 0.141511917 0.000061035 121 SessionOpen c 67.195.115.177 47232 :80 121 ReqStart c 67.195.115.177 47232 366327720 121 RxRequest c GET 121 RxURL c /program-TCM/2009-05-08/Orasul-submarin-6413852-r54.html 121 RxProtocol c HTTP/1.0 121 RxHeader c Host: tv.acasa.ro 121 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 121 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 121 RxHeader c Accept-Language: en-us,en;q=0.5 121 RxHeader c Accept-Encoding: gzip,deflate 121 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 121 RxHeader c X-LLF-Mime-Type: true 121 VCL_call c recv 121 VCL_acl c NO_MATCH nocache 121 VCL_return c lookup 121 VCL_call c hash hash 121 VCL_call c miss fetch 121 Backend c 127 default default 121 ObjProtocol c HTTP/1.1 121 ObjStatus c 302 121 ObjResponse c Found 121 ObjHeader c Date: Mon, 11 Jan 2010 11:26:11 GMT 121 ObjHeader c Server: Apache 121 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 121 ObjHeader c Expires: 0 121 ObjHeader c Cache-Control: no-cache 121 ObjHeader c Pragma: no-cache 121 ObjHeader c Content-Language: ro 121 ObjHeader c Location: http://tv.acasa.ro/tv/index 121 ObjHeader c Content-Type: text/html; charset=UTF-8 121 TTL c 366327720 RFC 120 1263209171 0 0 0 0 121 VCL_call c fetch pass 121 Length c 65 121 VCL_call c deliver deliver 121 TxProtocol c HTTP/1.1 121 TxStatus c 302 121 TxResponse c Found 121 TxHeader c Server: Apache 121 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 121 TxHeader c Expires: 0 121 TxHeader c Cache-Control: no-cache 121 TxHeader c Pragma: no-cache 121 TxHeader c Content-Language: ro 121 TxHeader c Location: http://tv.acasa.ro/tv/index 121 TxHeader c Content-Type: text/html; charset=UTF-8 121 TxHeader c Content-Length: 65 121 TxHeader c Date: Mon, 11 Jan 2010 11:26:11 GMT 121 TxHeader c X-Varnish: 366327720 121 TxHeader c Age: 0 121 TxHeader c Connection: close 121 TxHeader c Via: varnish 121 TxHeader c X-Cache: MISS 121 ReqEnd c 366327720 1263209171.705789089 1263209171.839842081 0.000075102 0.133992910 0.000060081 31 ReqStart c 66.249.65.57 51488 366327937 31 RxRequest c GET 31 RxURL c /program-TCM/2008-09-03/Ultrajul-4421988-r54.html 31 RxProtocol c HTTP/1.1 31 RxHeader c Host: tv.acasa.ro 31 RxHeader c Connection: Keep-alive 31 RxHeader c Accept: text/html,*/*;q=0.9 31 RxHeader c From: googlebot(at)googlebot.com 31 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 31 RxHeader c Accept-Encoding: gzip,deflate 31 VCL_call c recv 31 VCL_acl c NO_MATCH nocache 31 VCL_return c lookup 31 VCL_call c hash hash 31 VCL_call c miss fetch 31 Backend c 75 default default 31 ObjProtocol c HTTP/1.1 31 ObjStatus c 302 31 ObjResponse c Found 31 ObjHeader c Date: Mon, 11 Jan 2010 11:26:15 GMT 31 ObjHeader c Server: Apache 31 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 ObjHeader c Expires: 0 31 ObjHeader c Cache-Control: no-cache 31 ObjHeader c Pragma: no-cache 31 ObjHeader c Content-Language: ro 31 ObjHeader c Location: http://tv.acasa.ro/tv/index 31 ObjHeader c Content-Type: text/html; charset=UTF-8 31 TTL c 366327937 RFC 120 1263209176 0 0 0 0 31 VCL_call c fetch pass 31 Length c 65 31 VCL_call c deliver deliver 31 TxProtocol c HTTP/1.1 31 TxStatus c 302 31 TxResponse c Found 31 TxHeader c Server: Apache 31 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 31 TxHeader c Expires: 0 31 TxHeader c Cache-Control: no-cache 31 TxHeader c Pragma: no-cache 31 TxHeader c Content-Language: ro 31 TxHeader c Location: http://tv.acasa.ro/tv/index 31 TxHeader c Content-Type: text/html; charset=UTF-8 31 TxHeader c Content-Length: 65 31 TxHeader c Date: Mon, 11 Jan 2010 11:26:16 GMT 31 TxHeader c X-Varnish: 366327937 31 TxHeader c Age: 0 31 TxHeader c Connection: keep-alive 31 TxHeader c Via: varnish 31 TxHeader c X-Cache: MISS 31 ReqEnd c 366327937 1263209175.964597940 1263209176.120524883 4.020166874 0.155848026 0.000078917 100 SessionOpen c 67.195.115.177 47946 :80 100 ReqStart c 67.195.115.177 47946 366328342 100 RxRequest c GET 100 RxURL c /program-Na_ional_TV/2010-01-05/Jeremiah-8722873.html 100 RxProtocol c HTTP/1.0 100 RxHeader c Host: tv.acasa.ro 100 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 100 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 100 RxHeader c Accept-Language: en-us,en;q=0.5 100 RxHeader c Accept-Encoding: gzip,deflate 100 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 100 RxHeader c X-LLF-Mime-Type: true 100 VCL_call c recv 100 VCL_acl c NO_MATCH nocache 100 VCL_return c lookup 100 VCL_call c hash hash 100 VCL_call c miss fetch 100 Backend c 102 default default 100 ObjProtocol c HTTP/1.1 100 ObjStatus c 302 100 ObjResponse c Found 100 ObjHeader c Date: Mon, 11 Jan 2010 11:26:21 GMT 100 ObjHeader c Server: Apache 100 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 ObjHeader c Expires: 0 100 ObjHeader c Cache-Control: no-cache 100 ObjHeader c Pragma: no-cache 100 ObjHeader c Content-Language: ro 100 ObjHeader c Location: http://tv.acasa.ro/tv/index 100 ObjHeader c Content-Type: text/html; charset=UTF-8 100 TTL c 366328342 RFC 120 1263209181 0 0 0 0 100 VCL_call c fetch pass 100 Length c 65 100 VCL_call c deliver deliver 100 TxProtocol c HTTP/1.1 100 TxStatus c 302 100 TxResponse c Found 100 TxHeader c Server: Apache 100 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 TxHeader c Expires: 0 100 TxHeader c Cache-Control: no-cache 100 TxHeader c Pragma: no-cache 100 TxHeader c Content-Language: ro 100 TxHeader c Location: http://tv.acasa.ro/tv/index 100 TxHeader c Content-Type: text/html; charset=UTF-8 100 TxHeader c Content-Length: 65 100 TxHeader c Date: Mon, 11 Jan 2010 11:26:21 GMT 100 TxHeader c X-Varnish: 366328342 100 TxHeader c Age: 0 100 TxHeader c Connection: close 100 TxHeader c Via: varnish 100 TxHeader c X-Cache: MISS 100 ReqEnd c 366328342 1263209181.505848885 1263209181.636986017 0.000055790 0.131050110 0.000087023 51 SessionOpen c 67.195.115.177 48199 :80 51 ReqStart c 67.195.115.177 48199 366328530 51 RxRequest c GET 51 RxURL c /program-Euforia_Lifestyle_TV/2009-04-12/Iubiri-mondene-6216882-r63.html 51 RxProtocol c HTTP/1.0 51 RxHeader c Host: tv.acasa.ro 51 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 51 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 51 RxHeader c Accept-Language: en-us,en;q=0.5 51 RxHeader c Accept-Encoding: gzip,deflate 51 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 51 RxHeader c X-LLF-Mime-Type: true 51 VCL_call c recv 51 VCL_acl c NO_MATCH nocache 51 VCL_return c lookup 51 VCL_call c hash hash 51 VCL_call c miss fetch 51 Backend c 55 default default 51 ObjProtocol c HTTP/1.1 51 ObjStatus c 302 51 ObjResponse c Found 51 ObjHeader c Date: Mon, 11 Jan 2010 11:26:25 GMT 51 ObjHeader c Server: Apache 51 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 ObjHeader c Expires: 0 51 ObjHeader c Cache-Control: no-cache 51 ObjHeader c Pragma: no-cache 51 ObjHeader c Content-Language: ro 51 ObjHeader c Location: http://tv.acasa.ro/tv/index 51 ObjHeader c Content-Type: text/html; charset=UTF-8 51 TTL c 366328530 RFC 120 1263209185 0 0 0 0 51 VCL_call c fetch pass 51 Length c 65 51 VCL_call c deliver deliver 51 TxProtocol c HTTP/1.1 51 TxStatus c 302 51 TxResponse c Found 51 TxHeader c Server: Apache 51 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 51 TxHeader c Expires: 0 51 TxHeader c Cache-Control: no-cache 51 TxHeader c Pragma: no-cache 51 TxHeader c Content-Language: ro 51 TxHeader c Location: http://tv.acasa.ro/tv/index 51 TxHeader c Content-Type: text/html; charset=UTF-8 51 TxHeader c Content-Length: 65 51 TxHeader c Date: Mon, 11 Jan 2010 11:26:25 GMT 51 TxHeader c X-Varnish: 366328530 51 TxHeader c Age: 0 51 TxHeader c Connection: close 51 TxHeader c Via: varnish 51 TxHeader c X-Cache: MISS 51 ReqEnd c 366328530 1263209185.308249950 1263209185.492196083 0.000054836 0.183866978 0.000079155 94 SessionOpen c 95.108.156.251 61180 :80 94 ReqStart c 95.108.156.251 61180 366328524 94 RxRequest c GET 94 RxURL c /seriale-tv/van-wilder-2-the-rise-of-taj-2006 94 RxProtocol c HTTP/1.1 94 RxHeader c Host: filme.acasa.ro 94 RxHeader c Connection: Keep-Alive 94 RxHeader c Accept: */* 94 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 94 RxHeader c Accept-Encoding: gzip,deflate 94 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 94 RxHeader c From: webadmin at yandex.ru 94 VCL_call c recv 94 VCL_acl c NO_MATCH nocache 94 VCL_return c lookup 94 VCL_call c hash hash 94 VCL_call c miss fetch 94 Backend c 96 default default 94 ObjProtocol c HTTP/1.1 94 ObjStatus c 302 94 ObjResponse c Found 94 ObjHeader c Date: Mon, 11 Jan 2010 11:26:25 GMT 94 ObjHeader c Server: Apache 94 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 94 ObjHeader c Expires: 0 94 ObjHeader c Cache-Control: no-cache 94 ObjHeader c Pragma: no-cache 94 ObjHeader c Content-Language: ro 94 ObjHeader c Location: http://filme.acasa.ro/seriale-tv 94 ObjHeader c Content-Type: text/html; charset=UTF-8 94 TTL c 366328524 RFC 120 1263209186 0 0 0 0 94 VCL_call c fetch pass 94 Length c 70 94 VCL_call c deliver deliver 94 TxProtocol c HTTP/1.1 94 TxStatus c 302 94 TxResponse c Found 94 TxHeader c Server: Apache 94 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 94 TxHeader c Expires: 0 94 TxHeader c Cache-Control: no-cache 94 TxHeader c Pragma: no-cache 94 TxHeader c Content-Language: ro 94 TxHeader c Location: http://filme.acasa.ro/seriale-tv 94 TxHeader c Content-Type: text/html; charset=UTF-8 94 TxHeader c Content-Length: 70 94 TxHeader c Date: Mon, 11 Jan 2010 11:26:26 GMT 94 TxHeader c X-Varnish: 366328524 94 TxHeader c Age: 0 94 TxHeader c Connection: keep-alive 94 TxHeader c Via: varnish 94 TxHeader c X-Cache: MISS 94 ReqEnd c 366328524 1263209185.088525057 1263209186.137048006 0.000053167 1.048461914 0.000061035 76 SessionOpen c 67.195.115.177 48334 :80 76 ReqStart c 67.195.115.177 48334 366328635 76 RxRequest c GET 76 RxURL c /program-Prima_TV/2008-09-28/Al-saptelea-cer-4569236-r5.html 76 RxProtocol c HTTP/1.0 76 RxHeader c Host: tv.acasa.ro 76 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 76 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 76 RxHeader c Accept-Language: en-us,en;q=0.5 76 RxHeader c Accept-Encoding: gzip,deflate 76 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 76 RxHeader c X-LLF-Mime-Type: true 76 VCL_call c recv 76 VCL_acl c NO_MATCH nocache 76 VCL_return c lookup 76 VCL_call c hash hash 76 VCL_call c miss fetch 76 Backend c 77 default default 76 ObjProtocol c HTTP/1.1 76 ObjStatus c 302 76 ObjResponse c Found 76 ObjHeader c Date: Mon, 11 Jan 2010 11:26:26 GMT 76 ObjHeader c Server: Apache 76 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 76 ObjHeader c Expires: 0 76 ObjHeader c Cache-Control: no-cache 76 ObjHeader c Pragma: no-cache 76 ObjHeader c Content-Language: ro 76 ObjHeader c Location: http://tv.acasa.ro/tv/index 76 ObjHeader c Content-Type: text/html; charset=UTF-8 76 TTL c 366328635 RFC 120 1263209189 0 0 0 0 76 VCL_call c fetch pass 76 Length c 65 76 VCL_call c deliver deliver 76 TxProtocol c HTTP/1.1 76 TxStatus c 302 76 TxResponse c Found 76 TxHeader c Server: Apache 76 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 76 TxHeader c Expires: 0 76 TxHeader c Cache-Control: no-cache 76 TxHeader c Pragma: no-cache 76 TxHeader c Content-Language: ro 76 TxHeader c Location: http://tv.acasa.ro/tv/index 76 TxHeader c Content-Type: text/html; charset=UTF-8 76 TxHeader c Content-Length: 65 76 TxHeader c Date: Mon, 11 Jan 2010 11:26:29 GMT 76 TxHeader c X-Varnish: 366328635 76 TxHeader c Age: 0 76 TxHeader c Connection: close 76 TxHeader c Via: varnish 76 TxHeader c X-Cache: MISS 76 ReqEnd c 366328635 1263209186.989571095 1263209189.618046999 0.000092983 2.628443956 0.000031948 39 SessionOpen c 217.10.213.126 1726 :80 39 ReqStart c 217.10.213.126 1726 366328810 39 RxRequest c GET 39 RxURL c /program-Prima_TV/2009-09-13/Fermier-Caut-nevasta--7653172.html 39 RxProtocol c HTTP/1.1 39 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-m s-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-silverlight, */* 39 RxHeader c Referer: http://www.google.ro/search?hl=ro&q=fermier+caut+nevasta+episodul+1&meta=&aq=3&oq=fermier+caut+nevasta+episod 39 RxHeader c Accept-Language: en-us 39 RxHeader c Accept-Encoding: gzip, deflate 39 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET C LR 3.5.30729) 39 RxHeader c Host: tv.acasa.ro 39 RxHeader c Connection: Keep-Alive 39 RxHeader c Cookie: POPUPCHECK=1263295494546; trafic_h=05dba28ffda3e46l10837189cc8f7189*1250985859*acasa.ro*1262849575*1263209113*12; __utma=24020955 5.1771099526.1250985859.1262849575.1263209113.13; __utmz=240209555.1263209113.13.13.utmccn=(organic)|utmcsr=google|utm 39 VCL_call c recv 39 VCL_acl c NO_MATCH nocache 39 VCL_return c pass 39 VCL_call c pass pass 39 Backend c 40 default default 39 ObjProtocol c HTTP/1.1 39 ObjStatus c 302 39 ObjResponse c Found 39 ObjHeader c Date: Mon, 11 Jan 2010 11:26:30 GMT 39 ObjHeader c Server: Apache 39 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 39 ObjHeader c Expires: 0 39 ObjHeader c Cache-Control: no-cache 39 ObjHeader c Pragma: no-cache 39 ObjHeader c Content-Language: ro 39 ObjHeader c Location: http://tv.acasa.ro/tv/index 39 ObjHeader c Content-Type: text/html; charset=UTF-8 39 TTL c 366328810 RFC 120 1263209190 0 0 0 0 39 VCL_call c fetch pass 39 Length c 65 39 VCL_call c deliver deliver 39 TxProtocol c HTTP/1.1 39 TxStatus c 302 39 TxResponse c Found 39 TxHeader c Server: Apache 39 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 39 TxHeader c Expires: 0 39 TxHeader c Cache-Control: no-cache 39 TxHeader c Pragma: no-cache 39 TxHeader c Content-Language: ro 39 TxHeader c Location: http://tv.acasa.ro/tv/index 39 TxHeader c Content-Type: text/html; charset=UTF-8 39 TxHeader c Content-Length: 65 39 TxHeader c Date: Mon, 11 Jan 2010 11:26:30 GMT 39 TxHeader c X-Varnish: 366328810 39 TxHeader c Age: 0 39 TxHeader c Connection: keep-alive 39 TxHeader c Via: varnish 39 TxHeader c X-Cache: MISS 39 ReqEnd c 366328810 1263209190.144804955 1263209190.312735081 0.000073910 0.167819977 0.000110149 81 ReqStart c 66.249.65.57 57714 366329011 81 RxRequest c GET 81 RxURL c /program-TCM/2008-09-03/Cimarron-4421998-r54.html 81 RxProtocol c HTTP/1.1 81 RxHeader c Host: tv.acasa.ro 81 RxHeader c Connection: Keep-alive 81 RxHeader c Accept: text/html,*/*;q=0.9 81 RxHeader c From: googlebot(at)googlebot.com 81 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 81 RxHeader c Accept-Encoding: gzip,deflate 81 VCL_call c recv 81 VCL_acl c NO_MATCH nocache 81 VCL_return c lookup 81 VCL_call c hash hash 81 VCL_call c miss fetch 81 Backend c 78 default default 81 ObjProtocol c HTTP/1.1 81 ObjStatus c 302 81 ObjResponse c Found 81 ObjHeader c Date: Mon, 11 Jan 2010 11:26:35 GMT 81 ObjHeader c Server: Apache 81 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 ObjHeader c Expires: 0 81 ObjHeader c Cache-Control: no-cache 81 ObjHeader c Pragma: no-cache 81 ObjHeader c Content-Language: ro 81 ObjHeader c Location: http://tv.acasa.ro/tv/index 81 ObjHeader c Content-Type: text/html; charset=UTF-8 81 TTL c 366329011 RFC 120 1263209195 0 0 0 0 81 VCL_call c fetch pass 81 Length c 65 81 VCL_call c deliver deliver 81 TxProtocol c HTTP/1.1 81 TxStatus c 302 81 TxResponse c Found 81 TxHeader c Server: Apache 81 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 TxHeader c Expires: 0 81 TxHeader c Cache-Control: no-cache 81 TxHeader c Pragma: no-cache 81 TxHeader c Content-Language: ro 81 TxHeader c Location: http://tv.acasa.ro/tv/index 81 TxHeader c Content-Type: text/html; charset=UTF-8 81 TxHeader c Content-Length: 65 81 TxHeader c Date: Mon, 11 Jan 2010 11:26:35 GMT 81 TxHeader c X-Varnish: 366329011 81 TxHeader c Age: 0 81 TxHeader c Connection: keep-alive 81 TxHeader c Via: varnish 81 TxHeader c X-Cache: MISS 81 ReqEnd c 366329011 1263209195.030405045 1263209195.739120007 1.576182127 0.708664894 0.000050068 114 SessionOpen c 213.233.88.252 54033 :80 114 ReqStart c 213.233.88.252 54033 366329418 114 RxRequest c GET 114 RxURL c /program-Minimax/2009-12-20/Maestrul-Strop-8585208-r23.html 114 RxProtocol c HTTP/1.1 114 RxHeader c Host: tv.acasa.ro 114 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ro; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 114 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 114 RxHeader c Accept-Language: ro-ro,ro;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2 114 RxHeader c Accept-Encoding: gzip,deflate 114 RxHeader c Accept-Charset: UTF-8,* 114 RxHeader c Keep-Alive: 300 114 RxHeader c Connection: keep-alive 114 RxHeader c Referer: http://www.google.ro/url?sa=t&source=web&ct=res&cd=2&ved=0CAkQFjAB&url=http%3A%2F%2Ftv.acasa.ro%2Fprogram-Minimax%2F2009-12-20%2 FMaestrul-Strop-8585208-r23.html&rct=j&q=jocuri+maestrul+strop&ei=1ApLS-mmK4KNjAeW2bWBBw&usg=AFQjCNE1onEycRcuRyH-XZg3N 114 VCL_call c recv 114 VCL_acl c NO_MATCH nocache 114 VCL_return c lookup 114 VCL_call c hash hash 114 VCL_call c miss fetch 114 Backend c 116 default default 114 ObjProtocol c HTTP/1.1 114 ObjStatus c 302 114 ObjResponse c Found 114 ObjHeader c Date: Mon, 11 Jan 2010 11:26:40 GMT 114 ObjHeader c Server: Apache 114 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 114 ObjHeader c Expires: 0 114 ObjHeader c Cache-Control: no-cache 114 ObjHeader c Pragma: no-cache 114 ObjHeader c Content-Language: ro 114 ObjHeader c Location: http://tv.acasa.ro/tv/index 114 ObjHeader c Content-Type: text/html; charset=UTF-8 114 TTL c 366329418 RFC 120 1263209200 0 0 0 0 114 VCL_call c fetch pass 114 Length c 65 114 VCL_call c deliver deliver 114 TxProtocol c HTTP/1.1 114 TxStatus c 302 114 TxResponse c Found 114 TxHeader c Server: Apache 114 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 114 TxHeader c Expires: 0 114 TxHeader c Cache-Control: no-cache 114 TxHeader c Pragma: no-cache 114 TxHeader c Content-Language: ro 114 TxHeader c Location: http://tv.acasa.ro/tv/index 114 TxHeader c Content-Type: text/html; charset=UTF-8 114 TxHeader c Content-Length: 65 114 TxHeader c Date: Mon, 11 Jan 2010 11:26:40 GMT 114 TxHeader c X-Varnish: 366329418 114 TxHeader c Age: 0 114 TxHeader c Connection: keep-alive 114 TxHeader c Via: varnish 114 TxHeader c X-Cache: MISS 114 ReqEnd c 366329418 1263209200.516699076 1263209200.710553885 0.000102997 0.193737984 0.000116825 14 ReqStart c 213.233.88.252 54042 366329621 14 RxRequest c GET 14 RxURL c /program-Minimax/2009-12-20/Maestrul-Strop-8585208-r23.html 14 RxProtocol c HTTP/1.1 14 RxHeader c Host: tv.acasa.ro 14 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ro; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 14 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 14 RxHeader c Accept-Language: ro-ro,ro;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2 14 RxHeader c Accept-Encoding: gzip,deflate 14 RxHeader c Accept-Charset: UTF-8,* 14 RxHeader c Keep-Alive: 300 14 RxHeader c Connection: keep-alive 14 RxHeader c Referer: http://www.google.ro/url?sa=t&source=web&ct=res&cd=2&ved=0CAkQFjAB&url=http%3A%2F%2Ftv.acasa.ro%2Fprogram-Minimax%2F2009-12-20%2 FMaestrul-Strop-8585208-r23.html&rct=j&q=jocuri+maestrul+strop&ei=1ApLS-mmK4KNjAeW2bWBBw&usg=AFQjCNE1onEycRcuRyH-XZg3N 14 VCL_call c recv 14 VCL_acl c NO_MATCH nocache 14 VCL_return c lookup 14 VCL_call c hash hash 14 HitPass c 366329418 14 VCL_call c pass pass 14 Backend c 57 default default 14 ObjProtocol c HTTP/1.1 14 ObjStatus c 302 14 ObjResponse c Found 14 ObjHeader c Date: Mon, 11 Jan 2010 11:26:43 GMT 14 ObjHeader c Server: Apache 14 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 14 ObjHeader c Expires: 0 14 ObjHeader c Cache-Control: no-cache 14 ObjHeader c Pragma: no-cache 14 ObjHeader c Content-Language: ro 14 ObjHeader c Location: http://tv.acasa.ro/tv/index 14 ObjHeader c Content-Type: text/html; charset=UTF-8 14 TTL c 366329621 RFC 120 1263209206 0 0 0 0 14 VCL_call c fetch pass 14 Length c 65 14 VCL_call c deliver deliver 14 TxProtocol c HTTP/1.1 14 TxStatus c 302 14 TxResponse c Found 14 TxHeader c Server: Apache 14 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 14 TxHeader c Expires: 0 14 TxHeader c Cache-Control: no-cache 14 TxHeader c Pragma: no-cache 14 TxHeader c Content-Language: ro 14 TxHeader c Location: http://tv.acasa.ro/tv/index 14 TxHeader c Content-Type: text/html; charset=UTF-8 14 TxHeader c Content-Length: 65 14 TxHeader c Date: Mon, 11 Jan 2010 11:26:46 GMT 14 TxHeader c X-Varnish: 366329621 14 TxHeader c Age: 0 14 TxHeader c Connection: keep-alive 14 TxHeader c Via: varnish 14 TxHeader c X-Cache: MISS 14 ReqEnd c 366329621 1263209203.877194881 1263209206.692914009 2.020351887 2.815677166 0.000041962 125 SessionOpen c 67.195.115.177 49782 :80 125 ReqStart c 67.195.115.177 49782 366329649 125 RxRequest c GET 125 RxURL c /program-TVR_International/2009-08-29/Ulita-spre-Europa-7598237-r15.html 125 RxProtocol c HTTP/1.0 125 RxHeader c Host: tv.acasa.ro 125 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 125 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 125 RxHeader c Accept-Language: en-us,en;q=0.5 125 RxHeader c Accept-Encoding: gzip,deflate 125 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 125 RxHeader c X-LLF-Mime-Type: true 125 VCL_call c recv 125 VCL_acl c NO_MATCH nocache 125 VCL_return c lookup 125 VCL_call c hash hash 125 VCL_call c miss fetch 125 Backend c 126 default default 125 ObjProtocol c HTTP/1.1 125 ObjStatus c 302 125 ObjResponse c Found 125 ObjHeader c Date: Mon, 11 Jan 2010 11:26:44 GMT 125 ObjHeader c Server: Apache 125 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 125 ObjHeader c Expires: 0 125 ObjHeader c Cache-Control: no-cache 125 ObjHeader c Pragma: no-cache 125 ObjHeader c Content-Language: ro 125 ObjHeader c Location: http://tv.acasa.ro/tv/index 125 ObjHeader c Content-Type: text/html; charset=UTF-8 125 TTL c 366329649 RFC 120 1263209206 0 0 0 0 125 VCL_call c fetch pass 125 Length c 65 125 VCL_call c deliver deliver 125 TxProtocol c HTTP/1.1 125 TxStatus c 302 125 TxResponse c Found 125 TxHeader c Server: Apache 125 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 125 TxHeader c Expires: 0 125 TxHeader c Cache-Control: no-cache 125 TxHeader c Pragma: no-cache 125 TxHeader c Content-Language: ro 125 TxHeader c Location: http://tv.acasa.ro/tv/index 125 TxHeader c Content-Type: text/html; charset=UTF-8 125 TxHeader c Content-Length: 65 125 TxHeader c Date: Mon, 11 Jan 2010 11:26:46 GMT 125 TxHeader c X-Varnish: 366329649 125 TxHeader c Age: 0 125 TxHeader c Connection: close 125 TxHeader c Via: varnish 125 TxHeader c X-Cache: MISS 125 ReqEnd c 366329649 1263209204.934860945 1263209206.741312027 0.000026941 1.806404114 0.000046968 41 SessionOpen c 62.217.247.246 23857 :80 41 ReqStart c 62.217.247.246 23857 366330105 41 RxRequest c GET 41 RxURL c / 41 RxProtocol c HTTP/1.1 41 RxHeader c Accept: text/html, image/vnd.wap.wbmp, image/png, image/jpeg, image/gif, image/bmp, application/vnd.wap.xhtml+xml, application/xhtml+xml, application/vnd.wap.multipart.mixed, multipart/mixed, text/vnd.wap.wml, application/vnd.oma.dd+xml, text/vnd.sun.j2me 41 RxHeader c Accept-Language: ro 41 RxHeader c Accept-Charset: utf-8;q=1.0,iso-8859-1;q=0.6 41 RxHeader c x-wap-profile: "http://wap.samsungmobile.com/uaprof/U800UAProf3G.xml" 41 RxHeader c User-Agent: SAMSUNG-SGH-U800/1.0 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 41 RxHeader c X-Forwarded-For: 10.82.10.57 41 RxHeader c X-Nokia-RemoteSocket: 10.82.10.57:18560 41 RxHeader c X-Nokia-LocalSocket: 172.26.12.13:8799 41 RxHeader c Accept-Encoding: deflate,gzip,identity,*;q=0 41 RxHeader c Cookie2: $Version=1 41 RxHeader c Cookie: __utmz=240209555.1262959155.1.1.utmccn=(referral)|utmcsr=tv.acasa.ro|utmcct=/tv/mobile|utmcmd=referral; 41 RxHeader c X-Nokia-Gateway-Id: NBG/2.1/1 41 RxHeader c X-Nokia-MaxDownlinkBitrate: 0 41 RxHeader c X-Nokia-MaxUplinkBitrate: 0 41 RxHeader c Via: HTTP/1.1 proxy1-b[AC174795] (Traffic-Server/5.2.2-59208 [uScM]) 41 RxHeader c Host: tv.acasa.ro 41 VCL_call c recv 41 VCL_acl c NO_MATCH nocache 41 VCL_return c pass 41 VCL_call c pass pass 41 Backend c 51 default default 41 ObjProtocol c HTTP/1.1 41 ObjStatus c 302 41 ObjResponse c Found 41 ObjHeader c Date: Mon, 11 Jan 2010 11:26:54 GMT 41 ObjHeader c Server: Apache 41 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 ObjHeader c Expires: 0 41 ObjHeader c Cache-Control: no-cache 41 ObjHeader c Pragma: no-cache 41 ObjHeader c Content-Language: ro 41 ObjHeader c Location: http://tv.acasa.ro/tv/mobile 41 ObjHeader c Content-Type: text/html; charset=UTF-8 41 TTL c 366330105 RFC 120 1263209214 0 0 0 0 41 VCL_call c fetch pass 41 Length c 66 41 VCL_call c deliver deliver 41 TxProtocol c HTTP/1.1 41 TxStatus c 302 41 TxResponse c Found 41 TxHeader c Server: Apache 41 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 41 TxHeader c Expires: 0 41 TxHeader c Cache-Control: no-cache 41 TxHeader c Pragma: no-cache 41 TxHeader c Content-Language: ro 41 TxHeader c Location: http://tv.acasa.ro/tv/mobile 41 TxHeader c Content-Type: text/html; charset=UTF-8 41 TxHeader c Content-Length: 66 41 TxHeader c Date: Mon, 11 Jan 2010 11:26:54 GMT 41 TxHeader c X-Varnish: 366330105 41 TxHeader c Age: 0 41 TxHeader c Connection: keep-alive 41 TxHeader c Via: varnish 41 TxHeader c X-Cache: MISS 41 ReqEnd c 366330105 1263209214.506439924 1263209214.635556936 0.000056982 0.129065037 0.000051975 19 SessionOpen c 66.249.65.57 43582 :80 19 ReqStart c 66.249.65.57 43582 366330558 19 RxRequest c GET 19 RxURL c /program-TCM/2008-09-04/Cimarron-4422004-r54.html 19 RxProtocol c HTTP/1.1 19 RxHeader c Host: tv.acasa.ro 19 RxHeader c Connection: Keep-alive 19 RxHeader c Accept: text/html,*/*;q=0.9 19 RxHeader c From: googlebot(at)googlebot.com 19 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 19 RxHeader c Accept-Encoding: gzip,deflate 19 VCL_call c recv 19 VCL_acl c NO_MATCH nocache 19 VCL_return c lookup 19 VCL_call c hash hash 19 VCL_call c miss fetch 19 Backend c 25 default default 19 ObjProtocol c HTTP/1.1 19 ObjStatus c 302 19 ObjResponse c Found 19 ObjHeader c Date: Mon, 11 Jan 2010 11:27:01 GMT 19 ObjHeader c Server: Apache 19 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 19 ObjHeader c Expires: 0 19 ObjHeader c Cache-Control: no-cache 19 ObjHeader c Pragma: no-cache 19 ObjHeader c Content-Language: ro 19 ObjHeader c Location: http://tv.acasa.ro/tv/index 19 ObjHeader c Content-Type: text/html; charset=UTF-8 19 TTL c 366330558 RFC 120 1263209221 0 0 0 0 19 VCL_call c fetch pass 19 Length c 65 19 VCL_call c deliver deliver 19 TxProtocol c HTTP/1.1 19 TxStatus c 302 19 TxResponse c Found 19 TxHeader c Server: Apache 19 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 19 TxHeader c Expires: 0 19 TxHeader c Cache-Control: no-cache 19 TxHeader c Pragma: no-cache 19 TxHeader c Content-Language: ro 19 TxHeader c Location: http://tv.acasa.ro/tv/index 19 TxHeader c Content-Type: text/html; charset=UTF-8 19 TxHeader c Content-Length: 65 19 TxHeader c Date: Mon, 11 Jan 2010 11:27:01 GMT 19 TxHeader c X-Varnish: 366330558 19 TxHeader c Age: 0 19 TxHeader c Connection: keep-alive 19 TxHeader c Via: varnish 19 TxHeader c X-Cache: MISS 19 ReqEnd c 366330558 1263209221.302800894 1263209221.493803978 0.000070810 0.190916061 0.000087023 83 SessionOpen c 62.217.247.243 7455 :80 83 ReqStart c 62.217.247.243 7455 366330605 83 RxRequest c GET 83 RxURL c /program_PRO_TV_--p7.html 83 RxProtocol c HTTP/1.1 83 RxHeader c Accept: text/html, image/vnd.wap.wbmp, image/png, image/jpeg, image/gif, image/bmp, application/vnd.wap.xhtml+xml, application/xhtml+xml, application/vnd.wap.multipart.mixed, multipart/mixed, text/vnd.wap.wml, application/vnd.oma.dd+xml, text/vnd.sun.j2me 83 RxHeader c Accept-Language: ro 83 RxHeader c Accept-Charset: utf-8;q=1.0,iso-8859-1;q=0.6 83 RxHeader c x-wap-profile: "http://wap.samsungmobile.com/uaprof/U800UAProf3G.xml" 83 RxHeader c User-Agent: SAMSUNG-SGH-U800/1.0 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 83 RxHeader c X-Forwarded-For: 10.82.10.57 83 RxHeader c X-Nokia-RemoteSocket: 10.82.10.57:18560 83 RxHeader c X-Nokia-LocalSocket: 172.26.12.13:8799 83 RxHeader c Accept-Encoding: deflate,gzip,identity,*;q=0 83 RxHeader c Cookie2: $Version=1 83 RxHeader c Cookie: __utmz=240209555.1262959155.1.1.utmccn=(referral)|utmcsr=tv.acasa.ro|utmcct=/tv/mobile|utmcmd=referral; 83 RxHeader c X-Nokia-Gateway-Id: NBG/2.1/1 83 RxHeader c X-Nokia-MaxDownlinkBitrate: 0 83 RxHeader c X-Nokia-MaxUplinkBitrate: 0 83 RxHeader c Via: HTTP/1.1 proxy1-d[AC1747A5] (Traffic-Server/5.2.2-59208 [uScM]) 83 RxHeader c Host: tv.acasa.ro 83 VCL_call c recv 83 VCL_acl c NO_MATCH nocache 83 VCL_return c pass 83 VCL_call c pass pass 83 Backend c 84 default default 83 ObjProtocol c HTTP/1.1 83 ObjStatus c 302 83 ObjResponse c Found 83 ObjHeader c Date: Mon, 11 Jan 2010 11:27:02 GMT 83 ObjHeader c Server: Apache 83 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 83 ObjHeader c Expires: 0 83 ObjHeader c Cache-Control: no-cache 83 ObjHeader c Pragma: no-cache 83 ObjHeader c Content-Language: ro 83 ObjHeader c Location: http://tv.acasa.ro/tv/mobile?action=1&id=7 83 ObjHeader c Content-Type: text/html; charset=UTF-8 83 TTL c 366330605 RFC 120 1263209222 0 0 0 0 83 VCL_call c fetch pass 83 Length c 80 83 VCL_call c deliver deliver 83 TxProtocol c HTTP/1.1 83 TxStatus c 302 83 TxResponse c Found 83 TxHeader c Server: Apache 83 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 83 TxHeader c Expires: 0 83 TxHeader c Cache-Control: no-cache 83 TxHeader c Pragma: no-cache 83 TxHeader c Content-Language: ro 83 TxHeader c Location: http://tv.acasa.ro/tv/mobile?action=1&id=7 83 TxHeader c Content-Type: text/html; charset=UTF-8 83 TxHeader c Content-Length: 80 83 TxHeader c Date: Mon, 11 Jan 2010 11:27:02 GMT 83 TxHeader c X-Varnish: 366330605 83 TxHeader c Age: 0 83 TxHeader c Connection: keep-alive 83 TxHeader c Via: varnish 83 TxHeader c X-Cache: MISS 83 ReqEnd c 366330605 1263209222.088279963 1263209222.215713978 0.000066042 0.127376080 0.000057936 17 SessionOpen c 65.55.37.202 1863 :80 17 ReqStart c 65.55.37.202 1863 366330683 17 RxRequest c GET 17 RxURL c /redirect?id=14735 17 RxProtocol c HTTP/1.1 17 RxHeader c Accept: */* 17 RxHeader c Host: dir.acasa.ro 17 RxHeader c Accept-Encoding: gzip, deflate 17 RxHeader c User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm) 17 RxHeader c Connection: Keep-Alive 17 RxHeader c Cache-Control: no-cache 17 RxHeader c Pragma: no-cache 17 VCL_call c recv 17 VCL_acl c NO_MATCH nocache 17 VCL_return c lookup 17 VCL_call c hash hash 17 VCL_call c miss fetch 17 Backend c 72 default default 17 ObjProtocol c HTTP/1.1 17 ObjStatus c 302 17 ObjResponse c Found 17 ObjHeader c Date: Mon, 11 Jan 2010 11:27:03 GMT 17 ObjHeader c Server: Apache 17 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 ObjHeader c Expires: 0 17 ObjHeader c Cache-Control: no-cache 17 ObjHeader c Pragma: no-cache 17 ObjHeader c Content-Language: ro 17 ObjHeader c Location: http://www.dentalcer.ro 17 ObjHeader c Set-Cookie: void=24oXbV4bdZVCrTzZp; domain=.acasa.ro; path=/ 17 ObjHeader c Content-Type: text/html; charset=utf-8 17 TTL c 366330683 RFC 120 1263209225 0 0 0 0 17 VCL_call c fetch pass 17 Length c 61 17 VCL_call c deliver deliver 17 TxProtocol c HTTP/1.1 17 TxStatus c 302 17 TxResponse c Found 17 TxHeader c Server: Apache 17 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 TxHeader c Expires: 0 17 TxHeader c Cache-Control: no-cache 17 TxHeader c Pragma: no-cache 17 TxHeader c Content-Language: ro 17 TxHeader c Location: http://www.dentalcer.ro 17 TxHeader c Set-Cookie: void=24oXbV4bdZVCrTzZp; domain=.acasa.ro; path=/ 17 TxHeader c Content-Type: text/html; charset=utf-8 17 TxHeader c Content-Length: 61 17 TxHeader c Date: Mon, 11 Jan 2010 11:27:05 GMT 17 TxHeader c X-Varnish: 366330683 17 TxHeader c Age: 0 17 TxHeader c Connection: keep-alive 17 TxHeader c Via: varnish 17 TxHeader c X-Cache: MISS 17 ReqEnd c 366330683 1263209223.344969988 1263209225.948694944 0.000108957 2.603682041 0.000042915 67 SessionOpen c 67.195.115.177 51510 :80 67 ReqStart c 67.195.115.177 51510 366330930 67 RxRequest c GET 67 RxURL c /program-Viasat_Explorer/2009-08-12/Pescarul-aventurier-7356389-r39.html 67 RxProtocol c HTTP/1.0 67 RxHeader c Host: tv.acasa.ro 67 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 67 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 67 RxHeader c Accept-Language: en-us,en;q=0.5 67 RxHeader c Accept-Encoding: gzip,deflate 67 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 67 RxHeader c X-LLF-Mime-Type: true 67 VCL_call c recv 67 VCL_acl c NO_MATCH nocache 67 VCL_return c lookup 67 VCL_call c hash hash 67 VCL_call c miss fetch 67 Backend c 68 default default 67 ObjProtocol c HTTP/1.1 67 ObjStatus c 302 67 ObjResponse c Found 67 ObjHeader c Date: Mon, 11 Jan 2010 11:27:07 GMT 67 ObjHeader c Server: Apache 67 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 67 ObjHeader c Expires: 0 67 ObjHeader c Cache-Control: no-cache 67 ObjHeader c Pragma: no-cache 67 ObjHeader c Content-Language: ro 67 ObjHeader c Location: http://tv.acasa.ro/tv/index 67 ObjHeader c Content-Type: text/html; charset=UTF-8 67 TTL c 366330930 RFC 120 1263209227 0 0 0 0 67 VCL_call c fetch pass 67 Length c 65 67 VCL_call c deliver deliver 67 TxProtocol c HTTP/1.1 67 TxStatus c 302 67 TxResponse c Found 67 TxHeader c Server: Apache 67 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 67 TxHeader c Expires: 0 67 TxHeader c Cache-Control: no-cache 67 TxHeader c Pragma: no-cache 67 TxHeader c Content-Language: ro 67 TxHeader c Location: http://tv.acasa.ro/tv/index 67 TxHeader c Content-Type: text/html; charset=UTF-8 67 TxHeader c Content-Length: 65 67 TxHeader c Date: Mon, 11 Jan 2010 11:27:07 GMT 67 TxHeader c X-Varnish: 366330930 67 TxHeader c Age: 0 67 TxHeader c Connection: close 67 TxHeader c Via: varnish 67 TxHeader c X-Cache: MISS 67 ReqEnd c 366330930 1263209227.664772034 1263209227.850078106 0.000052929 0.185214043 0.000092030 28 SessionOpen c 66.249.65.57 34978 :80 28 ReqStart c 66.249.65.57 34978 366331259 28 RxRequest c GET 28 RxURL c /program-Antena_1/2008-09-15/Jungla-de-neon-4502630-r17.html 28 RxProtocol c HTTP/1.1 28 RxHeader c Host: tv.acasa.ro 28 RxHeader c Connection: Keep-alive 28 RxHeader c Accept: */* 28 RxHeader c From: googlebot(at)googlebot.com 28 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 28 RxHeader c Accept-Encoding: gzip,deflate 28 VCL_call c recv 28 VCL_acl c NO_MATCH nocache 28 VCL_return c lookup 28 VCL_call c hash hash 28 VCL_call c miss fetch 28 Backend c 37 default default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 302 28 ObjResponse c Found 28 ObjHeader c Date: Mon, 11 Jan 2010 11:27:13 GMT 28 ObjHeader c Server: Apache 28 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 ObjHeader c Expires: 0 28 ObjHeader c Cache-Control: no-cache 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Content-Language: ro 28 ObjHeader c Location: http://tv.acasa.ro/tv/index 28 ObjHeader c Content-Type: text/html; charset=UTF-8 28 TTL c 366331259 RFC 120 1263209233 0 0 0 0 28 VCL_call c fetch pass 28 Length c 65 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 302 28 TxResponse c Found 28 TxHeader c Server: Apache 28 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 TxHeader c Expires: 0 28 TxHeader c Cache-Control: no-cache 28 TxHeader c Pragma: no-cache 28 TxHeader c Content-Language: ro 28 TxHeader c Location: http://tv.acasa.ro/tv/index 28 TxHeader c Content-Type: text/html; charset=UTF-8 28 TxHeader c Content-Length: 65 28 TxHeader c Date: Mon, 11 Jan 2010 11:27:13 GMT 28 TxHeader c X-Varnish: 366331259 28 TxHeader c Age: 0 28 TxHeader c Connection: keep-alive 28 TxHeader c Via: varnish 28 TxHeader c X-Cache: MISS 28 ReqEnd c 366331259 1263209233.504980087 1263209233.650780916 0.000071049 0.145746946 0.000053883 79 SessionOpen c 66.249.65.57 45897 :80 79 ReqStart c 66.249.65.57 45897 366331530 79 RxRequest c GET 79 RxURL c /program-TCM/2008-09-04/Gangsteri-4422010-r54.html 79 RxProtocol c HTTP/1.1 79 RxHeader c Host: tv.acasa.ro 79 RxHeader c Connection: Keep-alive 79 RxHeader c Accept: text/html,*/*;q=0.9 79 RxHeader c From: googlebot(at)googlebot.com 79 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 79 RxHeader c Accept-Encoding: gzip,deflate 79 VCL_call c recv 79 VCL_acl c NO_MATCH nocache 79 VCL_return c lookup 79 VCL_call c hash hash 79 VCL_call c miss fetch 79 Backend c 118 default default 79 ObjProtocol c HTTP/1.1 79 ObjStatus c 302 79 ObjResponse c Found 79 ObjHeader c Date: Mon, 11 Jan 2010 11:27:19 GMT 79 ObjHeader c Server: Apache 79 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 79 ObjHeader c Expires: 0 79 ObjHeader c Cache-Control: no-cache 79 ObjHeader c Pragma: no-cache 79 ObjHeader c Content-Language: ro 79 ObjHeader c Location: http://tv.acasa.ro/tv/index 79 ObjHeader c Content-Type: text/html; charset=UTF-8 79 TTL c 366331530 RFC 120 1263209239 0 0 0 0 79 VCL_call c fetch pass 79 Length c 65 79 VCL_call c deliver deliver 79 TxProtocol c HTTP/1.1 79 TxStatus c 302 79 TxResponse c Found 79 TxHeader c Server: Apache 79 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 79 TxHeader c Expires: 0 79 TxHeader c Cache-Control: no-cache 79 TxHeader c Pragma: no-cache 79 TxHeader c Content-Language: ro 79 TxHeader c Location: http://tv.acasa.ro/tv/index 79 TxHeader c Content-Type: text/html; charset=UTF-8 79 TxHeader c Content-Length: 65 79 TxHeader c Date: Mon, 11 Jan 2010 11:27:19 GMT 79 TxHeader c X-Varnish: 366331530 79 TxHeader c Age: 0 79 TxHeader c Connection: keep-alive 79 TxHeader c Via: varnish 79 TxHeader c X-Cache: MISS 79 ReqEnd c 366331530 1263209239.149151087 1263209239.264337063 0.000059128 0.115113020 0.000072956 52 SessionOpen c 220.181.7.59 13712 :80 52 ReqStart c 220.181.7.59 13712 366331821 52 RxRequest c GET 52 RxURL c / 52 RxProtocol c HTTP/1.1 52 RxHeader c Host: sport.acasa.ro 52 RxHeader c Connection: close 52 RxHeader c User-Agent: Baiduspider+(+http://www.baidu.com/search/spider.htm) 52 RxHeader c Accept-Language: zh-cn,zh-tw 52 RxHeader c Accept-Encoding: gzip 52 RxHeader c Accept: */* 52 VCL_call c recv 52 VCL_acl c NO_MATCH nocache 52 VCL_return c lookup 52 VCL_call c hash hash 52 Hit c 366123745 52 VCL_call c hit deliver 52 Length c 232 52 VCL_call c deliver deliver 52 TxProtocol c HTTP/1.1 52 TxStatus c 302 52 TxResponse c Found 52 TxHeader c Server: Apache 52 TxHeader c Location: http://stiri.acasa.ro/stiri/categorii/sport.html 52 TxHeader c Content-Type: text/html; charset=iso-8859-1 52 TxHeader c Content-Length: 232 52 TxHeader c Date: Mon, 11 Jan 2010 11:27:29 GMT 52 TxHeader c X-Varnish: 366331821 366123745 52 TxHeader c Age: 3809 52 TxHeader c Connection: close 52 TxHeader c Via: varnish 52 TxHeader c X-Cache: HIT 52 TxHeader c X-Cache-Hits: 4 52 ReqEnd c 366331821 1263209249.534909964 1263209249.535033941 0.001019001 0.000069141 0.000054836 81 SessionOpen c 62.217.247.245 2118 :80 81 ReqStart c 62.217.247.245 2118 366331682 81 RxRequest c GET 81 RxURL c /program-PRO_TV/2010-01-11/V-n-toare-fatal--8825970-r7.html 81 RxProtocol c HTTP/1.1 81 RxHeader c Accept: text/html, image/vnd.wap.wbmp, image/png, image/jpeg, image/gif, image/bmp, application/vnd.wap.xhtml+xml, application/xhtml+xml, application/vnd.wap.multipart.mixed, multipart/mixed, text/vnd.wap.wml, application/vnd.oma.dd+xml, text/vnd.sun.j2me 81 RxHeader c Accept-Language: ro 81 RxHeader c Accept-Charset: utf-8;q=1.0,iso-8859-1;q=0.6 81 RxHeader c x-wap-profile: "http://wap.samsungmobile.com/uaprof/U800UAProf3G.xml" 81 RxHeader c User-Agent: SAMSUNG-SGH-U800/1.0 SHP/VPP/R5 NetFront/3.4 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 81 RxHeader c X-Forwarded-For: 10.82.10.57 81 RxHeader c X-Nokia-RemoteSocket: 10.82.10.57:18560 81 RxHeader c X-Nokia-LocalSocket: 172.26.12.13:8799 81 RxHeader c Accept-Encoding: deflate,gzip,identity,*;q=0 81 RxHeader c Cookie2: $Version=1 81 RxHeader c Cookie: __utmz=240209555.1262959155.1.1.utmccn=(referral)|utmcsr=tv.acasa.ro|utmcct=/tv/mobile|utmcmd=referral; 81 RxHeader c X-Nokia-MaxDownlinkBitrate: 0 81 RxHeader c X-Nokia-MaxUplinkBitrate: 0 81 RxHeader c Via: HTTP/1.1 proxy1-a[AC17478D] (Traffic-Server/5.2.2-59208 [uScM]) 81 RxHeader c Host: tv.acasa.ro 81 VCL_call c recv 81 VCL_acl c NO_MATCH nocache 81 VCL_return c pass 81 VCL_call c pass pass 81 Backend c 82 default default 81 ObjProtocol c HTTP/1.1 81 ObjStatus c 302 81 ObjResponse c Found 81 ObjHeader c Date: Mon, 11 Jan 2010 11:27:23 GMT 81 ObjHeader c Server: Apache 81 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 ObjHeader c Expires: 0 81 ObjHeader c Cache-Control: no-cache 81 ObjHeader c Pragma: no-cache 81 ObjHeader c Content-Language: ro 81 ObjHeader c Location: http://tv.acasa.ro/tv/mobile?action=2&fid=8825970 81 ObjHeader c Content-Type: text/html; charset=UTF-8 81 TTL c 366331682 RFC 120 1263209249 0 0 0 0 81 VCL_call c fetch pass 81 Length c 87 81 VCL_call c deliver deliver 81 TxProtocol c HTTP/1.1 81 TxStatus c 302 81 TxResponse c Found 81 TxHeader c Server: Apache 81 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 TxHeader c Expires: 0 81 TxHeader c Cache-Control: no-cache 81 TxHeader c Pragma: no-cache 81 TxHeader c Content-Language: ro 81 TxHeader c Location: http://tv.acasa.ro/tv/mobile?action=2&fid=8825970 81 TxHeader c Content-Type: text/html; charset=UTF-8 81 TxHeader c Content-Length: 87 81 TxHeader c Date: Mon, 11 Jan 2010 11:27:29 GMT 81 TxHeader c X-Varnish: 366331682 81 TxHeader c Age: 0 81 TxHeader c Connection: keep-alive 81 TxHeader c Via: varnish 81 TxHeader c X-Cache: MISS 81 ReqEnd c 366331682 1263209243.303893089 1263209249.594233990 0.000076056 6.290277958 0.000062943 20 SessionOpen c 67.195.115.177 52961 :80 20 ReqStart c 67.195.115.177 52961 366331803 20 RxRequest c GET 20 RxURL c /program-Euforia_Lifestyle_TV/2009-11-30/Jack-8431556-r63.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 39 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:27:27 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366331803 RFC 120 1263209249 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:27:29 GMT 20 TxHeader c X-Varnish: 366331803 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366331803 1263209247.581001997 1263209249.640810966 0.000022888 2.059775114 0.000033855 54 SessionOpen c 66.249.65.57 61328 :80 54 ReqStart c 66.249.65.57 61328 366332452 54 RxRequest c GET 54 RxURL c /program-TCM/2008-09-09/Campionul-4431777-r54.html 54 RxProtocol c HTTP/1.1 54 RxHeader c Host: tv.acasa.ro 54 RxHeader c Connection: Keep-alive 54 RxHeader c Accept: text/html,*/*;q=0.9 54 RxHeader c From: googlebot(at)googlebot.com 54 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 54 RxHeader c Accept-Encoding: gzip,deflate 54 VCL_call c recv 54 VCL_acl c NO_MATCH nocache 54 VCL_return c lookup 54 VCL_call c hash hash 54 VCL_call c miss fetch 54 Backend c 58 default default 54 ObjProtocol c HTTP/1.1 54 ObjStatus c 302 54 ObjResponse c Found 54 ObjHeader c Date: Mon, 11 Jan 2010 11:27:40 GMT 54 ObjHeader c Server: Apache 54 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 54 ObjHeader c Expires: 0 54 ObjHeader c Cache-Control: no-cache 54 ObjHeader c Pragma: no-cache 54 ObjHeader c Content-Language: ro 54 ObjHeader c Location: http://tv.acasa.ro/tv/index 54 ObjHeader c Content-Type: text/html; charset=UTF-8 54 TTL c 366332452 RFC 120 1263209260 0 0 0 0 54 VCL_call c fetch pass 54 Length c 65 54 VCL_call c deliver deliver 54 TxProtocol c HTTP/1.1 54 TxStatus c 302 54 TxResponse c Found 54 TxHeader c Server: Apache 54 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 54 TxHeader c Expires: 0 54 TxHeader c Cache-Control: no-cache 54 TxHeader c Pragma: no-cache 54 TxHeader c Content-Language: ro 54 TxHeader c Location: http://tv.acasa.ro/tv/index 54 TxHeader c Content-Type: text/html; charset=UTF-8 54 TxHeader c Content-Length: 65 54 TxHeader c Date: Mon, 11 Jan 2010 11:27:40 GMT 54 TxHeader c X-Varnish: 366332452 54 TxHeader c Age: 0 54 TxHeader c Connection: keep-alive 54 TxHeader c Via: varnish 54 TxHeader c X-Cache: MISS 54 ReqEnd c 366332452 1263209260.644644022 1263209260.764405966 0.000107050 0.119684935 0.000077009 79 SessionOpen c 67.195.115.177 53891 :80 79 ReqStart c 67.195.115.177 53891 366332469 79 RxRequest c GET 79 RxURL c /program-Prima_TV/2008-07-04/Dragoste-si-putere-4001136.html 79 RxProtocol c HTTP/1.0 79 RxHeader c Host: tv.acasa.ro 79 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 79 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 79 RxHeader c Accept-Language: en-us,en;q=0.5 79 RxHeader c Accept-Encoding: gzip,deflate 79 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 79 RxHeader c X-LLF-Mime-Type: true 79 VCL_call c recv 79 VCL_acl c NO_MATCH nocache 79 VCL_return c lookup 79 VCL_call c hash hash 79 VCL_call c miss fetch 79 Backend c 85 default default 79 ObjProtocol c HTTP/1.1 79 ObjStatus c 302 79 ObjResponse c Found 79 ObjHeader c Date: Mon, 11 Jan 2010 11:27:40 GMT 79 ObjHeader c Server: Apache 79 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 79 ObjHeader c Expires: 0 79 ObjHeader c Cache-Control: no-cache 79 ObjHeader c Pragma: no-cache 79 ObjHeader c Content-Language: ro 79 ObjHeader c Location: http://tv.acasa.ro/tv/index 79 ObjHeader c Content-Type: text/html; charset=UTF-8 79 TTL c 366332469 RFC 120 1263209260 0 0 0 0 79 VCL_call c fetch pass 79 Length c 65 79 VCL_call c deliver deliver 79 TxProtocol c HTTP/1.1 79 TxStatus c 302 79 TxResponse c Found 79 TxHeader c Server: Apache 79 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 79 TxHeader c Expires: 0 79 TxHeader c Cache-Control: no-cache 79 TxHeader c Pragma: no-cache 79 TxHeader c Content-Language: ro 79 TxHeader c Location: http://tv.acasa.ro/tv/index 79 TxHeader c Content-Type: text/html; charset=UTF-8 79 TxHeader c Content-Length: 65 79 TxHeader c Date: Mon, 11 Jan 2010 11:27:40 GMT 79 TxHeader c X-Varnish: 366332469 79 TxHeader c Age: 0 79 TxHeader c Connection: close 79 TxHeader c Via: varnish 79 TxHeader c X-Cache: MISS 79 ReqEnd c 366332469 1263209260.796437979 1263209260.990856886 0.000087976 0.194365025 0.000053883 87 SessionOpen c 95.108.156.251 65440 :80 87 ReqStart c 95.108.156.251 65440 366332516 87 RxRequest c GET 87 RxURL c /program-Travel_Channel/2010-01-13/X-Quest-8721207-r86.html 87 RxProtocol c HTTP/1.1 87 RxHeader c Host: tv.acasa.ro 87 RxHeader c Connection: Keep-Alive 87 RxHeader c Accept: */* 87 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 87 RxHeader c Accept-Encoding: gzip,deflate 87 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 87 RxHeader c From: webadmin at yandex.ru 87 VCL_call c recv 87 VCL_acl c NO_MATCH nocache 87 VCL_return c lookup 87 VCL_call c hash hash 87 VCL_call c miss fetch 87 Backend c 93 default default 87 ObjProtocol c HTTP/1.1 87 ObjStatus c 302 87 ObjResponse c Found 87 ObjHeader c Date: Mon, 11 Jan 2010 11:27:41 GMT 87 ObjHeader c Server: Apache 87 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 87 ObjHeader c Expires: 0 87 ObjHeader c Cache-Control: no-cache 87 ObjHeader c Pragma: no-cache 87 ObjHeader c Content-Language: ro 87 ObjHeader c Location: http://tv.acasa.ro/tv/index 87 ObjHeader c Content-Type: text/html; charset=UTF-8 87 TTL c 366332516 RFC 120 1263209262 0 0 0 0 87 VCL_call c fetch pass 87 Length c 65 87 VCL_call c deliver deliver 87 TxProtocol c HTTP/1.1 87 TxStatus c 302 87 TxResponse c Found 87 TxHeader c Server: Apache 87 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 87 TxHeader c Expires: 0 87 TxHeader c Cache-Control: no-cache 87 TxHeader c Pragma: no-cache 87 TxHeader c Content-Language: ro 87 TxHeader c Location: http://tv.acasa.ro/tv/index 87 TxHeader c Content-Type: text/html; charset=UTF-8 87 TxHeader c Content-Length: 65 87 TxHeader c Date: Mon, 11 Jan 2010 11:27:42 GMT 87 TxHeader c X-Varnish: 366332516 87 TxHeader c Age: 0 87 TxHeader c Connection: keep-alive 87 TxHeader c Via: varnish 87 TxHeader c X-Cache: MISS 87 ReqEnd c 366332516 1263209261.262634993 1263209262.075874090 0.000104904 0.813154936 0.000084162 137 SessionOpen c 67.195.115.177 54130 :80 137 ReqStart c 67.195.115.177 54130 366332678 137 RxRequest c GET 137 RxURL c /program-B1/2010-01-04/Ilustrate-cu-flori-de-camp-8759375.html 137 RxProtocol c HTTP/1.0 137 RxHeader c Host: tv.acasa.ro 137 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 137 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 137 RxHeader c Accept-Language: en-us,en;q=0.5 137 RxHeader c Accept-Encoding: gzip,deflate 137 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 137 RxHeader c X-LLF-Mime-Type: true 137 VCL_call c recv 137 VCL_acl c NO_MATCH nocache 137 VCL_return c lookup 137 VCL_call c hash hash 137 VCL_call c miss fetch 137 Backend c 139 default default 137 ObjProtocol c HTTP/1.1 137 ObjStatus c 302 137 ObjResponse c Found 137 ObjHeader c Date: Mon, 11 Jan 2010 11:27:43 GMT 137 ObjHeader c Server: Apache 137 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 ObjHeader c Expires: 0 137 ObjHeader c Cache-Control: no-cache 137 ObjHeader c Pragma: no-cache 137 ObjHeader c Content-Language: ro 137 ObjHeader c Location: http://tv.acasa.ro/tv/index 137 ObjHeader c Content-Type: text/html; charset=UTF-8 137 TTL c 366332678 RFC 120 1263209264 0 0 0 0 137 VCL_call c fetch pass 137 Length c 65 137 VCL_call c deliver deliver 137 TxProtocol c HTTP/1.1 137 TxStatus c 302 137 TxResponse c Found 137 TxHeader c Server: Apache 137 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 TxHeader c Expires: 0 137 TxHeader c Cache-Control: no-cache 137 TxHeader c Pragma: no-cache 137 TxHeader c Content-Language: ro 137 TxHeader c Location: http://tv.acasa.ro/tv/index 137 TxHeader c Content-Type: text/html; charset=UTF-8 137 TxHeader c Content-Length: 65 137 TxHeader c Date: Mon, 11 Jan 2010 11:27:44 GMT 137 TxHeader c X-Varnish: 366332678 137 TxHeader c Age: 0 137 TxHeader c Connection: close 137 TxHeader c Via: varnish 137 TxHeader c X-Cache: MISS 137 ReqEnd c 366332678 1263209263.910923004 1263209264.181679010 0.000088930 0.270688057 0.000067949 59 SessionOpen c 67.195.115.177 54178 :80 59 ReqStart c 67.195.115.177 54178 366332710 59 RxRequest c GET 59 RxURL c /program-PRO_TV/2010-01-01/Masca-8701451.html 59 RxProtocol c HTTP/1.0 59 RxHeader c Host: tv.acasa.ro 59 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 59 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 59 RxHeader c Accept-Language: en-us,en;q=0.5 59 RxHeader c Accept-Encoding: gzip,deflate 59 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 59 RxHeader c X-LLF-Mime-Type: true 59 VCL_call c recv 59 VCL_acl c NO_MATCH nocache 59 VCL_return c lookup 59 VCL_call c hash hash 59 VCL_call c miss fetch 59 Backend c 68 default default 59 ObjProtocol c HTTP/1.1 59 ObjStatus c 302 59 ObjResponse c Found 59 ObjHeader c Date: Mon, 11 Jan 2010 11:27:44 GMT 59 ObjHeader c Server: Apache 59 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 59 ObjHeader c Expires: 0 59 ObjHeader c Cache-Control: no-cache 59 ObjHeader c Pragma: no-cache 59 ObjHeader c Content-Language: ro 59 ObjHeader c Location: http://tv.acasa.ro/tv/index 59 ObjHeader c Content-Type: text/html; charset=UTF-8 59 TTL c 366332710 RFC 120 1263209264 0 0 0 0 59 VCL_call c fetch pass 59 Length c 65 59 VCL_call c deliver deliver 59 TxProtocol c HTTP/1.1 59 TxStatus c 302 59 TxResponse c Found 59 TxHeader c Server: Apache 59 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 59 TxHeader c Expires: 0 59 TxHeader c Cache-Control: no-cache 59 TxHeader c Pragma: no-cache 59 TxHeader c Content-Language: ro 59 TxHeader c Location: http://tv.acasa.ro/tv/index 59 TxHeader c Content-Type: text/html; charset=UTF-8 59 TxHeader c Content-Length: 65 59 TxHeader c Date: Mon, 11 Jan 2010 11:27:44 GMT 59 TxHeader c X-Varnish: 366332710 59 TxHeader c Age: 0 59 TxHeader c Connection: close 59 TxHeader c Via: varnish 59 TxHeader c X-Cache: MISS 59 ReqEnd c 366332710 1263209264.624224901 1263209264.776858091 0.001435995 0.152585983 0.000047207 35 SessionOpen c 67.195.111.158 51692 :80 35 ReqStart c 67.195.111.158 51692 366332729 35 RxRequest c GET 35 RxURL c /redirect?id=16119 35 RxProtocol c HTTP/1.0 35 RxHeader c Host: dir.acasa.ro 35 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 35 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 35 RxHeader c Accept-Language: en-us,en;q=0.5 35 RxHeader c Accept-Encoding: gzip,deflate 35 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 35 RxHeader c X-LLF-Mime-Type: true 35 VCL_call c recv 35 VCL_acl c NO_MATCH nocache 35 VCL_return c lookup 35 VCL_call c hash hash 35 VCL_call c miss fetch 35 Backend c 46 default default 35 ObjProtocol c HTTP/1.1 35 ObjStatus c 302 35 ObjResponse c Found 35 ObjHeader c Date: Mon, 11 Jan 2010 11:27:44 GMT 35 ObjHeader c Server: Apache 35 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 35 ObjHeader c Expires: 0 35 ObjHeader c Cache-Control: no-cache 35 ObjHeader c Pragma: no-cache 35 ObjHeader c Content-Language: ro 35 ObjHeader c Location: http://www.masterfifa.ro 35 ObjHeader c Set-Cookie: void=1pTDYg4ltsq8us0is; domain=.acasa.ro; path=/ 35 ObjHeader c Content-Type: text/html; charset=utf-8 35 TTL c 366332729 RFC 120 1263209265 0 0 0 0 35 VCL_call c fetch pass 35 Length c 62 35 VCL_call c deliver deliver 35 TxProtocol c HTTP/1.1 35 TxStatus c 302 35 TxResponse c Found 35 TxHeader c Server: Apache 35 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 35 TxHeader c Expires: 0 35 TxHeader c Cache-Control: no-cache 35 TxHeader c Pragma: no-cache 35 TxHeader c Content-Language: ro 35 TxHeader c Location: http://www.masterfifa.ro 35 TxHeader c Set-Cookie: void=1pTDYg4ltsq8us0is; domain=.acasa.ro; path=/ 35 TxHeader c Content-Type: text/html; charset=utf-8 35 TxHeader c Content-Length: 62 35 TxHeader c Date: Mon, 11 Jan 2010 11:27:45 GMT 35 TxHeader c X-Varnish: 366332729 35 TxHeader c Age: 0 35 TxHeader c Connection: close 35 TxHeader c Via: varnish 35 TxHeader c X-Cache: MISS 35 ReqEnd c 366332729 1263209264.887063980 1263209265.120394945 0.000056028 0.233283043 0.000047922 91 SessionOpen c 67.195.115.177 54342 :80 91 ReqStart c 67.195.115.177 54342 366332854 91 RxRequest c GET 91 RxURL c /program-TVR_1/2010-01-02/Cantecul-amintirii-amintirile-cantecului-8688982.html 91 RxProtocol c HTTP/1.0 91 RxHeader c Host: tv.acasa.ro 91 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 91 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 91 RxHeader c Accept-Language: en-us,en;q=0.5 91 RxHeader c Accept-Encoding: gzip,deflate 91 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 91 RxHeader c X-LLF-Mime-Type: true 91 VCL_call c recv 91 VCL_acl c NO_MATCH nocache 91 VCL_return c lookup 91 VCL_call c hash hash 91 VCL_call c miss fetch 91 Backend c 92 default default 91 ObjProtocol c HTTP/1.1 91 ObjStatus c 302 91 ObjResponse c Found 91 ObjHeader c Date: Mon, 11 Jan 2010 11:27:46 GMT 91 ObjHeader c Server: Apache 91 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 91 ObjHeader c Expires: 0 91 ObjHeader c Cache-Control: no-cache 91 ObjHeader c Pragma: no-cache 91 ObjHeader c Content-Language: ro 91 ObjHeader c Location: http://tv.acasa.ro/tv/index 91 ObjHeader c Content-Type: text/html; charset=UTF-8 91 TTL c 366332854 RFC 120 1263209267 0 0 0 0 91 VCL_call c fetch pass 91 Length c 65 91 VCL_call c deliver deliver 91 TxProtocol c HTTP/1.1 91 TxStatus c 302 91 TxResponse c Found 91 TxHeader c Server: Apache 91 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 91 TxHeader c Expires: 0 91 TxHeader c Cache-Control: no-cache 91 TxHeader c Pragma: no-cache 91 TxHeader c Content-Language: ro 91 TxHeader c Location: http://tv.acasa.ro/tv/index 91 TxHeader c Content-Type: text/html; charset=UTF-8 91 TxHeader c Content-Length: 65 91 TxHeader c Date: Mon, 11 Jan 2010 11:27:47 GMT 91 TxHeader c X-Varnish: 366332854 91 TxHeader c Age: 0 91 TxHeader c Connection: close 91 TxHeader c Via: varnish 91 TxHeader c X-Cache: MISS 91 ReqEnd c 366332854 1263209266.973900080 1263209267.119966030 0.000096083 0.145987034 0.000078917 53 SessionOpen c 67.195.115.177 54547 :80 53 ReqStart c 67.195.115.177 54547 366332992 53 RxRequest c GET 53 RxURL c /program-Free_X_TV/2009-12-05/Bonus-Scene-Greedy-Little-Bitch-8539155-r87.html 53 RxProtocol c HTTP/1.0 53 RxHeader c Host: tv.acasa.ro 53 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 53 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 53 RxHeader c Accept-Language: en-us,en;q=0.5 53 RxHeader c Accept-Encoding: gzip,deflate 53 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 53 RxHeader c X-LLF-Mime-Type: true 53 VCL_call c recv 53 VCL_acl c NO_MATCH nocache 53 VCL_return c lookup 53 VCL_call c hash hash 53 VCL_call c miss fetch 53 Backend c 57 default default 53 ObjProtocol c HTTP/1.1 53 ObjStatus c 302 53 ObjResponse c Found 53 ObjHeader c Date: Mon, 11 Jan 2010 11:27:50 GMT 53 ObjHeader c Server: Apache 53 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 53 ObjHeader c Expires: 0 53 ObjHeader c Cache-Control: no-cache 53 ObjHeader c Pragma: no-cache 53 ObjHeader c Content-Language: ro 53 ObjHeader c Location: http://tv.acasa.ro/tv/index 53 ObjHeader c Content-Type: text/html; charset=UTF-8 53 TTL c 366332992 RFC 120 1263209270 0 0 0 0 53 VCL_call c fetch pass 53 Length c 65 53 VCL_call c deliver deliver 53 TxProtocol c HTTP/1.1 53 TxStatus c 302 53 TxResponse c Found 53 TxHeader c Server: Apache 53 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 53 TxHeader c Expires: 0 53 TxHeader c Cache-Control: no-cache 53 TxHeader c Pragma: no-cache 53 TxHeader c Content-Language: ro 53 TxHeader c Location: http://tv.acasa.ro/tv/index 53 TxHeader c Content-Type: text/html; charset=UTF-8 53 TxHeader c Content-Length: 65 53 TxHeader c Date: Mon, 11 Jan 2010 11:27:50 GMT 53 TxHeader c X-Varnish: 366332992 53 TxHeader c Age: 0 53 TxHeader c Connection: close 53 TxHeader c Via: varnish 53 TxHeader c X-Cache: MISS 53 ReqEnd c 366332992 1263209270.123938084 1263209270.257199049 0.000035048 0.133216858 0.000044107 20 SessionOpen c 67.195.115.177 54676 :80 20 ReqStart c 67.195.115.177 54676 366333050 20 RxRequest c GET 20 RxURL c /program-TVR_1/2010-01-04/Anul-sportiv-2009-8689028.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 25 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:27:51 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366333050 RFC 120 1263209272 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:27:52 GMT 20 TxHeader c X-Varnish: 366333050 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366333050 1263209271.960763931 1263209272.077099085 0.000078917 0.116254091 0.000081062 47 SessionOpen c 207.46.199.198 38630 :80 47 ReqStart c 207.46.199.198 38630 366333055 47 RxRequest c GET 47 RxURL c /redirect?id=12229 47 RxProtocol c HTTP/1.1 47 RxHeader c Cache-Control: no-cache 47 RxHeader c Connection: Keep-Alive 47 RxHeader c Pragma: no-cache 47 RxHeader c Accept: */* 47 RxHeader c Accept-Encoding: gzip, deflate 47 RxHeader c Host: dir.acasa.ro 47 RxHeader c User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm) 47 VCL_call c recv 47 VCL_acl c NO_MATCH nocache 47 VCL_return c lookup 47 VCL_call c hash hash 47 VCL_call c miss fetch 47 Backend c 52 default default 47 ObjProtocol c HTTP/1.1 47 ObjStatus c 302 47 ObjResponse c Found 47 ObjHeader c Date: Mon, 11 Jan 2010 11:27:52 GMT 47 ObjHeader c Server: Apache 47 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 47 ObjHeader c Expires: 0 47 ObjHeader c Cache-Control: no-cache 47 ObjHeader c Pragma: no-cache 47 ObjHeader c Content-Language: ro 47 ObjHeader c Location: http://www.wasval.ro 47 ObjHeader c Set-Cookie: void=1c4vfi7lt5BD3dmDJ; domain=.acasa.ro; path=/ 47 ObjHeader c Content-Type: text/html; charset=utf-8 47 TTL c 366333055 RFC 120 1263209272 0 0 0 0 47 VCL_call c fetch pass 47 Length c 58 47 VCL_call c deliver deliver 47 TxProtocol c HTTP/1.1 47 TxStatus c 302 47 TxResponse c Found 47 TxHeader c Server: Apache 47 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 47 TxHeader c Expires: 0 47 TxHeader c Cache-Control: no-cache 47 TxHeader c Pragma: no-cache 47 TxHeader c Content-Language: ro 47 TxHeader c Location: http://www.wasval.ro 47 TxHeader c Set-Cookie: void=1c4vfi7lt5BD3dmDJ; domain=.acasa.ro; path=/ 47 TxHeader c Content-Type: text/html; charset=utf-8 47 TxHeader c Content-Length: 58 47 TxHeader c Date: Mon, 11 Jan 2010 11:27:52 GMT 47 TxHeader c X-Varnish: 366333055 47 TxHeader c Age: 0 47 TxHeader c Connection: keep-alive 47 TxHeader c Via: varnish 47 TxHeader c X-Cache: MISS 47 ReqEnd c 366333055 1263209272.566705942 1263209272.823605061 0.000104904 0.256837130 0.000061989 17 SessionOpen c 84.236.147.94 51438 :80 17 ReqStart c 84.236.147.94 51438 366333063 17 RxRequest c GET 17 RxURL c /program-Prima_TV/2009-10-12/Fermier-Caut-nevasta--7985739.html 17 RxProtocol c HTTP/1.1 17 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xa ml+xml, application/x-ms-xbap, application/x-shockwave-flash, */* 17 RxHeader c Referer: http://search.conduit.com/Results.aspx?q=related:http://www.nasul.net/2009/09/fermier-caut-nevasta-cu-luana-ibacka-la-prima-tv/& SearchSourceOrigin=10&hl=es&SelfSearch=1&ctid=CT1854633 17 RxHeader c Accept-Language: es 17 RxHeader c UA-CPU: x86 17 RxHeader c Accept-Encoding: gzip, deflate 17 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30618) 17 RxHeader c Host: tv.acasa.ro 17 RxHeader c Connection: Keep-Alive 17 RxHeader c Cookie: trafic_h=b6eeee98lce260b7f78d4bb665199a9a*1263208531*acasa.ro*1263208531*1263208531*1; trafic_v=1; __utma=240209555.1953566108.12 63208532.1263208532.1263208532.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.1263208532.1.1.utmccn=(organic) 17 VCL_call c recv 17 VCL_acl c NO_MATCH nocache 17 VCL_return c pass 17 VCL_call c pass pass 17 Backend c 21 default default 17 ObjProtocol c HTTP/1.1 17 ObjStatus c 302 17 ObjResponse c Found 17 ObjHeader c Date: Mon, 11 Jan 2010 11:27:53 GMT 17 ObjHeader c Server: Apache 17 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 ObjHeader c Expires: 0 17 ObjHeader c Cache-Control: no-cache 17 ObjHeader c Pragma: no-cache 17 ObjHeader c Content-Language: ro 17 ObjHeader c Location: http://tv.acasa.ro/tv/index 17 ObjHeader c Content-Type: text/html; charset=UTF-8 17 TTL c 366333063 RFC 120 1263209273 0 0 0 0 17 VCL_call c fetch pass 17 Length c 65 17 VCL_call c deliver deliver 17 TxProtocol c HTTP/1.1 17 TxStatus c 302 17 TxResponse c Found 17 TxHeader c Server: Apache 17 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 TxHeader c Expires: 0 17 TxHeader c Cache-Control: no-cache 17 TxHeader c Pragma: no-cache 17 TxHeader c Content-Language: ro 17 TxHeader c Location: http://tv.acasa.ro/tv/index 17 TxHeader c Content-Type: text/html; charset=UTF-8 17 TxHeader c Content-Length: 65 17 TxHeader c Date: Mon, 11 Jan 2010 11:27:53 GMT 17 TxHeader c X-Varnish: 366333063 17 TxHeader c Age: 0 17 TxHeader c Connection: keep-alive 17 TxHeader c Via: varnish 17 TxHeader c X-Cache: MISS 17 ReqEnd c 366333063 1263209273.272669077 1263209273.519500017 0.000116110 0.246744871 0.000086069 71 ReqStart c 79.115.86.172 3202 366333236 71 RxRequest c GET 71 RxURL c /post?id=-1&zi=-1&buton=Afiseaza 71 RxProtocol c HTTP/1.1 71 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, a 71 RxHeader c Referer: http://tv.acasa.ro/post?id=22&zi=-1&buton=Afiseaza 71 RxHeader c Accept-Language: en-us 71 RxHeader c UA-CPU: x86 71 RxHeader c Accept-Encoding: gzip, deflate 71 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6.3; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) 71 RxHeader c Host: tv.acasa.ro 71 RxHeader c Connection: Keep-Alive 71 RxHeader c Cookie: trafic_h=6dccbd9512a9d28lb3208d1a80d5ba61*1204279583*acasa.ro*1263071269*1263209231*33; __utma=240209555.516211857.1188851980.126 3071270.1263209231.32; __utmz=240209555.1263209231.32.19.utmccn=(organic)|utmcsr=google|utmctr=discovery|utmcmd=organi 71 VCL_call c recv 71 VCL_acl c NO_MATCH nocache 71 VCL_return c pass 71 VCL_call c pass pass 71 Backend c 59 default default 71 ObjProtocol c HTTP/1.1 71 ObjStatus c 302 71 ObjResponse c Found 71 ObjHeader c Date: Mon, 11 Jan 2010 11:27:56 GMT 71 ObjHeader c Server: Apache 71 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 71 ObjHeader c Expires: 0 71 ObjHeader c Cache-Control: no-cache 71 ObjHeader c Pragma: no-cache 71 ObjHeader c Content-Language: ro 71 ObjHeader c Location: http://tv.acasa.ro/tv/error 71 ObjHeader c Content-Type: text/html; charset=UTF-8 71 TTL c 366333236 RFC 120 1263209276 0 0 0 0 71 VCL_call c fetch pass 71 Length c 65 71 VCL_call c deliver deliver 71 TxProtocol c HTTP/1.1 71 TxStatus c 302 71 TxResponse c Found 71 TxHeader c Server: Apache 71 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 71 TxHeader c Expires: 0 71 TxHeader c Cache-Control: no-cache 71 TxHeader c Pragma: no-cache 71 TxHeader c Content-Language: ro 71 TxHeader c Location: http://tv.acasa.ro/tv/error 71 TxHeader c Content-Type: text/html; charset=UTF-8 71 TxHeader c Content-Length: 65 71 TxHeader c Date: Mon, 11 Jan 2010 11:27:56 GMT 71 TxHeader c X-Varnish: 366333236 71 TxHeader c Age: 0 71 TxHeader c Connection: keep-alive 71 TxHeader c Via: varnish 71 TxHeader c X-Cache: MISS 71 ReqEnd c 366333236 1263209276.145739079 1263209276.257719040 1.156844139 0.111920834 0.000059128 81 SessionOpen c 66.249.65.57 36971 :80 81 ReqStart c 66.249.65.57 36971 366333799 81 RxRequest c GET 81 RxURL c /program-TCM/2008-09-02/Skyjacked-4421982-r54.html 81 RxProtocol c HTTP/1.1 81 RxHeader c Host: tv.acasa.ro 81 RxHeader c Connection: Keep-alive 81 RxHeader c Accept: text/html,*/*;q=0.9 81 RxHeader c From: googlebot(at)googlebot.com 81 RxHeader c User-Agent: DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 81 RxHeader c Accept-Encoding: gzip,deflate 81 VCL_call c recv 81 VCL_acl c NO_MATCH nocache 81 VCL_return c lookup 81 VCL_call c hash hash 81 VCL_call c miss fetch 81 Backend c 82 default default 81 ObjProtocol c HTTP/1.1 81 ObjStatus c 302 81 ObjResponse c Found 81 ObjHeader c Date: Mon, 11 Jan 2010 11:28:05 GMT 81 ObjHeader c Server: Apache 81 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 ObjHeader c Expires: 0 81 ObjHeader c Cache-Control: no-cache 81 ObjHeader c Pragma: no-cache 81 ObjHeader c Content-Language: ro 81 ObjHeader c Location: http://tv.acasa.ro/tv/index 81 ObjHeader c Content-Type: text/html; charset=UTF-8 81 TTL c 366333799 RFC 120 1263209285 0 0 0 0 81 VCL_call c fetch pass 81 Length c 65 81 VCL_call c deliver deliver 81 TxProtocol c HTTP/1.1 81 TxStatus c 302 81 TxResponse c Found 81 TxHeader c Server: Apache 81 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 81 TxHeader c Expires: 0 81 TxHeader c Cache-Control: no-cache 81 TxHeader c Pragma: no-cache 81 TxHeader c Content-Language: ro 81 TxHeader c Location: http://tv.acasa.ro/tv/index 81 TxHeader c Content-Type: text/html; charset=UTF-8 81 TxHeader c Content-Length: 65 81 TxHeader c Date: Mon, 11 Jan 2010 11:28:05 GMT 81 TxHeader c X-Varnish: 366333799 81 TxHeader c Age: 0 81 TxHeader c Connection: keep-alive 81 TxHeader c Via: varnish 81 TxHeader c X-Cache: MISS 81 ReqEnd c 366333799 1263209285.119534016 1263209285.428792000 0.000366926 0.309211969 0.000046015 112 SessionOpen c 67.195.115.177 55972 :80 112 ReqStart c 67.195.115.177 55972 366333944 112 RxRequest c GET 112 RxURL c /program-Antena_International/2010-01-11/Sport-8924760-r90.html 112 RxProtocol c HTTP/1.0 112 RxHeader c Host: tv.acasa.ro 112 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 112 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 112 RxHeader c Accept-Language: en-us,en;q=0.5 112 RxHeader c Accept-Encoding: gzip,deflate 112 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 112 VCL_call c recv 112 VCL_acl c NO_MATCH nocache 112 VCL_return c lookup 112 VCL_call c hash hash 112 VCL_call c miss fetch 112 Backend c 144 default default 112 ObjProtocol c HTTP/1.1 112 ObjStatus c 302 112 ObjResponse c Found 112 ObjHeader c Date: Mon, 11 Jan 2010 11:28:08 GMT 112 ObjHeader c Server: Apache 112 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 112 ObjHeader c Expires: 0 112 ObjHeader c Cache-Control: no-cache 112 ObjHeader c Pragma: no-cache 112 ObjHeader c Content-Language: ro 112 ObjHeader c Location: http://tv.acasa.ro/tv/index 112 ObjHeader c Content-Type: text/html; charset=UTF-8 112 TTL c 366333944 RFC 120 1263209289 0 0 0 0 112 VCL_call c fetch pass 112 Length c 65 112 VCL_call c deliver deliver 112 TxProtocol c HTTP/1.1 112 TxStatus c 302 112 TxResponse c Found 112 TxHeader c Server: Apache 112 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 112 TxHeader c Expires: 0 112 TxHeader c Cache-Control: no-cache 112 TxHeader c Pragma: no-cache 112 TxHeader c Content-Language: ro 112 TxHeader c Location: http://tv.acasa.ro/tv/index 112 TxHeader c Content-Type: text/html; charset=UTF-8 112 TxHeader c Content-Length: 65 112 TxHeader c Date: Mon, 11 Jan 2010 11:28:09 GMT 112 TxHeader c X-Varnish: 366333944 112 TxHeader c Age: 0 112 TxHeader c Connection: close 112 TxHeader c Via: varnish 112 TxHeader c X-Cache: MISS 112 ReqEnd c 366333944 1263209288.329427958 1263209289.628750086 0.000058889 1.299277067 0.000045061 66 SessionOpen c 81.196.48.84 1306 :80 66 ReqStart c 81.196.48.84 1306 366334978 66 RxRequest c GET 66 RxURL c /redirect?id=4672 66 RxProtocol c HTTP/1.1 66 RxHeader c Accept: */* 66 RxHeader c Referer: http://dir.acasa.ro/Sport_si_recreere/Auto--160.html 66 RxHeader c Accept-Language: ro 66 RxHeader c Accept-Encoding: gzip, deflate 66 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) 66 RxHeader c Host: dir.acasa.ro 66 RxHeader c Connection: Keep-Alive 66 RxHeader c Cookie: POPUPCHECK=1263295685250; trafic_h=2belfe55b113e984512c7862c7e074b9*1263209288*acasa.ro*1263209288*1263209288*1; trafic_v=1; __ut ma=240209555.1056631315.1263209288.1263209288.1263209288.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.12632 66 VCL_call c recv 66 VCL_acl c NO_MATCH nocache 66 VCL_return c pass 66 VCL_call c pass pass 66 Backend c 77 default default 66 ObjProtocol c HTTP/1.1 66 ObjStatus c 302 66 ObjResponse c Found 66 ObjHeader c Date: Mon, 11 Jan 2010 11:28:24 GMT 66 ObjHeader c Server: Apache 66 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 ObjHeader c Expires: 0 66 ObjHeader c Cache-Control: no-cache 66 ObjHeader c Pragma: no-cache 66 ObjHeader c Content-Language: ro 66 ObjHeader c Location: http://dacia.gsign.biz 66 ObjHeader c Set-Cookie: void=14Np36AhJ72jDYLv; domain=.acasa.ro; path=/ 66 ObjHeader c Content-Type: text/html; charset=utf-8 66 TTL c 366334978 RFC 120 1263209306 0 0 0 0 66 VCL_call c fetch pass 66 Length c 60 66 VCL_call c deliver deliver 66 TxProtocol c HTTP/1.1 66 TxStatus c 302 66 TxResponse c Found 66 TxHeader c Server: Apache 66 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 TxHeader c Expires: 0 66 TxHeader c Cache-Control: no-cache 66 TxHeader c Pragma: no-cache 66 TxHeader c Content-Language: ro 66 TxHeader c Location: http://dacia.gsign.biz 66 TxHeader c Set-Cookie: void=14Np36AhJ72jDYLv; domain=.acasa.ro; path=/ 66 TxHeader c Content-Type: text/html; charset=utf-8 [root at web ~]# more 302 34 SessionOpen c 95.108.156.251 60140 :80 34 ReqStart c 95.108.156.251 60140 366308812 34 RxRequest c GET 34 RxURL c /program-Kiss_TV/2010-01-13/Kiss-by-night-8899983-r8.html 34 RxProtocol c HTTP/1.1 34 RxHeader c Host: tv.acasa.ro 34 RxHeader c Connection: Keep-Alive 34 RxHeader c Accept: */* 34 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 34 RxHeader c Accept-Encoding: gzip,deflate 34 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 34 RxHeader c From: webadmin at yandex.ru 34 VCL_call c recv 34 VCL_acl c NO_MATCH nocache 34 VCL_return c lookup 34 VCL_call c hash hash 34 VCL_call c miss fetch 34 Backend c 49 default default 34 ObjProtocol c HTTP/1.1 34 ObjStatus c 302 34 ObjResponse c Found 34 ObjHeader c Date: Mon, 11 Jan 2010 11:21:12 GMT 34 ObjHeader c Server: Apache 34 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 34 ObjHeader c Expires: 0 34 ObjHeader c Cache-Control: no-cache 34 ObjHeader c Pragma: no-cache 34 ObjHeader c Content-Language: ro 34 ObjHeader c Location: http://tv.acasa.ro/tv/index 34 ObjHeader c Content-Type: text/html; charset=UTF-8 34 TTL c 366308812 RFC 120 1263208873 0 0 0 0 34 VCL_call c fetch pass 34 Length c 65 34 VCL_call c deliver deliver 34 TxProtocol c HTTP/1.1 34 TxStatus c 302 34 TxResponse c Found 34 TxHeader c Server: Apache 34 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 34 TxHeader c Expires: 0 34 TxHeader c Cache-Control: no-cache 34 TxHeader c Pragma: no-cache 34 TxHeader c Content-Language: ro 34 TxHeader c Location: http://tv.acasa.ro/tv/index 34 TxHeader c Content-Type: text/html; charset=UTF-8 34 TxHeader c Content-Length: 65 34 TxHeader c Date: Mon, 11 Jan 2010 11:21:13 GMT 34 TxHeader c X-Varnish: 366308812 34 TxHeader c Age: 0 34 TxHeader c Connection: keep-alive 34 TxHeader c Via: varnish 34 TxHeader c X-Cache: MISS 34 ReqEnd c 366308812 1263208872.422010899 1263208873.871994972 0.000029802 1.449938059 0.000046015 46 SessionOpen c 79.119.170.144 3694 :80 46 ReqStart c 79.119.170.144 3694 366308774 46 RxRequest c GET 46 RxURL c /andromeda-2000 46 RxProtocol c HTTP/1.1 46 RxHeader c Host: filme.acasa.ro 46 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ro; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 46 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 46 RxHeader c Accept-Language: ro-ro,ro;q=0.8,en-us;q=0.6,en-gb;q=0.4,en;q=0.2 46 RxHeader c Accept-Encoding: gzip,deflate 46 RxHeader c Accept-Charset: UTF-8,* 46 RxHeader c Keep-Alive: 300 46 RxHeader c Connection: keep-alive 46 RxHeader c Referer: http://filme.acasa.ro/gen/Fantastic 46 RxHeader c Cookie: trafic_h=445022561608l7fbc3890036e7839041*1258729244*acasa.ro*1262813723*1263205515*4; __utma=240209555.701818405.1258729247.1262 813723.1263205515.4; __utmz=240209555.1263208371.4.5.utmccn=(organic)|utmcsr=google|utmctr=listare+filme|utmcmd=organi 46 VCL_call c recv 46 VCL_acl c NO_MATCH nocache 46 VCL_return c pass 46 VCL_call c pass pass 46 Backend c 121 default default 46 ObjProtocol c HTTP/1.1 46 ObjStatus c 302 46 ObjResponse c Found 46 ObjHeader c Date: Mon, 11 Jan 2010 11:21:11 GMT 46 ObjHeader c Server: Apache 46 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 46 ObjHeader c Expires: 0 46 ObjHeader c Cache-Control: no-cache 46 ObjHeader c Pragma: no-cache 46 ObjHeader c Content-Language: ro 46 ObjHeader c Location: http://filme.acasa.ro/ 46 ObjHeader c Content-Type: text/html; charset=UTF-8 46 TTL c 366308774 RFC 120 1263208874 0 0 0 0 46 VCL_call c fetch pass 46 Length c 60 46 VCL_call c deliver deliver 46 TxProtocol c HTTP/1.1 46 TxStatus c 302 46 TxResponse c Found 46 TxHeader c Server: Apache 46 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 46 TxHeader c Expires: 0 46 TxHeader c Cache-Control: no-cache 46 TxHeader c Pragma: no-cache 46 TxHeader c Content-Language: ro 46 TxHeader c Location: http://filme.acasa.ro/ 46 TxHeader c Content-Type: text/html; charset=UTF-8 46 TxHeader c Content-Length: 60 46 TxHeader c Date: Mon, 11 Jan 2010 11:21:14 GMT 46 TxHeader c X-Varnish: 366308774 46 TxHeader c Age: 0 46 TxHeader c Connection: keep-alive 46 TxHeader c Via: varnish 46 TxHeader c X-Cache: MISS 46 ReqEnd c 366308774 1263208871.071818113 1263208874.618308067 0.000063181 3.546463966 0.000025988 76 SessionOpen c 67.195.115.177 53699 :80 76 ReqStart c 67.195.115.177 53699 366309075 76 RxRequest c GET 76 RxURL c /program-AXN/2009-01-01/Baietii-de-la-sport-5266634-r33.html 76 RxProtocol c HTTP/1.0 76 RxHeader c Host: tv.acasa.ro 76 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 76 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 76 RxHeader c Accept-Language: en-us,en;q=0.5 76 RxHeader c Accept-Encoding: gzip,deflate 76 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 76 RxHeader c X-LLF-Mime-Type: true 76 VCL_call c recv 76 VCL_acl c NO_MATCH nocache 76 VCL_return c lookup 76 VCL_call c hash hash 76 VCL_call c miss fetch 76 Backend c 77 default default 76 ObjProtocol c HTTP/1.1 76 ObjStatus c 302 76 ObjResponse c Found 76 ObjHeader c Date: Mon, 11 Jan 2010 11:21:16 GMT 76 ObjHeader c Server: Apache 76 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 76 ObjHeader c Expires: 0 76 ObjHeader c Cache-Control: no-cache 76 ObjHeader c Pragma: no-cache 76 ObjHeader c Content-Language: ro 76 ObjHeader c Location: http://tv.acasa.ro/tv/index 76 ObjHeader c Content-Type: text/html; charset=UTF-8 76 TTL c 366309075 RFC 120 1263208877 0 0 0 0 76 VCL_call c fetch pass 76 Length c 65 76 VCL_call c deliver deliver 76 TxProtocol c HTTP/1.1 76 TxStatus c 302 76 TxResponse c Found 76 TxHeader c Server: Apache 76 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 76 TxHeader c Expires: 0 76 TxHeader c Cache-Control: no-cache 76 TxHeader c Pragma: no-cache 76 TxHeader c Content-Language: ro 76 TxHeader c Location: http://tv.acasa.ro/tv/index 76 TxHeader c Content-Type: text/html; charset=UTF-8 76 TxHeader c Content-Length: 65 76 TxHeader c Date: Mon, 11 Jan 2010 11:21:17 GMT 76 TxHeader c X-Varnish: 366309075 76 TxHeader c Age: 0 76 TxHeader c Connection: close 76 TxHeader c Via: varnish 76 TxHeader c X-Cache: MISS 76 ReqEnd c 366309075 1263208876.902172089 1263208877.050297976 0.000054121 0.148049831 0.000076056 90 SessionOpen c 93.116.74.80 3572 :80 90 ReqStart c 93.116.74.80 3572 366309097 90 RxRequest c GET 90 RxURL c /redirect?id=9107 90 RxProtocol c HTTP/1.1 90 RxHeader c Accept: */* 90 RxHeader c Referer: http://dir.acasa.ro/Cumparaturi/Masini--263.html 90 RxHeader c Accept-Language: ro 90 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; MRSPUTNIK 2, 1, 0, 4 HW; GTB6.3; MRA 5.5 (build 02842); Mozil la/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.4 90 RxHeader c Accept-Encoding: gzip, deflate 90 RxHeader c Host: dir.acasa.ro 90 RxHeader c Connection: Keep-Alive 90 RxHeader c Cookie: __utmc=240209555; void=1LLj6C-5VtfDNqn00u; trafic_h=fb8l6ffc30fed067c4967b38b3ed8fac*1262791756*acasa.ro*1263038119*1263206417*3; trafic_v=1; __utma=240209555.2129152946.1262791756.1263038119.1263206417.3; __utmb=240209555; __utmz=240209555.126320 90 VCL_call c recv 90 VCL_acl c NO_MATCH nocache 90 VCL_return c pass 90 VCL_call c pass pass 90 Backend c 91 default default 90 ObjProtocol c HTTP/1.1 90 ObjStatus c 302 90 ObjResponse c Found 90 ObjHeader c Date: Mon, 11 Jan 2010 11:21:17 GMT 90 ObjHeader c Server: Apache 90 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 90 ObjHeader c Expires: 0 90 ObjHeader c Cache-Control: no-cache 90 ObjHeader c Pragma: no-cache 90 ObjHeader c Content-Language: ro 90 ObjHeader c Location: http://masini.acasa.ro/ 90 ObjHeader c Content-Type: text/html; charset=utf-8 90 TTL c 366309097 RFC 120 1263208878 0 0 0 0 90 VCL_call c fetch pass 90 Length c 61 90 VCL_call c deliver deliver 90 TxProtocol c HTTP/1.1 90 TxStatus c 302 90 TxResponse c Found 90 TxHeader c Server: Apache 90 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 90 TxHeader c Expires: 0 90 TxHeader c Cache-Control: no-cache 90 TxHeader c Pragma: no-cache 90 TxHeader c Content-Language: ro 90 TxHeader c Location: http://masini.acasa.ro/ 90 TxHeader c Content-Type: text/html; charset=utf-8 90 TxHeader c Content-Length: 61 90 TxHeader c Date: Mon, 11 Jan 2010 11:21:18 GMT 90 TxHeader c X-Varnish: 366309097 90 TxHeader c Age: 0 90 TxHeader c Connection: keep-alive 90 TxHeader c Via: varnish 90 TxHeader c X-Cache: MISS 90 ReqEnd c 366309097 1263208877.933342934 1263208878.031282902 0.000085831 0.097846031 0.000093937 23 SessionOpen c 67.195.115.177 53952 :80 23 ReqStart c 67.195.115.177 53952 366309285 23 RxRequest c GET 23 RxURL c /program-Cinemax/2010-01-06/Ultima-sansa-8732069-r42.html 23 RxProtocol c HTTP/1.0 23 RxHeader c Host: tv.acasa.ro 23 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 23 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 23 RxHeader c Accept-Language: en-us,en;q=0.5 23 RxHeader c Accept-Encoding: gzip,deflate 23 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 23 RxHeader c X-LLF-Mime-Type: true 23 VCL_call c recv 23 VCL_acl c NO_MATCH nocache 23 VCL_return c lookup 23 VCL_call c hash hash 23 VCL_call c miss fetch 23 Backend c 28 default default 23 ObjProtocol c HTTP/1.1 23 ObjStatus c 302 23 ObjResponse c Found 23 ObjHeader c Date: Mon, 11 Jan 2010 11:21:21 GMT 23 ObjHeader c Server: Apache 23 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 ObjHeader c Expires: 0 23 ObjHeader c Cache-Control: no-cache 23 ObjHeader c Pragma: no-cache 23 ObjHeader c Content-Language: ro 23 ObjHeader c Location: http://tv.acasa.ro/tv/index 23 ObjHeader c Content-Type: text/html; charset=UTF-8 23 TTL c 366309285 RFC 120 1263208882 0 0 0 0 23 VCL_call c fetch pass 23 Length c 65 23 VCL_call c deliver deliver 23 TxProtocol c HTTP/1.1 23 TxStatus c 302 23 TxResponse c Found 23 TxHeader c Server: Apache 23 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 TxHeader c Expires: 0 23 TxHeader c Cache-Control: no-cache 23 TxHeader c Pragma: no-cache 23 TxHeader c Content-Language: ro 23 TxHeader c Location: http://tv.acasa.ro/tv/index 23 TxHeader c Content-Type: text/html; charset=UTF-8 23 TxHeader c Content-Length: 65 23 TxHeader c Date: Mon, 11 Jan 2010 11:21:22 GMT 23 TxHeader c X-Varnish: 366309285 23 TxHeader c Age: 0 23 TxHeader c Connection: close 23 TxHeader c Via: varnish 23 TxHeader c X-Cache: MISS 23 ReqEnd c 366309285 1263208881.786039114 1263208882.456554890 0.000078201 0.670464993 0.000050783 17 SessionOpen c 67.195.115.177 55023 :80 17 ReqStart c 67.195.115.177 55023 366309825 17 RxRequest c GET 17 RxURL c /program-Acas_TV/2010-01-11/Vremea-de-ACASA-8834016.html 17 RxProtocol c HTTP/1.0 17 RxHeader c Host: tv.acasa.ro 17 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 17 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 17 RxHeader c Accept-Language: en-us,en;q=0.5 17 RxHeader c Accept-Encoding: gzip,deflate 17 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 17 RxHeader c X-LLF-Mime-Type: true 17 VCL_call c recv 17 VCL_acl c NO_MATCH nocache 17 VCL_return c lookup 17 VCL_call c hash hash 17 VCL_call c miss fetch 17 Backend c 20 default default 17 ObjProtocol c HTTP/1.1 17 ObjStatus c 302 17 ObjResponse c Found 17 ObjHeader c Date: Mon, 11 Jan 2010 11:21:34 GMT 17 ObjHeader c Server: Apache 17 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 ObjHeader c Expires: 0 17 ObjHeader c Cache-Control: no-cache 17 ObjHeader c Pragma: no-cache 17 ObjHeader c Content-Language: ro 17 ObjHeader c Location: http://tv.acasa.ro/tv/index 17 ObjHeader c Content-Type: text/html; charset=UTF-8 17 TTL c 366309825 RFC 120 1263208894 0 0 0 0 17 VCL_call c fetch pass 17 Length c 65 17 VCL_call c deliver deliver 17 TxProtocol c HTTP/1.1 17 TxStatus c 302 17 TxResponse c Found 17 TxHeader c Server: Apache 17 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 17 TxHeader c Expires: 0 17 TxHeader c Cache-Control: no-cache 17 TxHeader c Pragma: no-cache 17 TxHeader c Content-Language: ro 17 TxHeader c Location: http://tv.acasa.ro/tv/index 17 TxHeader c Content-Type: text/html; charset=UTF-8 17 TxHeader c Content-Length: 65 17 TxHeader c Date: Mon, 11 Jan 2010 11:21:34 GMT 17 TxHeader c X-Varnish: 366309825 17 TxHeader c Age: 0 17 TxHeader c Connection: close 17 TxHeader c Via: varnish 17 TxHeader c X-Cache: MISS 17 ReqEnd c 366309825 1263208894.818624973 1263208894.948905945 0.000052929 0.130192995 0.000087976 71 SessionOpen c 67.195.115.177 55184 :80 71 ReqStart c 67.195.115.177 55184 366309928 71 RxRequest c GET 71 RxURL c /program-MTV_Romania/2009-11-10/Alice-8237750-r26.html 71 RxProtocol c HTTP/1.0 71 RxHeader c Host: tv.acasa.ro 71 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 71 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 71 RxHeader c Accept-Language: en-us,en;q=0.5 71 RxHeader c Accept-Encoding: gzip,deflate 71 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 71 RxHeader c X-LLF-Mime-Type: true 71 VCL_call c recv 71 VCL_acl c NO_MATCH nocache 71 VCL_return c lookup 71 VCL_call c hash hash 71 VCL_call c miss fetch 71 Backend c 78 default default 71 ObjProtocol c HTTP/1.1 71 ObjStatus c 302 71 ObjResponse c Found 71 ObjHeader c Date: Mon, 11 Jan 2010 11:21:36 GMT 71 ObjHeader c Server: Apache 71 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 71 ObjHeader c Expires: 0 71 ObjHeader c Cache-Control: no-cache 71 ObjHeader c Pragma: no-cache 71 ObjHeader c Content-Language: ro 71 ObjHeader c Location: http://tv.acasa.ro/tv/index 71 ObjHeader c Content-Type: text/html; charset=UTF-8 71 TTL c 366309928 RFC 120 1263208896 0 0 0 0 71 VCL_call c fetch pass 71 Length c 65 71 VCL_call c deliver deliver 71 TxProtocol c HTTP/1.1 71 TxStatus c 302 71 TxResponse c Found 71 TxHeader c Server: Apache 71 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 71 TxHeader c Expires: 0 71 TxHeader c Cache-Control: no-cache 71 TxHeader c Pragma: no-cache 71 TxHeader c Content-Language: ro 71 TxHeader c Location: http://tv.acasa.ro/tv/index 71 TxHeader c Content-Type: text/html; charset=UTF-8 71 TxHeader c Content-Length: 65 71 TxHeader c Date: Mon, 11 Jan 2010 11:21:36 GMT 71 TxHeader c X-Varnish: 366309928 71 TxHeader c Age: 0 71 TxHeader c Connection: close 71 TxHeader c Via: varnish 71 TxHeader c X-Cache: MISS 71 ReqEnd c 366309928 1263208896.790374041 1263208896.919428110 0.000113010 0.128968954 0.000085115 88 SessionOpen c 95.108.156.251 51822 :80 88 ReqStart c 95.108.156.251 51822 366310272 88 RxRequest c GET 88 RxURL c /program-MGM/2010-01-03/Vacan-la-Vene-ia-8687313-r92.html 88 RxProtocol c HTTP/1.1 88 RxHeader c Host: tv.acasa.ro 88 RxHeader c Connection: Keep-Alive 88 RxHeader c Accept: */* 88 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 88 RxHeader c Accept-Encoding: gzip,deflate 88 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 88 RxHeader c From: webadmin at yandex.ru 88 VCL_call c recv 88 VCL_acl c NO_MATCH nocache 88 VCL_return c lookup 88 VCL_call c hash hash 88 VCL_call c miss fetch 88 Backend c 89 default default 88 ObjProtocol c HTTP/1.1 88 ObjStatus c 302 88 ObjResponse c Found 88 ObjHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 88 ObjHeader c Server: Apache 88 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 ObjHeader c Expires: 0 88 ObjHeader c Cache-Control: no-cache 88 ObjHeader c Pragma: no-cache 88 ObjHeader c Content-Language: ro 88 ObjHeader c Location: http://tv.acasa.ro/tv/index 88 ObjHeader c Content-Type: text/html; charset=UTF-8 88 TTL c 366310272 RFC 120 1263208903 0 0 0 0 88 VCL_call c fetch pass 88 Length c 65 88 VCL_call c deliver deliver 88 TxProtocol c HTTP/1.1 88 TxStatus c 302 88 TxResponse c Found 88 TxHeader c Server: Apache 88 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 TxHeader c Expires: 0 88 TxHeader c Cache-Control: no-cache 88 TxHeader c Pragma: no-cache 88 TxHeader c Content-Language: ro 88 TxHeader c Location: http://tv.acasa.ro/tv/index 88 TxHeader c Content-Type: text/html; charset=UTF-8 88 TxHeader c Content-Length: 65 88 TxHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 88 TxHeader c X-Varnish: 366310272 88 TxHeader c Age: 0 88 TxHeader c Connection: keep-alive 88 TxHeader c Via: varnish 88 TxHeader c X-Cache: MISS 88 ReqEnd c 366310272 1263208903.338821888 1263208903.459625006 0.000044823 0.120719194 0.000083923 42 SessionOpen c 194.60.106.5 13618 :80 42 ReqStart c 194.60.106.5 13618 366310326 42 RxRequest c GET 42 RxURL c /post?id=-1&zi=2&buton=Afiseaza 42 RxProtocol c HTTP/1.0 42 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, applicati 42 RxHeader c Referer: http://tv.acasa.ro/post?id=66&zi=3&buton=Afiseaza 42 RxHeader c Accept-Language: en-us 42 RxHeader c Accept-Encoding: gzip, deflate 42 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 3.0.04506.30; .NET CLR 2.0.5 0727; MS-RTC EA 2) 42 RxHeader c Host: tv.acasa.ro 42 RxHeader c Cookie: POPUPCHECK=1263294371928; trafic_h=668a2ff70l6fbe4a6dff7dea14f58330*1263207988*acasa.ro*1263207988*1263207988*1; trafic_v=1; __ut ma=240209555.189825096.1263207988.1263207988.1263207988.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.126320 42 RxHeader c Via: 1.1 cgli129a.eu.unilever.com:8080 (squid/2.6.STABLE21) 42 RxHeader c Cache-Control: max-age=259200 42 VCL_call c recv 42 VCL_acl c NO_MATCH nocache 42 VCL_return c pass 42 VCL_call c pass pass 42 Backend c 118 default default 42 ObjProtocol c HTTP/1.1 42 ObjStatus c 302 42 ObjResponse c Found 42 ObjHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 42 ObjHeader c Server: Apache 42 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 42 ObjHeader c Expires: 0 42 ObjHeader c Cache-Control: no-cache 42 ObjHeader c Pragma: no-cache 42 ObjHeader c Content-Language: ro 42 ObjHeader c Location: http://tv.acasa.ro/tv/error 42 ObjHeader c Content-Type: text/html; charset=UTF-8 42 TTL c 366310326 RFC 120 1263208903 0 0 0 0 42 VCL_call c fetch pass 42 Length c 65 42 VCL_call c deliver deliver 42 TxProtocol c HTTP/1.1 42 TxStatus c 302 42 TxResponse c Found 42 TxHeader c Server: Apache 42 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 42 TxHeader c Expires: 0 42 TxHeader c Cache-Control: no-cache 42 TxHeader c Pragma: no-cache 42 TxHeader c Content-Language: ro 42 TxHeader c Location: http://tv.acasa.ro/tv/error 42 TxHeader c Content-Type: text/html; charset=UTF-8 42 TxHeader c Content-Length: 65 42 TxHeader c Date: Mon, 11 Jan 2010 11:21:43 GMT 42 TxHeader c X-Varnish: 366310326 42 TxHeader c Age: 0 42 TxHeader c Connection: close 42 TxHeader c Via: varnish 42 TxHeader c X-Cache: MISS 42 ReqEnd c 366310326 1263208903.838655949 1263208903.969909906 0.002033949 0.131188154 0.000065804 120 SessionOpen c 216.129.119.11 40089 :80 120 ReqStart c 216.129.119.11 40089 366311845 120 RxRequest c GET 120 RxURL c /program-Cartoon_Network/2008-07-31/The-Amazing-Adrenalini-Brothers-4195409-r53.html 120 RxProtocol c HTTP/1.0 120 RxHeader c Connection: close 120 RxHeader c Host: tv.acasa.ro 120 RxHeader c Accept-Encoding: gzip 120 RxHeader c User-Agent: Mozilla/5.0 (Twiceler-0.9 http://www.cuil.com/twiceler/robot.html) 120 RxHeader c Accept: text/html, */* 120 VCL_call c recv 120 VCL_acl c NO_MATCH nocache 120 VCL_return c lookup 120 VCL_call c hash hash 120 VCL_call c miss fetch 120 Backend c 121 default default 120 ObjProtocol c HTTP/1.1 120 ObjStatus c 302 120 ObjResponse c Found 120 ObjHeader c Date: Mon, 11 Jan 2010 11:22:12 GMT 120 ObjHeader c Server: Apache 120 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 120 ObjHeader c Expires: 0 120 ObjHeader c Cache-Control: no-cache 120 ObjHeader c Pragma: no-cache 120 ObjHeader c Content-Language: ro 120 ObjHeader c Location: http://tv.acasa.ro/tv/index 120 ObjHeader c Content-Type: text/html; charset=UTF-8 120 TTL c 366311845 RFC 120 1263208932 0 0 0 0 120 VCL_call c fetch pass 120 Length c 65 120 VCL_call c deliver deliver 120 TxProtocol c HTTP/1.1 120 TxStatus c 302 120 TxResponse c Found 120 TxHeader c Server: Apache 120 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 120 TxHeader c Expires: 0 120 TxHeader c Cache-Control: no-cache 120 TxHeader c Pragma: no-cache 120 TxHeader c Content-Language: ro 120 TxHeader c Location: http://tv.acasa.ro/tv/index 120 TxHeader c Content-Type: text/html; charset=UTF-8 120 TxHeader c Content-Length: 65 120 TxHeader c Date: Mon, 11 Jan 2010 11:22:12 GMT 120 TxHeader c X-Varnish: 366311845 120 TxHeader c Age: 0 120 TxHeader c Connection: close 120 TxHeader c Via: varnish 120 TxHeader c X-Cache: MISS 120 ReqEnd c 366311845 1263208932.224442959 1263208932.402268887 0.000064850 0.177715063 0.000110865 88 SessionOpen c 67.195.115.177 57795 :80 88 ReqStart c 67.195.115.177 57795 366311992 88 RxRequest c GET 88 RxURL c /program-Antena1/2008-12-15/Scene-de-caznicie-5223267-r17.html 88 RxProtocol c HTTP/1.0 88 RxHeader c Host: tv.acasa.ro 88 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 88 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 88 RxHeader c Accept-Language: en-us,en;q=0.5 88 RxHeader c Accept-Encoding: gzip,deflate 88 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 88 RxHeader c X-LLF-Mime-Type: true 88 VCL_call c recv 88 VCL_acl c NO_MATCH nocache 88 VCL_return c lookup 88 VCL_call c hash hash 88 VCL_call c miss fetch 88 Backend c 91 default default 88 ObjProtocol c HTTP/1.1 88 ObjStatus c 302 88 ObjResponse c Found 88 ObjHeader c Date: Mon, 11 Jan 2010 11:22:13 GMT 88 ObjHeader c Server: Apache 88 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 ObjHeader c Expires: 0 88 ObjHeader c Cache-Control: no-cache 88 ObjHeader c Pragma: no-cache 88 ObjHeader c Content-Language: ro 88 ObjHeader c Location: http://tv.acasa.ro/tv/index 88 ObjHeader c Content-Type: text/html; charset=UTF-8 88 TTL c 366311992 RFC 120 1263208936 0 0 0 0 88 VCL_call c fetch pass 88 Length c 65 88 VCL_call c deliver deliver 88 TxProtocol c HTTP/1.1 88 TxStatus c 302 88 TxResponse c Found 88 TxHeader c Server: Apache 88 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 88 TxHeader c Expires: 0 88 TxHeader c Cache-Control: no-cache 88 TxHeader c Pragma: no-cache 88 TxHeader c Content-Language: ro 88 TxHeader c Location: http://tv.acasa.ro/tv/index 88 TxHeader c Content-Type: text/html; charset=UTF-8 88 TxHeader c Content-Length: 65 88 TxHeader c Date: Mon, 11 Jan 2010 11:22:16 GMT 88 TxHeader c X-Varnish: 366311992 88 TxHeader c Age: 0 88 TxHeader c Connection: close 88 TxHeader c Via: varnish 88 TxHeader c X-Cache: MISS 88 ReqEnd c 366311992 1263208933.540297031 1263208936.291946888 0.000045061 2.751549006 0.000100851 37 SessionOpen c 67.195.115.177 57937 :80 37 ReqStart c 67.195.115.177 57937 366312171 37 RxRequest c GET 37 RxURL c /program-TVR_International/2009-12-04/Tu-decizi-pentru-Romania-8547994-r15.html 37 RxProtocol c HTTP/1.0 37 RxHeader c Host: tv.acasa.ro 37 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 37 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 37 RxHeader c Accept-Language: en-us,en;q=0.5 37 RxHeader c Accept-Encoding: gzip,deflate 37 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 37 RxHeader c X-LLF-Mime-Type: true 37 VCL_call c recv 37 VCL_acl c NO_MATCH nocache 37 VCL_return c lookup 37 VCL_call c hash hash 37 VCL_call c miss fetch 37 Backend c 120 default default 37 ObjProtocol c HTTP/1.1 37 ObjStatus c 302 37 ObjResponse c Found 37 ObjHeader c Date: Mon, 11 Jan 2010 11:22:15 GMT 37 ObjHeader c Server: Apache 37 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 ObjHeader c Expires: 0 37 ObjHeader c Cache-Control: no-cache 37 ObjHeader c Pragma: no-cache 37 ObjHeader c Content-Language: ro 37 ObjHeader c Location: http://tv.acasa.ro/tv/index 37 ObjHeader c Content-Type: text/html; charset=UTF-8 37 TTL c 366312171 RFC 120 1263208936 0 0 0 0 37 VCL_call c fetch pass 37 Length c 65 37 VCL_call c deliver deliver 37 TxProtocol c HTTP/1.1 37 TxStatus c 302 37 TxResponse c Found 37 TxHeader c Server: Apache 37 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 37 TxHeader c Expires: 0 37 TxHeader c Cache-Control: no-cache 37 TxHeader c Pragma: no-cache 37 TxHeader c Content-Language: ro 37 TxHeader c Location: http://tv.acasa.ro/tv/index 37 TxHeader c Content-Type: text/html; charset=UTF-8 37 TxHeader c Content-Length: 65 37 TxHeader c Date: Mon, 11 Jan 2010 11:22:16 GMT 37 TxHeader c X-Varnish: 366312171 37 TxHeader c Age: 0 37 TxHeader c Connection: close 37 TxHeader c Via: varnish 37 TxHeader c X-Cache: MISS 37 ReqEnd c 366312171 1263208935.506747007 1263208936.349788904 0.000027895 0.842972040 0.000069857 100 SessionOpen c 67.195.115.177 58940 :80 100 ReqStart c 67.195.115.177 58940 366312985 100 RxRequest c GET 100 RxURL c /tv/film?id=5441832&newsletter=1 100 RxProtocol c HTTP/1.0 100 RxHeader c Host: tv.acasa.ro 100 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 100 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 100 RxHeader c Accept-Language: en-us,en;q=0.5 100 RxHeader c Accept-Encoding: gzip,deflate 100 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 100 RxHeader c X-LLF-Mime-Type: true 100 VCL_call c recv 100 VCL_acl c NO_MATCH nocache 100 VCL_return c lookup 100 VCL_call c hash hash 100 VCL_call c miss fetch 100 Backend c 153 default default 100 ObjProtocol c HTTP/1.1 100 ObjStatus c 302 100 ObjResponse c Found 100 ObjHeader c Date: Mon, 11 Jan 2010 11:22:27 GMT 100 ObjHeader c Server: Apache 100 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 ObjHeader c Expires: 0 100 ObjHeader c Cache-Control: no-cache 100 ObjHeader c Pragma: no-cache 100 ObjHeader c Content-Language: ro 100 ObjHeader c Location: http://tv.acasa.ro/tv/index 100 ObjHeader c Content-Type: text/html; charset=UTF-8 100 TTL c 366312985 RFC 120 1263208950 0 0 0 0 100 VCL_call c fetch pass 100 Length c 65 100 VCL_call c deliver deliver 100 TxProtocol c HTTP/1.1 100 TxStatus c 302 100 TxResponse c Found 100 TxHeader c Server: Apache 100 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 100 TxHeader c Expires: 0 100 TxHeader c Cache-Control: no-cache 100 TxHeader c Pragma: no-cache 100 TxHeader c Content-Language: ro 100 TxHeader c Location: http://tv.acasa.ro/tv/index 100 TxHeader c Content-Type: text/html; charset=UTF-8 100 TxHeader c Content-Length: 65 100 TxHeader c Date: Mon, 11 Jan 2010 11:22:30 GMT 100 TxHeader c X-Varnish: 366312985 100 TxHeader c Age: 0 100 TxHeader c Connection: close 100 TxHeader c Via: varnish 100 TxHeader c X-Cache: MISS 100 ReqEnd c 366312985 1263208947.814032078 1263208950.822393894 0.000048161 3.008318901 0.000042915 20 SessionOpen c 67.195.115.177 59716 :80 20 ReqStart c 67.195.115.177 59716 366313640 20 RxRequest c GET 20 RxURL c /program-Viasat_History/2010-01-07/Reinventatorii-8699251-r40.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 59 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:22:37 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366313640 RFC 120 1263208957 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:22:37 GMT 20 TxHeader c X-Varnish: 366313640 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366313640 1263208957.484276056 1263208957.635644913 0.000074148 0.151289940 0.000078917 99 ReqStart c 66.249.65.57 53321 366314180 99 RxRequest c GET 99 RxURL c /program-Minimax/2009-08-03/Koala-Brothers-7336748-r23.html 99 RxProtocol c HTTP/1.1 99 RxHeader c Host: tv.acasa.ro 99 RxHeader c Connection: Keep-alive 99 RxHeader c Accept: */* 99 RxHeader c From: googlebot(at)googlebot.com 99 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 99 RxHeader c Accept-Encoding: gzip,deflate 99 VCL_call c recv 99 VCL_acl c NO_MATCH nocache 99 VCL_return c lookup 99 VCL_call c hash hash 99 VCL_call c miss fetch 99 Backend c 131 default default 99 ObjProtocol c HTTP/1.1 99 ObjStatus c 302 99 ObjResponse c Found 99 ObjHeader c Date: Mon, 11 Jan 2010 11:22:45 GMT 99 ObjHeader c Server: Apache 99 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 99 ObjHeader c Expires: 0 99 ObjHeader c Cache-Control: no-cache 99 ObjHeader c Pragma: no-cache 99 ObjHeader c Content-Language: ro 99 ObjHeader c Location: http://tv.acasa.ro/tv/index 99 ObjHeader c Content-Type: text/html; charset=UTF-8 99 TTL c 366314180 RFC 120 1263208967 0 0 0 0 99 VCL_call c fetch pass 99 Length c 65 99 VCL_call c deliver deliver 99 TxProtocol c HTTP/1.1 99 TxStatus c 302 99 TxResponse c Found 99 TxHeader c Server: Apache 99 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 99 TxHeader c Expires: 0 99 TxHeader c Cache-Control: no-cache 99 TxHeader c Pragma: no-cache 99 TxHeader c Content-Language: ro 99 TxHeader c Location: http://tv.acasa.ro/tv/index 99 TxHeader c Content-Type: text/html; charset=UTF-8 99 TxHeader c Content-Length: 65 99 TxHeader c Date: Mon, 11 Jan 2010 11:22:47 GMT 99 TxHeader c X-Varnish: 366314180 99 TxHeader c Age: 0 99 TxHeader c Connection: keep-alive 99 TxHeader c Via: varnish 99 TxHeader c X-Cache: MISS 99 ReqEnd c 366314180 1263208965.381400108 1263208967.220005989 3.494348049 1.838551998 0.000053883 48 SessionOpen c 66.249.65.54 33653 :80 48 ReqStart c 66.249.65.54 33653 366314365 48 RxRequest c GET 48 RxURL c /redirect?id=3424 48 RxProtocol c HTTP/1.1 48 RxHeader c Host: dir.acasa.ro 48 RxHeader c Connection: Keep-alive 48 RxHeader c Accept: */* 48 RxHeader c From: googlebot(at)googlebot.com 48 RxHeader c User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) 48 RxHeader c Accept-Encoding: gzip,deflate 48 VCL_call c recv 48 VCL_acl c NO_MATCH nocache 48 VCL_return c lookup 48 VCL_call c hash hash 48 VCL_call c miss fetch 48 Backend c 49 default default 48 ObjProtocol c HTTP/1.1 48 ObjStatus c 302 48 ObjResponse c Found 48 ObjHeader c Date: Mon, 11 Jan 2010 11:22:47 GMT 48 ObjHeader c Server: Apache 48 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 48 ObjHeader c Expires: 0 48 ObjHeader c Cache-Control: no-cache 48 ObjHeader c Pragma: no-cache 48 ObjHeader c Content-Language: ro 48 ObjHeader c Location: http://www.hemelbeauty.com 48 ObjHeader c Set-Cookie: void=qepd8-UNFGeNnFAV; domain=.acasa.ro; path=/ 48 ObjHeader c Content-Type: text/html; charset=utf-8 48 TTL c 366314365 RFC 120 1263208968 0 0 0 0 48 VCL_call c fetch pass 48 Length c 64 48 VCL_call c deliver deliver 48 TxProtocol c HTTP/1.1 48 TxStatus c 302 48 TxResponse c Found 48 TxHeader c Server: Apache 48 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 48 TxHeader c Expires: 0 48 TxHeader c Cache-Control: no-cache 48 TxHeader c Pragma: no-cache 48 TxHeader c Content-Language: ro 48 TxHeader c Location: http://www.hemelbeauty.com 48 TxHeader c Set-Cookie: void=qepd8-UNFGeNnFAV; domain=.acasa.ro; path=/ 48 TxHeader c Content-Type: text/html; charset=utf-8 48 TxHeader c Content-Length: 64 48 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 48 TxHeader c X-Varnish: 366314365 48 TxHeader c Age: 0 48 TxHeader c Connection: keep-alive 48 TxHeader c Via: varnish 48 TxHeader c X-Cache: MISS 48 ReqEnd c 366314365 1263208967.902776957 1263208968.090610981 0.000072956 0.187798977 0.000035048 49 SessionOpen c 212.93.136.105 36020 :80 49 ReqStart c 212.93.136.105 36020 366314387 49 RxRequest c GET 49 RxURL c /program-Prima_TV/2009-12-31/Fete-de-maritat-8682717.html 49 RxProtocol c HTTP/1.0 49 RxHeader c Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-gsarcade-launch, */* 49 RxHeader c Referer: http://www.google.ro/search?client=qsb-win&rlz=1R3GGLL_roRO347RO349&hl=ro&q=fete+de+maritat 49 RxHeader c Accept-Language: en-us 49 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.3) 49 RxHeader c Accept-Encoding: gzip, deflate 49 RxHeader c Host: tv.acasa.ro 49 RxHeader c Via: 1.1 Nova-Communication (squid/3.0.STABLE13) 49 RxHeader c X-Forwarded-For: unknown 49 RxHeader c Cache-Control: max-age=259200 49 RxHeader c Connection: keep-alive 49 VCL_call c recv 49 VCL_acl c NO_MATCH nocache 49 VCL_return c lookup 49 VCL_call c hash hash 49 VCL_call c miss fetch 49 Backend c 60 default default 49 ObjProtocol c HTTP/1.1 49 ObjStatus c 302 49 ObjResponse c Found 49 ObjHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 49 ObjHeader c Server: Apache 49 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 ObjHeader c Expires: 0 49 ObjHeader c Cache-Control: no-cache 49 ObjHeader c Pragma: no-cache 49 ObjHeader c Content-Language: ro 49 ObjHeader c Location: http://tv.acasa.ro/tv/index 49 ObjHeader c Content-Type: text/html; charset=UTF-8 49 TTL c 366314387 RFC 120 1263208968 0 0 0 0 49 VCL_call c fetch pass 49 Length c 65 49 VCL_call c deliver deliver 49 TxProtocol c HTTP/1.1 49 TxStatus c 302 49 TxResponse c Found 49 TxHeader c Server: Apache 49 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 TxHeader c Expires: 0 49 TxHeader c Cache-Control: no-cache 49 TxHeader c Pragma: no-cache 49 TxHeader c Content-Language: ro 49 TxHeader c Location: http://tv.acasa.ro/tv/index 49 TxHeader c Content-Type: text/html; charset=UTF-8 49 TxHeader c Content-Length: 65 49 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 49 TxHeader c X-Varnish: 366314387 49 TxHeader c Age: 0 49 TxHeader c Connection: keep-alive 49 TxHeader c Via: varnish 49 TxHeader c X-Cache: MISS 49 ReqEnd c 366314387 1263208968.221381903 1263208968.360692978 0.000059843 0.139232159 0.000078917 28 SessionOpen c 86.122.56.146 48109 :80 28 ReqStart c 86.122.56.146 48109 366314399 28 RxRequest c GET 28 RxURL c /program-Prima_TV/2009-12-31/Fete-de-maritat-8682717.html 28 RxProtocol c HTTP/1.1 28 RxHeader c Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-gsarcade-launch, */* 28 RxHeader c Referer: http://www.google.ro/search?client=qsb-win&rlz=1R3GGLL_roRO347RO349&hl=ro&q=fete+de+maritat 28 RxHeader c Accept-Language: en-us 28 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.3) 28 RxHeader c Accept-Encoding: gzip, deflate 28 RxHeader c Host: tv.acasa.ro 28 RxHeader c X-Proxy-ID: 1182211944 28 RxHeader c X-Forwarded-For: 212.93.136.122 28 RxHeader c Via: 1.1 86.122.56.146 (Mikrotik HttpProxy) 28 VCL_call c recv 28 VCL_acl c NO_MATCH nocache 28 VCL_return c lookup 28 VCL_call c hash hash 28 HitPass c 366314387 28 VCL_call c pass pass 28 Backend c 60 default default 28 ObjProtocol c HTTP/1.1 28 ObjStatus c 302 28 ObjResponse c Found 28 ObjHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 28 ObjHeader c Server: Apache 28 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 ObjHeader c Expires: 0 28 ObjHeader c Cache-Control: no-cache 28 ObjHeader c Pragma: no-cache 28 ObjHeader c Content-Language: ro 28 ObjHeader c Location: http://tv.acasa.ro/tv/index 28 ObjHeader c Content-Type: text/html; charset=UTF-8 28 TTL c 366314399 RFC 120 1263208968 0 0 0 0 28 VCL_call c fetch pass 28 Length c 65 28 VCL_call c deliver deliver 28 TxProtocol c HTTP/1.1 28 TxStatus c 302 28 TxResponse c Found 28 TxHeader c Server: Apache 28 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 28 TxHeader c Expires: 0 28 TxHeader c Cache-Control: no-cache 28 TxHeader c Pragma: no-cache 28 TxHeader c Content-Language: ro 28 TxHeader c Location: http://tv.acasa.ro/tv/index 28 TxHeader c Content-Type: text/html; charset=UTF-8 28 TxHeader c Content-Length: 65 28 TxHeader c Date: Mon, 11 Jan 2010 11:22:48 GMT 28 TxHeader c X-Varnish: 366314399 28 TxHeader c Age: 0 28 TxHeader c Connection: keep-alive 28 TxHeader c Via: varnish 28 TxHeader c X-Cache: MISS 28 ReqEnd c 366314399 1263208968.373939991 1263208968.525717974 0.000257969 0.151699066 0.000078917 137 SessionOpen c 67.195.115.177 32897 :80 137 ReqStart c 67.195.115.177 32897 366314936 137 RxRequest c GET 137 RxURL c /program-HBO/2009-10-12/Cu-totii-la-surf--7942275.html 137 RxProtocol c HTTP/1.0 137 RxHeader c Host: tv.acasa.ro 137 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 137 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 137 RxHeader c Accept-Language: en-us,en;q=0.5 137 RxHeader c Accept-Encoding: gzip,deflate 137 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 137 RxHeader c X-LLF-Mime-Type: true 137 VCL_call c recv 137 VCL_acl c NO_MATCH nocache 137 VCL_return c lookup 137 VCL_call c hash hash 137 VCL_call c miss fetch 137 Backend c 139 default default 137 ObjProtocol c HTTP/1.1 137 ObjStatus c 302 137 ObjResponse c Found 137 ObjHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 137 ObjHeader c Server: Apache 137 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 ObjHeader c Expires: 0 137 ObjHeader c Cache-Control: no-cache 137 ObjHeader c Pragma: no-cache 137 ObjHeader c Content-Language: ro 137 ObjHeader c Location: http://tv.acasa.ro/tv/index 137 ObjHeader c Content-Type: text/html; charset=UTF-8 137 TTL c 366314936 RFC 120 1263208975 0 0 0 0 137 VCL_call c fetch pass 137 Length c 65 137 VCL_call c deliver deliver 137 TxProtocol c HTTP/1.1 137 TxStatus c 302 137 TxResponse c Found 137 TxHeader c Server: Apache 137 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 137 TxHeader c Expires: 0 137 TxHeader c Cache-Control: no-cache 137 TxHeader c Pragma: no-cache 137 TxHeader c Content-Language: ro 137 TxHeader c Location: http://tv.acasa.ro/tv/index 137 TxHeader c Content-Type: text/html; charset=UTF-8 137 TxHeader c Content-Length: 65 137 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 137 TxHeader c X-Varnish: 366314936 137 TxHeader c Age: 0 137 TxHeader c Connection: close 137 TxHeader c Via: varnish 137 TxHeader c X-Cache: MISS 137 ReqEnd c 366314936 1263208975.568783045 1263208975.872977018 0.000031948 0.304157019 0.000036955 145 SessionOpen c 84.223.183.79 60794 :80 145 ReqStart c 84.223.183.79 60794 366314919 145 RxRequest c GET 145 RxURL c /poze_Sexy_--s5.html 145 RxProtocol c HTTP/1.1 145 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; ro) Presto/2.2.15 Version/10.10 145 RxHeader c Host: poze.acasa.ro 145 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 145 RxHeader c Accept-Language: en-US,en;q=0.9 145 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 145 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 145 RxHeader c Referer: http://poze.acasa.ro/ 145 RxHeader c Cookie: POPUPCHECK=1263295357495; trafic_h=f1aba1acc6bd31dlbe216cfc3a5fe920*1263208814*acasa.ro*1263208814*1263208814*1; __utma=240209555 .1155727859.1263208814.1263208814.1263208814.1; __utmc=240209555; __utmz=240209555.1263208814.1.1.utmccn=(organic)|utm 145 RxHeader c Cookie2: $Version=1 145 RxHeader c Connection: Keep-Alive, TE 145 RxHeader c TE: deflate, gzip, chunked, identity, trailers 145 VCL_call c recv 145 VCL_acl c NO_MATCH nocache 145 VCL_return c pass 145 VCL_call c pass pass 145 Backend c 132 default default 145 ObjProtocol c HTTP/1.1 145 ObjStatus c 302 145 ObjResponse c Found 145 ObjHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 145 ObjHeader c Server: Apache 145 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 145 ObjHeader c Expires: 0 145 ObjHeader c Cache-Control: no-cache 145 ObjHeader c Pragma: no-cache 145 ObjHeader c Content-Language: ro 145 ObjHeader c Location: http://poze.acasa.ro/poze/ask 145 ObjHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 145 ObjHeader c Content-Type: text/html; charset=utf-8 145 TTL c 366314919 RFC 120 1263208975 0 0 0 0 145 VCL_call c fetch pass 145 Length c 67 145 VCL_call c deliver deliver 145 TxProtocol c HTTP/1.1 145 TxStatus c 302 145 TxResponse c Found 145 TxHeader c Server: Apache 145 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 145 TxHeader c Expires: 0 145 TxHeader c Cache-Control: no-cache 145 TxHeader c Pragma: no-cache 145 TxHeader c Content-Language: ro 145 TxHeader c Location: http://poze.acasa.ro/poze/ask 145 TxHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 145 TxHeader c Content-Type: text/html; charset=utf-8 145 TxHeader c Content-Length: 67 145 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 145 TxHeader c X-Varnish: 366314919 145 TxHeader c Age: 0 145 TxHeader c Connection: keep-alive 145 TxHeader c Via: varnish 145 TxHeader c X-Cache: MISS 145 ReqEnd c 366314919 1263208975.382122993 1263208975.889678955 0.000909090 0.507517099 0.000038862 20 SessionOpen c 67.195.115.177 60918 :80 20 ReqStart c 67.195.115.177 60918 366314793 20 RxRequest c GET 20 RxURL c /program-MTV_Rom_nia/2010-01-02/MTV-The-Movies-8711660.html 20 RxProtocol c HTTP/1.0 20 RxHeader c Host: tv.acasa.ro 20 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 20 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 20 RxHeader c Accept-Language: en-us,en;q=0.5 20 RxHeader c Accept-Encoding: gzip,deflate 20 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 20 RxHeader c X-LLF-Mime-Type: true 20 VCL_call c recv 20 VCL_acl c NO_MATCH nocache 20 VCL_return c lookup 20 VCL_call c hash hash 20 VCL_call c miss fetch 20 Backend c 23 default default 20 ObjProtocol c HTTP/1.1 20 ObjStatus c 302 20 ObjResponse c Found 20 ObjHeader c Date: Mon, 11 Jan 2010 11:22:53 GMT 20 ObjHeader c Server: Apache 20 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 ObjHeader c Expires: 0 20 ObjHeader c Cache-Control: no-cache 20 ObjHeader c Pragma: no-cache 20 ObjHeader c Content-Language: ro 20 ObjHeader c Location: http://tv.acasa.ro/tv/index 20 ObjHeader c Content-Type: text/html; charset=UTF-8 20 TTL c 366314793 RFC 120 1263208975 0 0 0 0 20 VCL_call c fetch pass 20 Length c 65 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 302 20 TxResponse c Found 20 TxHeader c Server: Apache 20 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 20 TxHeader c Expires: 0 20 TxHeader c Cache-Control: no-cache 20 TxHeader c Pragma: no-cache 20 TxHeader c Content-Language: ro 20 TxHeader c Location: http://tv.acasa.ro/tv/index 20 TxHeader c Content-Type: text/html; charset=UTF-8 20 TxHeader c Content-Length: 65 20 TxHeader c Date: Mon, 11 Jan 2010 11:22:55 GMT 20 TxHeader c X-Varnish: 366314793 20 TxHeader c Age: 0 20 TxHeader c Connection: close 20 TxHeader c Via: varnish 20 TxHeader c X-Cache: MISS 20 ReqEnd c 366314793 1263208973.286572933 1263208975.890410900 0.000128984 2.603799105 0.000038862 60 SessionOpen c 92.86.133.2 1996 :80 60 ReqStart c 92.86.133.2 1996 366315356 60 RxRequest c GET 60 RxURL c /redirect?id=6392 60 RxProtocol c HTTP/1.1 60 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.10 60 RxHeader c Host: dir.acasa.ro 60 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 60 RxHeader c Accept-Language: ro,en-US;q=0.9,en;q=0.8 60 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 60 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 60 RxHeader c Referer: http://dir.acasa.ro/Sanatate/Clinici/Stomatologie--420.html 60 RxHeader c Cookie: POPUPCHECK=1263295388703; trafic_h=7led5054a4bc052d2c0f778376c41b9a*1261326231*acasa.ro*1261326231*1263208955*2; __utma=240209555 .1745029308.1261326231.1261326231.1263208955.2; __utmc=240209555; __utmz=240209555.1263208955.2.2.utmccn=(organic)|utm 60 RxHeader c Cookie2: $Version=1 60 RxHeader c Connection: Keep-Alive, TE 60 RxHeader c TE: deflate, gzip, chunked, identity, trailers 60 VCL_call c recv 60 VCL_acl c NO_MATCH nocache 60 VCL_return c pass 60 VCL_call c pass pass 60 Backend c 157 default default 60 ObjProtocol c HTTP/1.1 60 ObjStatus c 302 60 ObjResponse c Found 60 ObjHeader c Date: Mon, 11 Jan 2010 11:23:00 GMT 60 ObjHeader c Server: Apache 60 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 60 ObjHeader c Expires: 0 60 ObjHeader c Cache-Control: no-cache 60 ObjHeader c Pragma: no-cache 60 ObjHeader c Content-Language: ro 60 ObjHeader c Location: http://www.stoma-urgent.ro 60 ObjHeader c Set-Cookie: void=Yw4Df-ATltcluTzzE; domain=.acasa.ro; path=/ 60 ObjHeader c Content-Type: text/html; charset=utf-8 60 TTL c 366315356 RFC 120 1263208980 0 0 0 0 60 VCL_call c fetch pass 60 Length c 64 60 VCL_call c deliver deliver 60 TxProtocol c HTTP/1.1 60 TxStatus c 302 60 TxResponse c Found 60 TxHeader c Server: Apache 60 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 60 TxHeader c Expires: 0 60 TxHeader c Cache-Control: no-cache 60 TxHeader c Pragma: no-cache 60 TxHeader c Content-Language: ro 60 TxHeader c Location: http://www.stoma-urgent.ro 60 TxHeader c Set-Cookie: void=Yw4Df-ATltcluTzzE; domain=.acasa.ro; path=/ 60 TxHeader c Content-Type: text/html; charset=utf-8 60 TxHeader c Content-Length: 64 60 TxHeader c Date: Mon, 11 Jan 2010 11:23:00 GMT 60 TxHeader c X-Varnish: 366315356 60 TxHeader c Age: 0 60 TxHeader c Connection: keep-alive 60 TxHeader c Via: varnish 60 TxHeader c X-Cache: MISS 60 ReqEnd c 366315356 1263208980.480185032 1263208980.654925108 0.000219107 0.174679995 0.000060081 66 SessionOpen c 84.223.183.79 60817 :80 66 ReqStart c 84.223.183.79 60817 366315921 66 RxRequest c POST 66 RxURL c /poze/ask 66 RxProtocol c HTTP/1.1 66 RxHeader c User-Agent: Opera/9.80 (Windows NT 5.1; U; ro) Presto/2.2.15 Version/10.10 66 RxHeader c Host: poze.acasa.ro 66 RxHeader c Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 66 RxHeader c Accept-Language: en-US,en;q=0.9 66 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 66 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 66 RxHeader c Referer: http://poze.acasa.ro/poze/ask 66 RxHeader c Cookie: POPUPCHECK=1263295357495; trafic_h=f1aba1acc6bd31dlbe216cfc3a5fe920*1263208814*acasa.ro*1263208814*1263208814*1; __utma=240209555 .1155727859.1263208814.1263208814.1263208814.1; __utmc=240209555; __utmz=240209555.1263208814.1.1.utmccn=(organic)|utm 66 RxHeader c Cookie2: $Version=1 66 RxHeader c Connection: Keep-Alive, TE 66 RxHeader c TE: deflate, gzip, chunked, identity, trailers 66 RxHeader c Content-Length: 16 66 RxHeader c Content-Type: application/x-www-form-urlencoded 66 VCL_call c recv 66 VCL_acl c NO_MATCH nocache 66 VCL_return c pass 66 VCL_call c pass pass 66 Backend c 128 default default 66 ObjProtocol c HTTP/1.1 66 ObjStatus c 302 66 ObjResponse c Found 66 ObjHeader c Date: Mon, 11 Jan 2010 11:23:05 GMT 66 ObjHeader c Server: Apache 66 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 ObjHeader c Expires: 0 66 ObjHeader c Cache-Control: no-cache 66 ObjHeader c Pragma: no-cache 66 ObjHeader c Content-Language: ro 66 ObjHeader c Location: http://poze.acasa.ro/poze/top?categ=5 66 ObjHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 66 ObjHeader c Content-Type: text/html; charset=utf-8 66 TTL c 366315921 RFC 120 1263208985 0 0 0 0 66 VCL_call c fetch pass 66 Length c 75 66 VCL_call c deliver deliver 66 TxProtocol c HTTP/1.1 66 TxStatus c 302 66 TxResponse c Found 66 TxHeader c Server: Apache 66 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 66 TxHeader c Expires: 0 66 TxHeader c Cache-Control: no-cache 66 TxHeader c Pragma: no-cache 66 TxHeader c Content-Language: ro 66 TxHeader c Location: http://poze.acasa.ro/poze/top?categ=5 66 TxHeader c Set-Cookie: void=Wwf0n-8YUFI6uvuRp; domain=.acasa.ro; path=/ 66 TxHeader c Content-Type: text/html; charset=utf-8 66 TxHeader c Content-Length: 75 66 TxHeader c Date: Mon, 11 Jan 2010 11:23:05 GMT 66 TxHeader c X-Varnish: 366315921 66 TxHeader c Age: 0 66 TxHeader c Connection: keep-alive 66 TxHeader c Via: varnish 66 TxHeader c X-Cache: MISS 66 ReqEnd c 366315921 1263208985.546696901 1263208985.818258047 0.000101805 0.271466017 0.000095129 49 SessionOpen c 95.108.156.251 59155 :80 49 ReqStart c 95.108.156.251 59155 366316143 49 RxRequest c GET 49 RxURL c /program-Free_X_TV/2010-01-13/I-Swallow-Six-Part-1-8949460-r87.html 49 RxProtocol c HTTP/1.1 49 RxHeader c Host: tv.acasa.ro 49 RxHeader c Connection: Keep-Alive 49 RxHeader c Accept: */* 49 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 49 RxHeader c Accept-Encoding: gzip,deflate 49 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 49 RxHeader c From: webadmin at yandex.ru 49 VCL_call c recv 49 VCL_acl c NO_MATCH nocache 49 VCL_return c lookup 49 VCL_call c hash hash 49 VCL_call c miss fetch 49 Backend c 50 default default 49 ObjProtocol c HTTP/1.1 49 ObjStatus c 302 49 ObjResponse c Found 49 ObjHeader c Date: Mon, 11 Jan 2010 11:23:10 GMT 49 ObjHeader c Server: Apache 49 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 ObjHeader c Expires: 0 49 ObjHeader c Cache-Control: no-cache 49 ObjHeader c Pragma: no-cache 49 ObjHeader c Content-Language: ro 49 ObjHeader c Location: http://tv.acasa.ro/tv/index 49 ObjHeader c Content-Type: text/html; charset=UTF-8 49 TTL c 366316143 RFC 120 1263208990 0 0 0 0 49 VCL_call c fetch pass 49 Length c 65 49 VCL_call c deliver deliver 49 TxProtocol c HTTP/1.1 49 TxStatus c 302 49 TxResponse c Found 49 TxHeader c Server: Apache 49 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 49 TxHeader c Expires: 0 49 TxHeader c Cache-Control: no-cache 49 TxHeader c Pragma: no-cache 49 TxHeader c Content-Language: ro 49 TxHeader c Location: http://tv.acasa.ro/tv/index 49 TxHeader c Content-Type: text/html; charset=UTF-8 49 TxHeader c Content-Length: 65 49 TxHeader c Date: Mon, 11 Jan 2010 11:23:10 GMT 49 TxHeader c X-Varnish: 366316143 49 TxHeader c Age: 0 49 TxHeader c Connection: keep-alive 49 TxHeader c Via: varnish 49 TxHeader c X-Cache: MISS 49 ReqEnd c 366316143 1263208990.798176050 1263208990.954207897 0.000100136 0.155927896 0.000103951 44 SessionOpen c 79.118.206.91 2094 :80 44 ReqStart c 79.118.206.91 2094 366316258 44 RxRequest c GET 44 RxURL c /post?id=-1&zi=6&buton=Afiseaza 44 RxProtocol c HTTP/1.1 44 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, */* 44 RxHeader c Referer: http://tv.acasa.ro/program_Antena_1_--p17.html 44 RxHeader c Accept-Language: ro 44 RxHeader c Accept-Encoding: gzip, deflate 44 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) 44 RxHeader c Host: tv.acasa.ro 44 RxHeader c Connection: Keep-Alive 44 RxHeader c Cookie: POPUPCHECK=1263295370846; trafic_h=7f7dd489e8e29elad208401f069d065b*1263208980*acasa.ro*1263208980*1263208980*1; trafic_v=1; __ut ma=240209555.964185069.1263208980.1263208980.1263208980.1; __utmb=240209555; __utmc=240209555; __utmz=240209555.126320 44 VCL_call c recv 44 VCL_acl c NO_MATCH nocache 44 VCL_return c pass 44 VCL_call c pass pass 44 Backend c 80 default default 44 ObjProtocol c HTTP/1.1 44 ObjStatus c 302 44 ObjResponse c Found 44 ObjHeader c Date: Mon, 11 Jan 2010 11:23:13 GMT 44 ObjHeader c Server: Apache 44 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 44 ObjHeader c Expires: 0 44 ObjHeader c Cache-Control: no-cache 44 ObjHeader c Pragma: no-cache 44 ObjHeader c Content-Language: ro 44 ObjHeader c Location: http://tv.acasa.ro/tv/error 44 ObjHeader c Content-Type: text/html; charset=UTF-8 44 TTL c 366316258 RFC 120 1263208993 0 0 0 0 44 VCL_call c fetch pass 44 Length c 65 44 VCL_call c deliver deliver 44 TxProtocol c HTTP/1.1 44 TxStatus c 302 44 TxResponse c Found 44 TxHeader c Server: Apache 44 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 44 TxHeader c Expires: 0 44 TxHeader c Cache-Control: no-cache 44 TxHeader c Pragma: no-cache 44 TxHeader c Content-Language: ro 44 TxHeader c Location: http://tv.acasa.ro/tv/error 44 TxHeader c Content-Type: text/html; charset=UTF-8 44 TxHeader c Content-Length: 65 44 TxHeader c Date: Mon, 11 Jan 2010 11:23:13 GMT 44 TxHeader c X-Varnish: 366316258 44 TxHeader c Age: 0 44 TxHeader c Connection: keep-alive 44 TxHeader c Via: varnish 44 TxHeader c X-Cache: MISS 44 ReqEnd c 366316258 1263208993.198345900 1263208993.321660042 0.000089884 0.123182058 0.000132084 122 SessionOpen c 216.129.119.11 57673 :80 122 ReqStart c 216.129.119.11 57673 366316404 122 RxRequest c GET 122 RxURL c /program-Cartoon_Network/2008-07-14/Dexter-s-Laboratory-4118211-r53.html 122 RxProtocol c HTTP/1.0 122 RxHeader c Connection: close 122 RxHeader c Host: tv.acasa.ro 122 RxHeader c Accept-Encoding: gzip 122 RxHeader c User-Agent: Mozilla/5.0 (Twiceler-0.9 http://www.cuil.com/twiceler/robot.html) 122 RxHeader c Accept: text/html, */* 122 VCL_call c recv 122 VCL_acl c NO_MATCH nocache 122 VCL_return c lookup 122 VCL_call c hash hash 122 VCL_call c miss fetch 122 Backend c 123 default default 122 ObjProtocol c HTTP/1.1 122 ObjStatus c 302 122 ObjResponse c Found 122 ObjHeader c Date: Mon, 11 Jan 2010 11:23:16 GMT 122 ObjHeader c Server: Apache 122 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 ObjHeader c Expires: 0 122 ObjHeader c Cache-Control: no-cache 122 ObjHeader c Pragma: no-cache 122 ObjHeader c Content-Language: ro 122 ObjHeader c Location: http://tv.acasa.ro/tv/index 122 ObjHeader c Content-Type: text/html; charset=UTF-8 122 TTL c 366316404 RFC 120 1263208997 0 0 0 0 122 VCL_call c fetch pass 122 Length c 65 122 VCL_call c deliver deliver 122 TxProtocol c HTTP/1.1 122 TxStatus c 302 122 TxResponse c Found 122 TxHeader c Server: Apache 122 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 TxHeader c Expires: 0 122 TxHeader c Cache-Control: no-cache 122 TxHeader c Pragma: no-cache 122 TxHeader c Content-Language: ro 122 TxHeader c Location: http://tv.acasa.ro/tv/index 122 TxHeader c Content-Type: text/html; charset=UTF-8 122 TxHeader c Content-Length: 65 122 TxHeader c Date: Mon, 11 Jan 2010 11:23:17 GMT 122 TxHeader c X-Varnish: 366316404 122 TxHeader c Age: 0 122 TxHeader c Connection: close 122 TxHeader c Via: varnish 122 TxHeader c X-Cache: MISS 122 ReqEnd c 366316404 1263208996.941240072 1263208997.059401989 0.000029087 0.118115902 0.000046015 61 SessionOpen c 67.195.111.158 34343 :80 61 ReqStart c 67.195.111.158 34343 366317722 61 RxRequest c GET 61 RxURL c /redirect?id=19222 61 RxProtocol c HTTP/1.0 61 RxHeader c Host: dir.acasa.ro 61 RxHeader c User-Agent: Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 61 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 61 RxHeader c Accept-Language: en-us,en;q=0.5 61 RxHeader c Accept-Encoding: gzip,deflate 61 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 61 RxHeader c X-LLF-Mime-Type: true 61 VCL_call c recv 61 VCL_acl c NO_MATCH nocache 61 VCL_return c lookup 61 VCL_call c hash hash 61 VCL_call c miss fetch 61 Backend c 83 default default 61 ObjProtocol c HTTP/1.1 61 ObjStatus c 302 61 ObjResponse c Found 61 ObjHeader c Date: Mon, 11 Jan 2010 11:23:34 GMT 61 ObjHeader c Server: Apache 61 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 61 ObjHeader c Expires: 0 61 ObjHeader c Cache-Control: no-cache 61 ObjHeader c Pragma: no-cache 61 ObjHeader c Content-Language: ro 61 ObjHeader c Location: http://www.evamendes-pics.com 61 ObjHeader c Set-Cookie: void=1r6eo88m9oUDVQrlY; domain=.acasa.ro; path=/ 61 ObjHeader c Content-Type: text/html; charset=utf-8 61 TTL c 366317722 RFC 120 1263209014 0 0 0 0 61 VCL_call c fetch pass 61 Length c 67 61 VCL_call c deliver deliver 61 TxProtocol c HTTP/1.1 61 TxStatus c 302 61 TxResponse c Found 61 TxHeader c Server: Apache 61 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 61 TxHeader c Expires: 0 61 TxHeader c Cache-Control: no-cache 61 TxHeader c Pragma: no-cache 61 TxHeader c Content-Language: ro 61 TxHeader c Location: http://www.evamendes-pics.com 61 TxHeader c Set-Cookie: void=1r6eo88m9oUDVQrlY; domain=.acasa.ro; path=/ 61 TxHeader c Content-Type: text/html; charset=utf-8 61 TxHeader c Content-Length: 67 61 TxHeader c Date: Mon, 11 Jan 2010 11:23:34 GMT 61 TxHeader c X-Varnish: 366317722 61 TxHeader c Age: 0 61 TxHeader c Connection: close 61 TxHeader c Via: varnish 61 TxHeader c X-Cache: MISS 61 ReqEnd c 366317722 1263209014.604552984 1263209014.849833965 0.000097990 0.245194912 0.000086069 122 SessionOpen c 217.10.213.126 1600 :80 122 ReqStart c 217.10.213.126 1600 366317877 122 RxRequest c GET 122 RxURL c /program-Prima_TV/2010-01-04/Fermier-Caut-nevasta--8759315.html 122 RxProtocol c HTTP/1.1 122 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-m s-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-silverlight, */* 122 RxHeader c Referer: http://www.google.ro/search?hl=ro&source=hp&q=fermier+caut+nevasta&meta=&aq=0&oq=fermier 122 RxHeader c Accept-Language: en-us 122 RxHeader c Accept-Encoding: gzip, deflate 122 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET C LR 3.5.30729) 122 RxHeader c Host: tv.acasa.ro 122 RxHeader c Connection: Keep-Alive 122 RxHeader c Cookie: POPUPCHECK=1261143965421; trafic_h=05dba28ffda3e46l10837189cc8f7189*1250985859*acasa.ro*1262264880*1262849575*11; __utma=24020955 5.1771099526.1250985859.1262264880.1262849575.12; __utmz=240209555.1262849575.12.12.utmccn=(organic)|utmcsr=google|utm 122 VCL_call c recv 122 VCL_acl c NO_MATCH nocache 122 VCL_return c pass 122 VCL_call c pass pass 122 Backend c 125 default default 122 ObjProtocol c HTTP/1.1 122 ObjStatus c 302 122 ObjResponse c Found 122 ObjHeader c Date: Mon, 11 Jan 2010 11:23:38 GMT 122 ObjHeader c Server: Apache 122 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 ObjHeader c Expires: 0 122 ObjHeader c Cache-Control: no-cache 122 ObjHeader c Pragma: no-cache 122 ObjHeader c Content-Language: ro 122 ObjHeader c Location: http://tv.acasa.ro/tv/index 122 ObjHeader c Content-Type: text/html; charset=UTF-8 122 TTL c 366317877 RFC 120 1263209018 0 0 0 0 122 VCL_call c fetch pass 122 Length c 65 122 VCL_call c deliver deliver 122 TxProtocol c HTTP/1.1 122 TxStatus c 302 122 TxResponse c Found 122 TxHeader c Server: Apache 122 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 122 TxHeader c Expires: 0 122 TxHeader c Cache-Control: no-cache 122 TxHeader c Pragma: no-cache 122 TxHeader c Content-Language: ro 122 TxHeader c Location: http://tv.acasa.ro/tv/index 122 TxHeader c Content-Type: text/html; charset=UTF-8 122 TxHeader c Content-Length: 65 122 TxHeader c Date: Mon, 11 Jan 2010 11:23:38 GMT 122 TxHeader c X-Varnish: 366317877 122 TxHeader c Age: 0 122 TxHeader c Connection: keep-alive 122 TxHeader c Via: varnish 122 TxHeader c X-Cache: MISS 122 ReqEnd c 366317877 1263209018.077413082 1263209018.414202929 0.000061035 0.336716890 0.000072956 84 SessionOpen c 95.108.156.251 51915 :80 84 ReqStart c 95.108.156.251 51915 366318200 84 RxRequest c GET 84 RxURL c /program-Free_X_TV/2010-01-11/We-Swallow-12-Part-2-8894997-r87.html 84 RxProtocol c HTTP/1.1 84 RxHeader c Host: tv.acasa.ro 84 RxHeader c Connection: Keep-Alive 84 RxHeader c Accept: */* 84 RxHeader c Accept-Language: ru, uk;q=0.8, be;q=0.8, en;q=0.7, *;q=0.01 84 RxHeader c Accept-Encoding: gzip,deflate 84 RxHeader c User-Agent: Yandex/1.01.001 (compatible; Win16; I) 84 RxHeader c From: webadmin at yandex.ru 84 VCL_call c recv 84 VCL_acl c NO_MATCH nocache 84 VCL_return c lookup 84 VCL_call c hash hash 84 VCL_call c miss fetch 84 Backend c 86 default default 84 ObjProtocol c HTTP/1.1 84 ObjStatus c 302 84 ObjResponse c Found 84 ObjHeader c Date: Mon, 11 Jan 2010 11:23:44 GMT 84 ObjHeader c Server: Apache 84 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 84 ObjHeader c Expires: 0 84 ObjHeader c Cache-Control: no-cache 84 ObjHeader c Pragma: no-cache 84 ObjHeader c Content-Language: ro 84 ObjHeader c Location: http://tv.acasa.ro/tv/index 84 ObjHeader c Content-Type: text/html; charset=UTF-8 84 TTL c 366318200 RFC 120 1263209024 0 0 0 0 84 VCL_call c fetch pass 84 Length c 65 84 VCL_call c deliver deliver 84 TxProtocol c HTTP/1.1 84 TxStatus c 302 84 TxResponse c Found 84 TxHeader c Server: Apache 84 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 84 TxHeader c Expires: 0 84 TxHeader c Cache-Control: no-cache 84 TxHeader c Pragma: no-cache 84 TxHeader c Content-Language: ro 84 TxHeader c Location: http://tv.acasa.ro/tv/index 84 TxHeader c Content-Type: text/html; charset=UTF-8 84 TxHeader c Content-Length: 65 84 TxHeader c Date: Mon, 11 Jan 2010 11:23:44 GMT 84 TxHeader c X-Varnish: 366318200 84 TxHeader c Age: 0 84 TxHeader c Connection: keep-alive 84 TxHeader c Via: varnish 84 TxHeader c X-Cache: MISS 84 ReqEnd c 366318200 1263209024.067236900 1263209024.220580101 0.000073910 0.153258085 0.000085115 89 SessionOpen c 89.36.221.240 2805 :80 89 ReqStart c 89.36.221.240 2805 366318967 89 RxRequest c GET 89 RxURL c /post?id=-1&zi=-1&buton=Afiseaza 89 RxProtocol c HTTP/1.1 89 RxHeader c Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, */* 89 RxHeader c Referer: http://tv.acasa.ro/post?id=97&zi=-1&buton=Afiseaza 89 RxHeader c Accept-Language: en-US 89 RxHeader c UA-CPU: x86 89 RxHeader c Accept-Encoding: gzip, deflate 89 RxHeader c User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; FunWebProducts) 89 RxHeader c Host: tv.acasa.ro 89 RxHeader c Connection: Keep-Alive 89 RxHeader c Cookie: POPUPCHECK=1263294670062; trafic_h=56fd9cc3a73al35f0934098a84024bb2*1260962519*acasa.ro*1262766245*1263208279*5; trafic_v=1; __ut ma=240209555.2116266143.1260962520.1263208641.1263209020.8; __utmb=240209555; __utmz=240209555.1263208641.7.6.utmccn=( 89 VCL_call c recv 89 VCL_acl c NO_MATCH nocache 89 VCL_return c pass 89 VCL_call c pass pass 89 Backend c 90 default default 89 ObjProtocol c HTTP/1.1 89 ObjStatus c 302 89 ObjResponse c Found 89 ObjHeader c Date: Mon, 11 Jan 2010 11:23:58 GMT 89 ObjHeader c Server: Apache 89 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 89 ObjHeader c Expires: 0 89 ObjHeader c Cache-Control: no-cache 89 ObjHeader c Pragma: no-cache 89 ObjHeader c Content-Language: ro 89 ObjHeader c Location: http://tv.acasa.ro/tv/error 89 ObjHeader c Content-Type: text/html; charset=UTF-8 89 TTL c 366318967 RFC 120 1263209039 0 0 0 0 89 VCL_call c fetch pass 89 Length c 65 89 VCL_call c deliver deliver 89 TxProtocol c HTTP/1.1 89 TxStatus c 302 89 TxResponse c Found 89 TxHeader c Server: Apache 89 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 89 TxHeader c Expires: 0 89 TxHeader c Cache-Control: no-cache 89 TxHeader c Pragma: no-cache 89 TxHeader c Content-Language: ro 89 TxHeader c Location: http://tv.acasa.ro/tv/error 89 TxHeader c Content-Type: text/html; charset=UTF-8 89 TxHeader c Content-Length: 65 89 TxHeader c Date: Mon, 11 Jan 2010 11:23:59 GMT 89 TxHeader c X-Varnish: 366318967 89 TxHeader c Age: 0 89 TxHeader c Connection: keep-alive 89 TxHeader c Via: varnish 89 TxHeader c X-Cache: MISS 89 ReqEnd c 366318967 1263209038.969425917 1263209039.157500029 0.000106812 0.187976122 0.000097990 23 SessionOpen c 65.55.216.32 55026 :80 23 ReqStart c 65.55.216.32 55026 366320162 23 RxRequest c GET 23 RxURL c /redirect?id=6857 23 RxProtocol c HTTP/1.1 23 RxHeader c Accept: */* 23 RxHeader c Host: dir.acasa.ro 23 RxHeader c Accept-Encoding: gzip, deflate 23 RxHeader c User-Agent: msnbot/2.0b (+http://search.msn.com/msnbot.htm) 23 RxHeader c Connection: Keep-Alive 23 RxHeader c Cache-Control: no-cache 23 RxHeader c Pragma: no-cache 23 VCL_call c recv 23 VCL_acl c NO_MATCH nocache 23 VCL_return c lookup 23 VCL_call c hash hash 23 VCL_call c miss fetch 23 Backend c 26 default default 23 ObjProtocol c HTTP/1.1 23 ObjStatus c 302 23 ObjResponse c Found 23 ObjHeader c Date: Mon, 11 Jan 2010 11:24:12 GMT 23 ObjHeader c Server: Apache 23 ObjHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 ObjHeader c Expires: 0 23 ObjHeader c Cache-Control: no-cache 23 ObjHeader c Pragma: no-cache 23 ObjHeader c Content-Language: ro 23 ObjHeader c Location: http://www.calion.ro 23 ObjHeader c Set-Cookie: void=3w60B3c8lUVS4qSi; domain=.acasa.ro; path=/ 23 ObjHeader c Content-Type: text/html; charset=utf-8 23 TTL c 366320162 RFC 120 1263209052 0 0 0 0 23 VCL_call c fetch pass 23 Length c 58 23 VCL_call c deliver deliver 23 TxProtocol c HTTP/1.1 23 TxStatus c 302 23 TxResponse c Found 23 TxHeader c Server: Apache 23 TxHeader c P3P: CP="NOI DSP COR LAW CURa DEVa TAIa PSAa PSDa OUR BUS UNI COM NAV" 23 TxHeader c Expires: 0 23 TxHeader c Cache-Control: no-cache 23 TxHeader c Pragma: no-cache 23 TxHeader c Content-Language: ro 23 TxHeader c Location: http://www.calion.ro 23 TxHeader c Set-Cookie: void=3w60B3c8lUVS4qSi; domain=.acasa.ro; path=/ 23 TxHeader c Content-Type: text/html; charset=utf-8 23 TxHeader c Content-Length: 58 23 TxHeader c Date: Mon, 11 Jan 2010 11:24:12 GMT 23 TxHeader c X-Varnish: 366320162 23 TxHeader c Age: 0 23 TxHeader c Connection: keep-alive 23 TxHeader c Via: varnish 23 TxHeader c X-Cache: MISS 23 ReqEnd c 366320162 1263209052.389780045 1263209052.577569008 0.000031948 0.187749863 0.000039101 -------------- next part -------------- # backend default { .host = "127.0.0.1"; .port = "79"; } acl purge { "localhost"; "192.168.100.0"/24; "217.156.103.4"; "89.32.16.26"; "89.115.4.220"; } # NO CACHE FROM CR.NETBRIDGE.RO acl nocache { "217.156.103.4"; } sub vcl_recv { if (req.request == "PURGE") { if(!client.ip ~ purge) { error 405 "Not Allowed"; } purge("req.url == " req.url); } # NO CACHE FROM CR.NETBRIDGE.RO if (client.ip ~ nocache) { return (pass); } ##### we added this part after we got the complaints # !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! # if (req.url ~ "^(www.)dir.acasa.ro") { # return (pass); #} if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { return (pipe); } # if (req.request != "GET" && req.request != "HEAD") { # /* We only deal with GET and HEAD by default */ # return (pass); # } if (req.http.Expect) { return (pipe); } if (req.http.Authorization || req.http.Cookie) { return (pass); } # return (lookup); #} if (req.http.Accept-Encoding) { if (req.http.Accept-Encoding ~ "gzip") { set req.http.Accept-Encoding = "gzip"; } elsif (req.http.Accept-Encoding ~ "deflate") { set req.http.Accept-Encoding = "deflate"; } else { unset req.http.Accept-Encoding; } } set req.grace = 30s; if (req.url ~ "^/(content|flash)") { return (pass); } if (req.http.host ~ "^(www.)?xmlmuzica.acasa.ro$") { return (pass); } # if (req.url ~ "^/(uploads|images|img|css|js)/" || req.url ~ "\.(txt|ico|png|jpeg|jpg|gif|tiff|js|css)$") { if (req.url ~ "\.(txt|ico|png|jpeg|jpg|gif|tiff|js|css)$") { unset req.http.Cookie; } } sub vcl_pipe { return (pipe); } sub vcl_pass { return (pass); } sub vcl_hash { set req.hash += req.url; if (req.http.host) { set req.hash += req.http.host; } else { set req.hash += server.ip; } return (hash); } sub vcl_hit { if (!obj.cacheable) { return (pass); } return (deliver); } sub vcl_miss { return (fetch); } sub vcl_fetch { if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)") { pass; } if (obj.ttl < 180s) { set obj.ttl = 1w; } set obj.grace = 30s; if (req.http.Authorization && !obj.http.Cache-Control ~ "public") { pass; } } sub vcl_deliver { set resp.http.Via = "varnish"; 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"; } } sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {" Acasa.ro ERROR!

Ne pare rau, in timpul procesarii cererii tale, am intampinat o eroare. Te rugam sa ne contactezi pe adresa de suport si sa ne detaliezi actiunea care a generat eroarea.

webmaster at acasa.ro

CONTACT
From phk at phk.freebsd.dk Mon Jan 11 16:15:47 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Jan 2010 16:15:47 +0000 Subject: Purging multiple requests In-Reply-To: Your message of "Mon, 11 Jan 2010 21:40:00 +0530." <75cf5801001110810k61d27215r1e69cee60731ebeb@mail.gmail.com> Message-ID: <46244.1263226547@critter.freebsd.dk> In message <75cf5801001110810k61d27215r1e69cee60731ebeb at mail.gmail.com>, Paras Fadte writes: >Is the following usage correct then ? > >*purge.url (/a/1.html|/b/2.html|/c/3.html)* yes, something like that. Check the regexp manual page or PCRE documentation if you are not used to regular expressions. O'Reilly probably also has a book about them... Poul-Henning -- 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 plfgoa at gmail.com Mon Jan 11 16:10:00 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Mon, 11 Jan 2010 21:40:00 +0530 Subject: Purging multiple requests In-Reply-To: <80260.1263199323@critter.freebsd.dk> References: <75cf5801001110036r5f3b2347g832e399cbe16f674@mail.gmail.com> <80260.1263199323@critter.freebsd.dk> Message-ID: <75cf5801001110810k61d27215r1e69cee60731ebeb@mail.gmail.com> Is the following usage correct then ? *purge.url (/a/1.html|/b/2.html|/c/3.html)* On Mon, Jan 11, 2010 at 2:12 PM, Poul-Henning Kamp wrote: > In message <75cf5801001110036r5f3b2347g832e399cbe16f674 at mail.gmail.com>, > Paras > Fadte writes: > > >Is it possible to purge a list of urls in varnish ? > > You can purge them as one regexp using (...|...|...|...|...) syntax > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at 7fff.com Tue Jan 12 01:27:40 2010 From: john at 7fff.com (John Norman) Date: Mon, 11 Jan 2010 20:27:40 -0500 Subject: Purging multiple requests In-Reply-To: <46244.1263226547@critter.freebsd.dk> References: <75cf5801001110810k61d27215r1e69cee60731ebeb@mail.gmail.com> <46244.1263226547@critter.freebsd.dk> Message-ID: Scenario: -- We would prefer not to leverage checking a lot of paths. -- Many pages are cached for GET's. -- In vcl_recv, we want to remove cookies and check the cache: if (req.request == "GET") { unset req.http.cookie; unset req.http.Authorization; lookup; } BUT: Suppose the lookup results in a MISS: Now we would like to "pass" but WITH the cookies. I.e., check the cache without cookies; but if there's a miss, reattach them and make the request. ---------------------- Let me put this another way, describing what's happening in our code: There are many routine server responses for which we have set caching headers. All is beautiful. But we have some, primarily of the form /something/edit where we would like to use the cookie to bring data into a form. To be sure, we could check the file paths . . . if (req.request == "GET" && req.url !~ "/edit$") { unset req.http.cookie; unset req.http.Authorization; lookup; } but we were wondering if there is a pattern to save the cookies and then reattach them later (in vcl_miss??), and thus get the "pass" to the backend with the cookies back on the request. John From kb+varnish at slide.com Tue Jan 12 01:44:03 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 11 Jan 2010 17:44:03 -0800 Subject: Purging multiple requests In-Reply-To: References: <75cf5801001110810k61d27215r1e69cee60731ebeb@mail.gmail.com> <46244.1263226547@critter.freebsd.dk> Message-ID: <1304E651-B595-4BD3-9A09-44A1B2C92122@slide.com> Something like: sub vcl_recv { if ( req.request == "GET" ) { set req.http.OLD-Cookie = req.http.Cookie; unset req.http.Cookie; set req.http.OLD-Authorization = req.http.Authorization; unset req.http.Authorization; } } sub vcl_miss { if ( req.http.OLD-Cookie ) { set bereq.http.Cookie = req.http.OLD-Cookie; unset req.http.OLD-Cookie; } if ( req.http.OLD-Authorization ) { set bereq.http.Authorization = req.http.OLD-Authorization; unset req.http.OLD-Authorization; } } But beware that you may need to increase your sess_workspace, especially if these headers are large. -- Ken On Jan 11, 2010, at 5:27 PM, John Norman wrote: > Scenario: > > -- We would prefer not to leverage checking a lot of paths. > > -- Many pages are cached for GET's. > > -- In vcl_recv, we want to remove cookies and check the cache: > > if (req.request == "GET") { > unset req.http.cookie; > unset req.http.Authorization; > lookup; > } > > BUT: Suppose the lookup results in a MISS: > > Now we would like to "pass" but WITH the cookies. I.e., check the > cache without cookies; but if there's a miss, reattach them and make > the request. > > ---------------------- > > Let me put this another way, describing what's happening in our code: > > There are many routine server responses for which we have set caching > headers. All is beautiful. > > But we have some, primarily of the form > > /something/edit > > where we would like to use the cookie to bring data into a form. > > To be sure, we could check the file paths . . . > > if (req.request == "GET" && req.url !~ "/edit$") { > unset req.http.cookie; > unset req.http.Authorization; > lookup; > } > > but we were wondering if there is a pattern to save the cookies and > then reattach them later (in vcl_miss??), and thus get the "pass" to > the backend with the cookies back on the request. > > John > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From pubcrawler.com at gmail.com Tue Jan 12 13:02:32 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Tue, 12 Jan 2010 08:02:32 -0500 Subject: Purging known specific document. Message-ID: <4c3149fb1001120502n5a177b0s4398e1b4cf65714b@mail.gmail.com> I looked at the FAQ and searched in Google and hadn't found a suitable example of how to purge a single known document sitting in Varnish cache. Say I have this document sitting in Varnish: images.pubcrawler.com/art/2.png tried: purge.url images.pubcrawler.com/art/2.png Get: 200 0 Assuming 200 means completed and 0 is number purged? Can't get the single item like this to purge. I can get it to purge by doing: purge.url ^/art/2.png BUT! I don't want to do that because another site behind Varnish might have the same path and potentially file... I want to purge the exact item. Thanks again.... From pubcrawler.com at gmail.com Tue Jan 12 16:07:36 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Tue, 12 Jan 2010 11:07:36 -0500 Subject: Vanish with Opera Message-ID: <4c3149fb1001120807l532747e3wbf616cd5dbee595b@mail.gmail.com> Was testing something today in Opera browser (latest) under Ubuntu 9.10. Requests go through Varnish to our cluster - thus the relativity. I can't figure this one out. If I load a page in Opera like: http://www.pubcrawler.com/Template/events.cfm It loads fine. If I hit CTRL-R or reload icon I get: Error 200 OK OK Guru Meditation: XID: 1003261083 If I hit CTRL-R or reload a second time I get: Error 503 Service Unavailable Service Unavailable Guru Meditation: XID: 1003261718 Is there something anyone can thing of that would cause this behavior? Thanks! From rtshilston at gmail.com Tue Jan 12 16:10:07 2010 From: rtshilston at gmail.com (Rob S) Date: Tue, 12 Jan 2010 16:10:07 +0000 Subject: Vanish with Opera In-Reply-To: <4c3149fb1001120807l532747e3wbf616cd5dbee595b@mail.gmail.com> References: <4c3149fb1001120807l532747e3wbf616cd5dbee595b@mail.gmail.com> Message-ID: <4B4C9EDF.9090800@gmail.com> pub crawler wrote: > Is there something anyone can thing of that would cause this behavior? Can you send a packet trace and/or the output of varnishlog for that specific XID? Rob From frank at vanlingen.name Tue Jan 12 19:51:16 2010 From: frank at vanlingen.name (Frank van Lingen) Date: Tue, 12 Jan 2010 20:51:16 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? can ping response time be configure? Message-ID: <458a97201001121151x2d22b646t1d39b743b61dc18@mail.gmail.com> I downloaded and compiled the latest version 2.0.6 I started varnish with just 40 threads: -p thread_pool_max=40 I then start it with: varnishd -a :80 -s malloc,40M -p thread_pool_min=5 -p thread_pool_max=40 -T localhost:6082 -f /etc/varnish/default.vcl Using malloc makes things worse and I have more restarts so I switched back to file: varnishd -a :80 -p thread_pool_min=5 -p thread_pool_max=40 -T localhost:6082 -f /etc/varnish/default.vcl -s file,/var/cache/varnish.cache,40M Everything works fine (the restart is graceful), but it is still restarting (see below). I installed it on a non virtualized box and have no problems with it. I suspect that it might have something to do with the resources allocated to the VM. Is there a way to configure the number of times it pings before restart? Jan 12 06:15:20 server1 varnishd[1573]: Child (3576) said Ready Jan 12 08:45:47 server1 varnishd[1573]: Child (3576) not responding to ping, killing it. Jan 12 08:45:47 server1 varnishd[1573]: Child (3576) not responding to ping, killing it. Jan 12 08:45:47 server1 varnishd[1573]: Child (3576) died signal=3 Jan 12 08:45:47 server1 varnishd[1573]: child (7996) Started Jan 12 08:45:47 server1 varnishd[1573]: Child (7996) said Closed fds: 4 5 9 10 12 13 Jan 12 08:45:47 server1 varnishd[1573]: Child (7996) said Child starts Jan 12 08:45:47 server1 varnishd[1573]: Child (7996) said managed to mmap 41943040 bytes of 41943040 Jan 12 08:45:47 server1 varnishd[1573]: Child (7996) said Ready On Mon, Jan 11, 2010 at 12:38 PM, Frank van Lingen wrote: > From the varnish documentation I see that the threadpool max has a > default of 1000 as I am doing some test on a (smal) VPS I reduced this > number to 40 just to see if this might cause the problem. > > Frank. > > > On Mon, Jan 11, 2010 at 12:22 PM, Frank van Lingen wrote: >> Below the last messages. These are two restarts within the hour, but >> most of the times it seems to run for several hours 4-8 without >> problems. ?I could not find any panic messages. I found some messages >> in the varnish mailing list regarding this but the only ones I found >> where 'died signal=6' >> >> JJan 10 18:17:22 server1 varnishd[14016]: Child (23771) not responding >> to ping, killing it. >> Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) not responding >> to ping, killing it. >> Jan 10 18:17:23 server1 varnishd[14016]: Child (23771) died signal=3 >> Jan 10 18:17:23 server1 varnishd[14016]: child (25855) Started >> Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Closed >> fds: 4 5 9 10 12 13 >> Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Child starts >> Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said managed to >> mmap 41943040 bytes of 41943040 >> Jan 10 18:17:23 server1 varnishd[14016]: Child (25855) said Ready >> Jan 10 18:49:43 server1 varnishd[14016]: Child (25855) not responding >> to ping, killing it. >> Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) not responding >> to ping, killing it. >> Jan 10 18:49:44 server1 varnishd[14016]: Child (25855) died signal=3 >> Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started >> Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Closed fds: >> 4 5 9 10 12 13 >> Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Child starts >> Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said managed to >> mmap 41943040 bytes of 41943040 >> Jan 10 18:49:44 server1 varnishd[14016]: Child (5186) said Ready >> Jan 10 20:13:43 server1 varnishd[14016]: Child (5186) not responding >> to ping, killing it. >> Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) not responding >> to ping, killing it. >> Jan 10 20:13:44 server1 varnishd[14016]: Child (5186) died signal=3 >> Jan 10 20:13:44 server1 varnishd[14016]: child (13400) Started >> Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Closed >> fds: 4 5 9 10 12 13 >> Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Child starts >> Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said managed to >> mmap 41943040 bytes of 41943040 >> Jan 10 20:13:44 server1 varnishd[14016]: Child (13400) said Ready >> >> Jan 10 18:49:44 server1 varnishd[14016]: child (5186) Started >> >> -------------------------------------------- >> Frank van Lingen >> email : frank at vanlingen.name >> VOIP (skype) : fvlingen >> IM (yahoo,hotmail) : fvlingen >> IM (AIM) : frank at vanlingen.name >> URL : http://vanlingen.name >> LinkedIn : fvlingen >> ------------------------------------------- >> >> >> >> On Mon, Jan 11, 2010 at 9:49 AM, Poul-Henning Kamp wrote: >>> In message <458a97201001090528g12f87amfdd974e85f00f288 at mail.gmail.com>, Frank v >>> an Lingen writes: >>> >>>>But I notice that once every so often the cache seems to either flush >>>>itself or restart. During this 2-3 seconds that this happens I can not >>>>load any pages. >>> >>> Check your syslog for panic messages from varnish, this should not >>> happen in regular use. >>> >>> -- >>> 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 john at 7fff.com Tue Jan 12 20:26:47 2010 From: john at 7fff.com (John Norman) Date: Tue, 12 Jan 2010 15:26:47 -0500 Subject: "trunk" in grace docs? Message-ID: At this page: http://varnish.projects.linpro.no/wiki/VCLExampleGrace What does the comment "# or for trunk" mean? And what is the difference between setting grace on obj and on beresp? (It would be helpful were both of these questions address in the doc.) John From john at 7fff.com Tue Jan 12 20:57:57 2010 From: john at 7fff.com (John Norman) Date: Tue, 12 Jan 2010 15:57:57 -0500 Subject: "trunk" in grace docs? In-Reply-To: References: Message-ID: Trunk of the the repo? On Tue, Jan 12, 2010 at 3:26 PM, John Norman wrote: > At this page: http://varnish.projects.linpro.no/wiki/VCLExampleGrace > > What does the comment "# or for trunk" mean? > > And what is the difference between setting grace on obj and on beresp? > > (It would be helpful were both of these questions address in the doc.) > > John > From john at 7fff.com Tue Jan 12 22:00:21 2010 From: john at 7fff.com (John Norman) Date: Tue, 12 Jan 2010 17:00:21 -0500 Subject: grace scenario - app side and varnish Message-ID: Folks, I'm having a dickens of a time triggering "grace" mode. Varnish version 2.0.6. I am using a director. On my app server, the expiration is set to, e.g., Cache-Control: max-age=10, public I would like to set "grace" in Varnish so that this stays in the cache for some long amount of time, and then when I hit the site, I get stale content (no wait), and the backend gets triggered to refresh the cache. It would seem that all I should have to do is set req.grace = 1m; at the top of vcl_recv (or for sections that go to "lookup"), and in vcl_fetch, set obj.grace = 1m. Then in the period between +10 seconds and 1m, I should see that behavior -- getting stale data, but seeing Varnish go to my backend app server to get new content? John From ross at trademe.co.nz Tue Jan 12 23:51:57 2010 From: ross at trademe.co.nz (Ross Brown) Date: Wed, 13 Jan 2010 12:51:57 +1300 Subject: "trunk" in grace docs? In-Reply-To: References: Message-ID: <1FF67D7369ED1A45832180C7C1109BCA13E23E6F64@tmmail0.trademe.local> Syntax has changed from obj.grace to beresp.grace, if you are using a recent build. See http://varnish.projects.linpro.no/changeset/4224 Ross -----Original Message----- From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of John Norman Sent: Wednesday, 13 January 2010 9:27 a.m. To: varnish-misc at projects.linpro.no Subject: "trunk" in grace docs? At this page: http://varnish.projects.linpro.no/wiki/VCLExampleGrace What does the comment "# or for trunk" mean? And what is the difference between setting grace on obj and on beresp? (It would be helpful were both of these questions address in the doc.) John _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From john at 7fff.com Wed Jan 13 03:24:28 2010 From: john at 7fff.com (John Norman) Date: Tue, 12 Jan 2010 22:24:28 -0500 Subject: "trunk" in grace docs? In-Reply-To: <1FF67D7369ED1A45832180C7C1109BCA13E23E6F64@tmmail0.trademe.local> References: <1FF67D7369ED1A45832180C7C1109BCA13E23E6F64@tmmail0.trademe.local> Message-ID: Thanks! On Tue, Jan 12, 2010 at 6:51 PM, Ross Brown wrote: > Syntax has changed from obj.grace to beresp.grace, if you are using a recent build. > > See http://varnish.projects.linpro.no/changeset/4224 > > Ross > > > -----Original Message----- > From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of John Norman > Sent: Wednesday, 13 January 2010 9:27 a.m. > To: varnish-misc at projects.linpro.no > Subject: "trunk" in grace docs? > > At this page: http://varnish.projects.linpro.no/wiki/VCLExampleGrace > > What does the comment "# or for trunk" mean? > > And what is the difference between setting grace on obj and on beresp? > > (It would be helpful were both of these questions address in the doc.) > > John > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From tfheen at redpill-linpro.com Wed Jan 13 11:02:54 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 13 Jan 2010 12:02:54 +0100 Subject: Purging known specific document. In-Reply-To: <4c3149fb1001120502n5a177b0s4398e1b4cf65714b@mail.gmail.com> (pub crawler's message of "Tue, 12 Jan 2010 08:02:32 -0500") References: <4c3149fb1001120502n5a177b0s4398e1b4cf65714b@mail.gmail.com> Message-ID: <87skaajmht.fsf@qurzaw.linpro.no> ]] pub crawler | tried: | purge.url images.pubcrawler.com/art/2.png | | Get: | 200 0 | | Assuming 200 means completed and 0 is number purged? No. 200 means ok, 0 means ?no bytes in reply? You probably want to do purge req.url == /art/2.png && req.http.host == images.pubcrawler.com http://varnish.projects.linpro.no/wiki/Purging talks a bit more about it. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 13 11:04:15 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 13 Jan 2010 12:04:15 +0100 Subject: varnish suddenly restarting / flushing itself after several hours? can ping response time be configure? In-Reply-To: <458a97201001121151x2d22b646t1d39b743b61dc18@mail.gmail.com> (Frank van Lingen's message of "Tue, 12 Jan 2010 20:51:16 +0100") References: <458a97201001121151x2d22b646t1d39b743b61dc18@mail.gmail.com> Message-ID: <87ockyjmfk.fsf@qurzaw.linpro.no> ]] Frank van Lingen | Everything works fine (the restart is graceful), but it is still | restarting (see below). I installed it on a non virtualized box and | have no problems with it. I suspect that it might have something to do | with the resources allocated to the VM. | | Is there a way to configure the number of times it pings before restart? Increase the cli_timeout parameter by passing -p cli_timeout=$number to varnishd. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 13 11:15:20 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 13 Jan 2010 12:15:20 +0100 Subject: grace scenario - app side and varnish In-Reply-To: (John Norman's message of "Tue, 12 Jan 2010 17:00:21 -0500") References: Message-ID: <87k4vmjlx3.fsf@qurzaw.linpro.no> ]] John Norman | I would like to set "grace" in Varnish so that this stays in the cache | for some long amount of time, and then when I hit the site, I get | stale content (no wait), and the backend gets triggered to refresh the | cache. grace works by serving old content to any clients which would otherwise be put on a wait list. It does not prefect or fetch asynchronously. So with grace, the first client has to wait, and any subsequent ones just get the graced content. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From ahooper at bmjgroup.com Wed Jan 13 11:24:07 2010 From: ahooper at bmjgroup.com (Alex Hooper) Date: Wed, 13 Jan 2010 11:24:07 +0000 Subject: varnishlog not behaving as expected (by me) Message-ID: <4B4DAD57.2050609@bmjgroup.com> Hi, I'm having a bit of trouble using varnishlog. I am using: /usr/local/bin/varnishlog -o RxURL "^wp-admin$" Expecting to see grouped log lines for requests where the RxURL matches /^wp-admin$. But the (copious) output I see is like: 0 StatAddr - 59.181.130.123 0 6 1 3 0 0 0 1003 8711 0 StatAddr - 120.28.216.236 0 1 6 11 0 0 0 3864 92763 0 StatAddr - 80.13.50.156 0 754 22 40 0 0 0 7080 0 0 StatAddr - 86.156.98.226 0 0 2 4 0 0 0 1397 9259 0 ExpPick - 1023444941 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444941 -1263381538 0 ExpPick - 1023444953 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023444953 -1263381538 0 ExpPick - 1023108126 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1023108126 -10 0 ExpPick - 1023109753 prefetch 0 VCL_call - prefetch 0 VCL_return - fetch 0 Debug - "Attempt Prefetch 1023109753" 0 StatAddr - 86.156.98.226 0 0 3 5 0 0 0 1750 22988 0 StatAddr - 193.146.115.134 0 12 4 4 0 0 0 708 0 0 StatAddr - 86.156.98.226 0 0 4 6 0 0 0 2103 36115 0 StatAddr - 80.13.50.156 0 754 22 41 0 0 0 7257 0 0 StatAddr - 80.13.50.156 0 754 23 42 0 0 0 7434 0 '/usr/local/bin/varnishlog' -i RxURL shows me the requests coming in. '/usr/local/bin/varnishlog -i RxURL|grep wp-admin' shows that there are generally no requests for wp-admin. Am I missing something obvious? (varnish-2.0.4 on RHEL 5.4) Cheers, Alex. -- Alex Hooper | www.bmjpg.com Operations Team Leader | ahooper at bmjgroup.com BMJ Technology, BMJ Publishing Group | +44 20 7383 6049 BMA House, LONDON, WC1H 9JR | _______________________________________________________________________ The BMJ Group is one of the world's most trusted providers of medical information for doctors, researchers, health care workers and patients www.bmjgroup.bmj.com. This email and any attachments are confidential. If you have received this email in error, please delete it and kindly notify us. If the email contains personal views then the BMJ Group accepts no responsibility for these statements. The recipient should check this email and attachments for viruses because the BMJ Group accepts no liability for any damage caused by viruses. Emails sent or received by the BMJ Group may be monitored for size, traffic, distribution and content. BMJ Publishing Group Limited trading as BMJ Group. A private limited company, registered in England and Wales under registration number 03102371. Registered office: BMA House, Tavistock Square, London WC1H 9JR, UK. _______________________________________________________________________ From john at 7fff.com Wed Jan 13 12:38:14 2010 From: john at 7fff.com (John Norman) Date: Wed, 13 Jan 2010 07:38:14 -0500 Subject: grace scenario - app side and varnish In-Reply-To: <87k4vmjlx3.fsf@qurzaw.linpro.no> References: <87k4vmjlx3.fsf@qurzaw.linpro.no> Message-ID: Thanks. An explicit statement of this in the docs would be helpful. On Wed, Jan 13, 2010 at 6:15 AM, Tollef Fog Heen wrote: > ]] John Norman > > | I would like to set "grace" in Varnish so that this stays in the cache > | for some long amount of time, and then when I hit the site, I get > | stale content (no wait), and the backend gets triggered to refresh the > | cache. > > grace works by serving old content to any clients which would otherwise > be put on a wait list. ?It does not prefect or fetch asynchronously. ?So > with grace, the first client has to wait, and any subsequent ones just > get the graced content. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From kristian at redpill-linpro.com Wed Jan 13 14:41:11 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Wed, 13 Jan 2010 15:41:11 +0100 Subject: Strange 302 redirect to google.com In-Reply-To: <41fe27a21001110357m3ac09688vdc4269bb16147715@mail.gmail.com> References: <41fe27a21001110357m3ac09688vdc4269bb16147715@mail.gmail.com> Message-ID: <20100113144110.GA12429@kjeks.linpro.no> On Mon, Jan 11, 2010 at 01:57:27PM +0200, Maurice wrote: > i have a problem with a strange 302 redirect to google.(com|ro) just by > visiting http://dir.acasa.ro on google chrome and ie, on firefox > everything works fine. the strange part is that on certain ips (not > listed in the vcl so nothing fancy) the page works on all browsers. is it > possible that varnish caches the 302 redirects and on a "get index" > request and spits out 302? but why redirect to google? I just had a look at this issue and can't reproduce it, nor do I see any good reason for why it would happen based on what you provide. Varnish can/does cache 302s, but that wouldn't explain why they are there in the first place. The varnishlog you provide does have any Location: header that links to Google, and after running through the list, none of those sites refer to Google either. And I can promise you that Varnish does not have any ties to Google out of the box. How consistently does this happen? What other systems are involved (loadbalancers,etc)? What sort of pattern do you see when it does happen? If you can reproduce it, seeing output from GET/HEAD and/or firebug might help reveal the underlying issue too. -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From bernard at frit.net Wed Jan 13 16:39:43 2010 From: bernard at frit.net (Bernardf FRIT) Date: Wed, 13 Jan 2010 17:39:43 +0100 Subject: Strange different behavior Message-ID: <4B4DF74F.50504@frit.net> Hi, I'm facing a pretty strange issue. URLs not supposed to be cached are in cache when requested by firefox but not by lwp. I'm suspecting cookie management... but I don't realy know how to avoid caching these URLs. Any help would be apreciated. URL like XX.html are XXX.php rewrited. In vcl I have : if (req.request == "GET" && req.url ~ "\.(html|php)") { pass; } And when requesting pages : 1. Under Linux/GET # GET -m HEAD _*http://XXXXXXXXXXX/annonces-immobilier/appartement-roanne/11.html*_ 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close _*Date: Wed, 16 Dec 2009 07:26:46 GMT*_ Pragma: no-cache Via: 1.1 varnish Age: 0 Server: Apache-NSCA Vary: Accept-Encoding,User-Agent Content-Type: text/html Expires: Thu, 19 Nov 1981 08:52:00 GMT Client-Date: Wed, 16 Dec 2009 07:26:20 GMT Client-Response-Num: 1 Set-Cookie: PHPSESSID=36e4f91a2e8ae9b1aa00d819c06e03a8; path=/ Set-Cookie: DYNSRV=s0; path=/ _*X-Cache: MISS*_ X-Served-By: Server 203 X-Varnish: 1411446250 2. Under Windows/Firefox Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Type: text/html Content-Length: 11758 X-Cacheable: YES _*Date: Wed, 16 Dec 2009 07:30:21 GMT*_ X-Varnish: 1411446251 1411446175 Age: 570 Via: 1.1 varnish Connection: keep-alive X-Served-By: Server 203 _*X-Cache: HIT*_ X-Cache-Hits: 1 Server: Apache-NSCA 3. Under Linux/GET # GET -m HEAD _*http://XXXXXXXXXXX/annonces-immobilier/appartement-roanne/11.html*_ 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close _*Date: Wed, 16 Dec 2009 07:31:34 GMT*_ Pragma: no-cache Via: 1.1 varnish Age: 0 Server: Apache-NSCA Vary: Accept-Encoding,User-Agent Content-Type: text/html Expires: Thu, 19 Nov 1981 08:52:00 GMT Client-Date: Wed, 16 Dec 2009 07:31:08 GMT Client-Response-Num: 1 Set-Cookie: PHPSESSID=fd043b9a9207d7137f79777970a54735; path=/ Set-Cookie: DYNSRV=s0; path=/ _*X-Cache: MISS*_ X-Served-By: Server 203 Regards -- Bernard FRIT From bernard at frit.net Wed Jan 13 17:45:26 2010 From: bernard at frit.net (Bernardf FRIT) Date: Wed, 13 Jan 2010 18:45:26 +0100 Subject: Strange different behavior Message-ID: <4B4E06B6.2080103@frit.net> Hi, I'm facing a pretty strange issue. URLs not supposed to be cached are in cache when requested by firefox but not by lwp. I'm suspecting cookie management... but I don't realy know how to avoid caching these URLs. Any help would be apreciated. URL like XX.html are XXX.php rewrited. In vcl I have : if (req.request == "GET" && req.url ~ "\.(html|php)") { pass; } And when requesting pages : 1. Under Linux/GET # GET -m HEAD _*http://XXXXXXXXXXX/annonces-immobilier/appartement-roanne/11.html*_ 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close _*Date: Wed, 16 Dec 2009 07:26:46 GMT*_ Pragma: no-cache Via: 1.1 varnish Age: 0 Server: Apache-NSCA Vary: Accept-Encoding,User-Agent Content-Type: text/html Expires: Thu, 19 Nov 1981 08:52:00 GMT Client-Date: Wed, 16 Dec 2009 07:26:20 GMT Client-Response-Num: 1 Set-Cookie: PHPSESSID=36e4f91a2e8ae9b1aa00d819c06e03a8; path=/ Set-Cookie: DYNSRV=s0; path=/ _*X-Cache: MISS*_ X-Served-By: Server 203 X-Varnish: 1411446250 2. Under Windows/Firefox Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding,User-Agent Content-Encoding: gzip Content-Type: text/html Content-Length: 11758 X-Cacheable: YES _*Date: Wed, 16 Dec 2009 07:30:21 GMT*_ X-Varnish: 1411446251 1411446175 Age: 570 Via: 1.1 varnish Connection: keep-alive X-Served-By: Server 203 _*X-Cache: HIT*_ X-Cache-Hits: 1 Server: Apache-NSCA 3. Under Linux/GET # GET -m HEAD _*http://XXXXXXXXXXX/annonces-immobilier/appartement-roanne/11.html*_ 200 OK Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close _*Date: Wed, 16 Dec 2009 07:31:34 GMT*_ Pragma: no-cache Via: 1.1 varnish Age: 0 Server: Apache-NSCA Vary: Accept-Encoding,User-Agent Content-Type: text/html Expires: Thu, 19 Nov 1981 08:52:00 GMT Client-Date: Wed, 16 Dec 2009 07:31:08 GMT Client-Response-Num: 1 Set-Cookie: PHPSESSID=fd043b9a9207d7137f79777970a54735; path=/ Set-Cookie: DYNSRV=s0; path=/ _*X-Cache: MISS*_ X-Served-By: Server 203 Regards -- Bernard FRIT From bernard at frit.net Wed Jan 13 17:55:00 2010 From: bernard at frit.net (Bernardf FRIT) Date: Wed, 13 Jan 2010 18:55:00 +0100 Subject: Strange different behavior In-Reply-To: <4B4E06B6.2080103@frit.net> References: <4B4E06B6.2080103@frit.net> Message-ID: <4B4E08F4.1020304@frit.net> Ooouups, sorry for the double... -- BF From john at 7fff.com Thu Jan 14 21:06:20 2010 From: john at 7fff.com (John Norman) Date: Thu, 14 Jan 2010 16:06:20 -0500 Subject: Does a Varnish restart clear the existing cache? Message-ID: I think the answer is "no," but . . . Does a Varnish restart clear the existing cache? (using the "file" storage.) From phk at phk.freebsd.dk Thu Jan 14 21:35:35 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 14 Jan 2010 21:35:35 +0000 Subject: Does a Varnish restart clear the existing cache? In-Reply-To: Your message of "Thu, 14 Jan 2010 16:06:20 EST." Message-ID: <14981.1263504935@critter.freebsd.dk> In message , John N orman writes: >I think the answer is "no," but . . . > > Does a Varnish restart clear the existing cache? > >(using the "file" storage.) Actually it does, we are working on the "persistent" storage module. -- 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 kristian at redpill-linpro.com Thu Jan 14 21:50:25 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Thu, 14 Jan 2010 22:50:25 +0100 Subject: Strange different behavior In-Reply-To: <4B4E06B6.2080103@frit.net> References: <4B4E06B6.2080103@frit.net> Message-ID: <20100114215025.GB9573@kjeks.kristian.int> On Wed, Jan 13, 2010 at 06:45:26PM +0100, Bernardf FRIT wrote: > Hi, > > I'm facing a pretty strange issue. URLs not supposed to be cached are in > cache when > requested by firefox but not by lwp. (...) > Vary: Accept-Encoding,User-Agent This is why. Vary: means "this page will look different depending on the following client headers". Your backend is telling Varnish to expect different variants of the page depending on what Accept-Encoding AND User-Agent header the client provides. Accept-Encoding is normal and sane (ie: if one client supports gzip and an other does not, one client will get a compressed variant of the page and the other client the uncompressed one). Vary on User-Agent is generally bad, and you should Just Fix That [tm]. Due to Vary: Accept-Encoding, lwp-request and Firefox will still get different variants, but you can supply the Accept-Encoding header to lwp-request, but if you want the content, you'll need to pipe it through gunzip (headers are still readable). -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From phk at phk.freebsd.dk Fri Jan 15 09:19:01 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 09:19:01 +0000 Subject: Strange different behavior In-Reply-To: Your message of "Thu, 14 Jan 2010 22:50:25 +0100." <20100114215025.GB9573@kjeks.kristian.int> Message-ID: <29801.1263547141@critter.freebsd.dk> In message <20100114215025.GB9573 at kjeks.kristian.int>, Kristian Lyngstol writes : >Vary on User-Agent is generally bad, and you should Just Fix That [tm]. Apart from the compatibility issue, a secondary reason it is a bad idea, is that User-Agent is practically unique for every single PC in the world, so you will cache up to hundreds of copies of the pages for no good reason. If your site is running live on Varnish, try running: varnishtop -i rxheader -I User-Agent and see how many different strings your clients send you... In all likelyhood, your backend looks at only one or two of the bits in User-Agent (MSIE or Mozilla ?) but Varnish has to look at the entire string, since it has no way of knowing what your backend looks at. One workaround, is to do what we call "User-Agent-Washing", where Varnish rewrites the Useragent to the handfull of different variants your backend really cares about, along the lines of: sub vcl_recv { if (req.http.user-agent ~ "MSIE") { set req.http.user-agent = "MSIE"; } else { set req.http.user-agent = "Mozilla"; } } So that you only cache the relevant number of copies. But as Kristian says: The best thing, is to not Vary on User-Agent in the first place, that's how the InterNet is supposed to work. Poul-Henning -- 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 john at 7fff.com Fri Jan 15 12:49:40 2010 From: john at 7fff.com (John Norman) Date: Fri, 15 Jan 2010 07:49:40 -0500 Subject: Strange different behavior In-Reply-To: <29801.1263547141@critter.freebsd.dk> References: <20100114215025.GB9573@kjeks.kristian.int> <29801.1263547141@critter.freebsd.dk> Message-ID: Sorry to be so obtuse: So with the default setup, there will be a cached copy of a page for every single user agent? If so, does anyone have a good number of user agents that should be supported for calculating the size of the cache? E.g., if I've guessed 64M for my pages, and I imagine that there are 10 user agents (I know it's more) then I'd want to multiply that 64M x 10. On Fri, Jan 15, 2010 at 4:19 AM, Poul-Henning Kamp wrote: > In message <20100114215025.GB9573 at kjeks.kristian.int>, Kristian Lyngstol writes > : > >>Vary on User-Agent is generally bad, and you should Just Fix That [tm]. > > Apart from the compatibility issue, a secondary reason it is a bad > idea, is that User-Agent is practically unique for every single PC > in the world, so you will cache up to hundreds of copies of the pages > for no good reason. > > If your site is running live on Varnish, try running: > > ? ? ? ?varnishtop -i rxheader -I User-Agent > > and see how many different strings your clients send you... > > In all likelyhood, your backend looks at only one or two of the bits > in User-Agent (MSIE or Mozilla ?) but Varnish has to look at the > entire string, since it has no way of knowing what your backend > looks at. > > One workaround, is to do what we call "User-Agent-Washing", where > Varnish rewrites the Useragent to the handfull of different variants > your backend really cares about, along the lines of: > > sub vcl_recv { > ? ? ? ?if (req.http.user-agent ~ "MSIE") { > ? ? ? ? ? ? ? ?set req.http.user-agent = "MSIE"; > ? ? ? ?} else { > ? ? ? ? ? ? ? ?set req.http.user-agent = "Mozilla"; > ? ? ? ?} > } > > So that you only cache the relevant number of copies. > > But as Kristian says: ?The best thing, is to not Vary on User-Agent > in the first place, that's how the InterNet is supposed to work. > > Poul-Henning > > -- > 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. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From phk at phk.freebsd.dk Fri Jan 15 12:52:19 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 12:52:19 +0000 Subject: Strange different behavior In-Reply-To: Your message of "Fri, 15 Jan 2010 07:49:40 EST." Message-ID: <31786.1263559939@critter.freebsd.dk> In message , John Norman writes: >Sorry to be so obtuse: > >So with the default setup, there will be a cached copy of a page for >every single user agent? Yes, unless you do something about the "Vary: User-Agent" header returned from the backend. >If so, does anyone have a good number of user agents that should be >supported for calculating the size of the cache? E.g., if I've guessed >64M for my pages, and I imagine that there are 10 user agents (I know >it's more) then I'd want to multiply that 64M x 10. You really need to find out what bit of user-agent your backend cares about. We are talking a multiplication factor of 100-1000 here. Poul-Henning -- 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 l at lrowe.co.uk Fri Jan 15 14:34:15 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Fri, 15 Jan 2010 14:34:15 +0000 Subject: Purging multiple requests In-Reply-To: References: <75cf5801001110810k61d27215r1e69cee60731ebeb@mail.gmail.com> <46244.1263226547@critter.freebsd.dk> Message-ID: 2010/1/12 John Norman : > Scenario: > > -- We would prefer not to leverage checking a lot of paths. > > -- Many pages are cached for GET's. > > -- In vcl_recv, we want to remove cookies and check the cache: > > if (req.request == "GET") { > ? ? unset req.http.cookie; > ? ? unset req.http.Authorization; > ? ? lookup; > ?} > > BUT: Suppose the lookup results in a MISS: > > Now we would like to "pass" but WITH the cookies. I.e., check the > cache without cookies; but if there's a miss, reattach them and make > the request. > > ---------------------- > > Let me put this another way, describing what's happening in our code: > > There are many routine server responses for which we have set caching > headers. All is beautiful. > > But we have some, primarily of the form > > ? ?/something/edit > > where we would like to use the cookie to bring data into a form. > > To be sure, we could check the file paths . . . > > if (req.request == "GET" && req.url !~ "/edit$") { > ? ? unset req.http.cookie; > ? ? unset req.http.Authorization; > ? ? lookup; > ?} > > but we were wondering if there is a pattern to save the cookies and > then reattach them later (in vcl_miss??), and thus get the "pass" to > the backend with the cookies back on the request. You can still lookup even with the authorization and cookie headers, just make sure you never reach the default vcl_recv by returning lookup from your vcl_recv. The simplest way to do this is just to copy and paste in the default and comment out the offending lines: sub vcl_recv { if (req.request != "GET" && req.request != "HEAD" && req.request != "PUT" && req.request != "POST" && req.request != "TRACE" && req.request != "OPTIONS" && req.request != "DELETE") { /* Non-RFC2616 or CONNECT which is weird. */ return (pipe); } if (req.request != "GET" && req.request != "HEAD") { /* We only deal with GET and HEAD by default */ return (pass); } #if (req.http.Authorization || req.http.Cookie) { # /* Not cacheable by default */ # return (pass); #} return (lookup); } No need to save and restore headers then. Laurence From john at 7fff.com Fri Jan 15 14:46:59 2010 From: john at 7fff.com (John Norman) Date: Fri, 15 Jan 2010 09:46:59 -0500 Subject: Strange different behavior In-Reply-To: <31786.1263559939@critter.freebsd.dk> References: <31786.1263559939@critter.freebsd.dk> Message-ID: OK. But if your application backend really doesn't do anything different for different user agents, then one should probably remove the user-agent? On Fri, Jan 15, 2010 at 7:52 AM, Poul-Henning Kamp wrote: > In message , John > Norman writes: >>Sorry to be so obtuse: >> >>So with the default setup, there will be a cached copy of a page for >>every single user agent? > > Yes, unless you do something about the "Vary: User-Agent" header > returned from the backend. > >>If so, does anyone have a good number of user agents that should be >>supported for calculating the size of the cache? E.g., if I've guessed >>64M for my pages, and I imagine that there are 10 user agents (I know >>it's more) then I'd want to multiply that 64M x 10. > > You really need to find out what bit of user-agent your backend > cares about. ?We are talking a multiplication factor of 100-1000 here. > > Poul-Henning > > -- > 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 rtshilston at gmail.com Fri Jan 15 14:50:28 2010 From: rtshilston at gmail.com (Rob S) Date: Fri, 15 Jan 2010 14:50:28 +0000 Subject: Strange different behavior In-Reply-To: <31786.1263559939@critter.freebsd.dk> References: <31786.1263559939@critter.freebsd.dk> Message-ID: <4B5080B4.5070407@gmail.com> Poul-Henning Kamp wrote: > > You really need to find out what bit of user-agent your backend > cares about. We are talking a multiplication factor of 100-1000 here Very slightly off-topic, but is it possible to vary based on a cookie? I'd rather leave one of our applications to process the user-agent, login credentials etc, than to move that logic into Varnish. Rob From phk at phk.freebsd.dk Fri Jan 15 15:12:19 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 15:12:19 +0000 Subject: Strange different behavior In-Reply-To: Your message of "Fri, 15 Jan 2010 14:50:28 GMT." <4B5080B4.5070407@gmail.com> Message-ID: <11057.1263568339@critter.freebsd.dk> In message <4B5080B4.5070407 at gmail.com>, Rob S writes: >Poul-Henning Kamp wrote: >> >> You really need to find out what bit of user-agent your backend >> cares about. We are talking a multiplication factor of 100-1000 here >Very slightly off-topic, but is it possible to vary based on a cookie? >I'd rather leave one of our applications to process the user-agent, >login credentials etc, than to move that logic into Varnish. I belive so, but the result will probably be that it varies on all your cookies... -- 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 phk at phk.freebsd.dk Fri Jan 15 15:13:09 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 15:13:09 +0000 Subject: Strange different behavior In-Reply-To: Your message of "Fri, 15 Jan 2010 09:46:59 EST." Message-ID: <11442.1263568389@critter.freebsd.dk> In message , John Norman writes: >OK. > >But if your application backend really doesn't do anything different >for different user agents, then one should probably remove the >user-agent? yes, by all means do so. -- 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 rtshilston at gmail.com Fri Jan 15 15:14:11 2010 From: rtshilston at gmail.com (Rob S) Date: Fri, 15 Jan 2010 15:14:11 +0000 Subject: Strange different behavior In-Reply-To: <11057.1263568339@critter.freebsd.dk> References: <11057.1263568339@critter.freebsd.dk> Message-ID: <4B508643.6020501@gmail.com> Poul-Henning Kamp wrote: > In message <4B5080B4.5070407 at gmail.com>, Rob S writes: > >> Poul-Henning Kamp wrote: >> >>> You really need to find out what bit of user-agent your backend >>> cares about. We are talking a multiplication factor of 100-1000 here >>> >> Very slightly off-topic, but is it possible to vary based on a cookie? >> I'd rather leave one of our applications to process the user-agent, >> login credentials etc, than to move that logic into Varnish. >> > > I belive so, but the result will probably be that it varies on all your > cookies... > In the 2010 road map, with the ability to extract particular cookies, do you reckon we could do anything to make this work? So, we'd set a cookie called "RenderType", and then Varnish would key on that cookie value? In the short term, can we set the hash to be a combination of a cookie value and host and URL? Rob From phk at phk.freebsd.dk Fri Jan 15 15:17:54 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 15:17:54 +0000 Subject: Strange different behavior In-Reply-To: Your message of "Fri, 15 Jan 2010 15:14:11 GMT." <4B508643.6020501@gmail.com> Message-ID: <13418.1263568674@critter.freebsd.dk> In message <4B508643.6020501 at gmail.com>, Rob S writes: >> I belive so, but the result will probably be that it varies on all your >> cookies... >> >In the 2010 road map, with the ability to extract particular cookies, do >you reckon we could do anything to make this work? So, we'd set a >cookie called "RenderType", and then Varnish would key on that cookie >value? In the short term, can we set the hash to be a combination of a >cookie value and host and URL? Well, there are two mechanisms available: Vary and vcl_hash. Vary: is the RFC2616 sanctioned way, and some backends understand how to use it. It is not cookie-cognizant. vcl_hash: This is Varnish forte: You get to decide what you consider the identifying properties of an "object", and you could, add any property you want, a cookie, client.ip, req.http.authentication etc. The VCL syntax for accessing cookies is getting closer, among other things it depends on being able to dynamically allocate space in the session for HTTP headers (please test this in -trunk :-) Poul-Henning -- 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 john at 7fff.com Fri Jan 15 15:47:12 2010 From: john at 7fff.com (John Norman) Date: Fri, 15 Jan 2010 10:47:12 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? Message-ID: Folks, A couple more questions: (1) Are they any good strategies for splitting load across Varnish front-ends? Or is the common practice to have just one Varnish server? (2) How do people avoid single-point-of-failure for Varnish? Do people run Varnish on two servers, amassing similar local caches, but put something in front of the two Varnishes? Or round-robin-DNS? John From l at lrowe.co.uk Fri Jan 15 15:49:13 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Fri, 15 Jan 2010 15:49:13 +0000 Subject: Strange different behavior In-Reply-To: <4B5080B4.5070407@gmail.com> References: <31786.1263559939@critter.freebsd.dk> <4B5080B4.5070407@gmail.com> Message-ID: 2010/1/15 Rob S : > Poul-Henning Kamp wrote: >> >> You really need to find out what bit of user-agent your backend >> cares about. ?We are talking a multiplication factor of 100-1000 here > Very slightly off-topic, but is it possible to vary based on a cookie? > I'd rather leave one of our applications to process the user-agent, > login credentials etc, than to move that logic into Varnish. You can do this by extracting the value of a cookie into its own header, then vary on that. e.g: sub vcl_recv { ... # We only care about the language in the I18N_LANGUAGE cookie if (req.http.Cookie ~ "(^|.*; )I18N_LANGUAGE=") { set req.http.Accept-Language = regsub(req.http.Cookie, "(^|.*; )I18N_LANGUAGE=([^;]*)(; .*|$)", "\2"); # XXX need to work out the proper way to match " here, e.g. "en" set req.http.Accept-Language = regsub(req.http.Accept-Language, "^.(.*).$", "\1"); } else { set req.http.Accept-Language = "en"; } ... } Laurence From rtshilston at gmail.com Fri Jan 15 15:49:31 2010 From: rtshilston at gmail.com (Rob S) Date: Fri, 15 Jan 2010 15:49:31 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: Message-ID: <4B508E8B.7030906@gmail.com> John Norman wrote: > Folks, > > A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? > > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? > We're running with two instances and round-robin DNS. The varnish servers are massively underused, and splitting the traffic also means we get half the hit rate. But it avoids the SPOF. Is anyone running LVS or similar in front of Varnish and can share their experience? Rob From se at 5mm.de Fri Jan 15 16:07:59 2010 From: se at 5mm.de (Simon Effenberg) Date: Fri, 15 Jan 2010 17:07:59 +0100 Subject: sess_timeout not working in 2.0.6? Message-ID: <20100115170759.9fb65144.se@5mm.de> I have a question about v2.0.6: after upgrading from 2.0.3 the sess_timeout first appear in the varnishlog after a minimum of 1 character was sent to varnish. so a client connection seems to never timedout (maybe sometime but not in the first 10 minutes). with 2.0.3 this wasn't any problem (the sess_timeout was and is set to 5s). Is there anything which was changed between 2.0.3 and 2.0.6 which can cause this issue? Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bheltne at gmail.com Fri Jan 15 18:09:55 2010 From: bheltne at gmail.com (Bendik Heltne) Date: Fri, 15 Jan 2010 19:09:55 +0100 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: Message-ID: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> > A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? We have 3 servers. A bit overkill, but then we have redundancy even if one fail. I guess 2 is the minimum option if you have an important site and 99,5% uptime guarantee. > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? We use a loadbalancer from F5 called BigIP. It's no exactly free, but there are free alternatives that will probably do much of the basic stuff: http://lcic.org/load_balancing.html - Bendik From rodrigo at mercadolibre.com Fri Jan 15 18:11:13 2010 From: rodrigo at mercadolibre.com (Rodrigo Benzaquen) Date: Fri, 15 Jan 2010 15:11:13 -0300 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> References: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> Message-ID: HA PROXY is open spurce and works pretty well. Also you can do load balance based on HAS URL if you want. On Fri, Jan 15, 2010 at 3:09 PM, Bendik Heltne wrote: > > A couple more questions: > > > > (1) Are they any good strategies for splitting load across Varnish > > front-ends? Or is the common practice to have just one Varnish server? > > We have 3 servers. A bit overkill, but then we have redundancy even if > one fail. I guess 2 is the minimum option if you have an important > site and 99,5% uptime guarantee. > > > (2) How do people avoid single-point-of-failure for Varnish? Do people > > run Varnish on two servers, amassing similar local caches, but put > > something in front of the two Varnishes? Or round-robin-DNS? > > We use a loadbalancer from F5 called BigIP. It's no exactly free, but > there are free alternatives that will probably do much of the basic > stuff: > http://lcic.org/load_balancing.html > > - Bendik > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at 7fff.com Fri Jan 15 21:16:44 2010 From: john at 7fff.com (John Norman) Date: Fri, 15 Jan 2010 16:16:44 -0500 Subject: Another question - after clearing cache (or restart), avoiding killing the backend? Message-ID: Thanks for the various answers! Since the cache is cleared after a restart, how do people avoid slamming their backends as the cache is refilled? (I know once answer is: Don't restart. But let's say that Varnish crashes, or there are other issues.) John From david.birdsong at gmail.com Fri Jan 15 21:19:33 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Fri, 15 Jan 2010 13:19:33 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 10:11 AM, Rodrigo Benzaquen wrote: > HA PROXY is open spurce and works pretty well. Also you can do load balance > based on HAS URL if you want. aye, the development is pretty active also. i asked for a consistent hash option in haproxy and got one in less than 2 weeks -only available in the dev version for now. > > > On Fri, Jan 15, 2010 at 3:09 PM, Bendik Heltne wrote: >> >> > A couple more questions: >> > >> > (1) Are they any good strategies for splitting load across Varnish >> > front-ends? Or is the common practice to have just one Varnish server? >> >> We have 3 servers. A bit overkill, but then we have redundancy even if >> one fail. I guess 2 is the minimum option if you have an important >> site and 99,5% uptime guarantee. >> >> > (2) How do people avoid single-point-of-failure for Varnish? Do people >> > run Varnish on two servers, amassing similar local caches, but put >> > something in front of the two Varnishes? Or round-robin-DNS? >> >> We use a loadbalancer from F5 called BigIP. It's no exactly free, but >> there are free alternatives that will probably do much of the basic >> stuff: >> http://lcic.org/load_balancing.html >> >> - Bendik >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > From david.birdsong at gmail.com Fri Jan 15 21:24:17 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Fri, 15 Jan 2010 13:24:17 -0800 Subject: tool for dumping contents of cache Message-ID: I know this would be a huge performance problem, but I'd really like a tool that could examine the storage file(s) of a running varnish instance that could dump out url's and hit counts. I'd load balance traffic away from varnish while doing this, so it would be ok for this tool to pummel the drives, suck up ram, and dominate cpu. Would it be possible to write? I'd be willing to pay. From michael at dynamine.net Fri Jan 15 21:38:27 2010 From: michael at dynamine.net (Michael Fischer) Date: Fri, 15 Jan 2010 13:38:27 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 1:19 PM, David Birdsong wrote: > On Fri, Jan 15, 2010 at 10:11 AM, Rodrigo Benzaquen > wrote: > > HA PROXY is open spurce and works pretty well. Also you can do load > balance > > based on HAS URL if you want. > > aye, the development is pretty active also. i asked for a consistent > hash option in haproxy and got one in less than 2 weeks -only > available in the dev version for now. Awesome! Now if we could just get one in Varnish :-) --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb+varnish at slide.com Fri Jan 15 21:49:40 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Fri, 15 Jan 2010 13:49:40 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> Message-ID: <1567ACB3-AB6A-4B5C-82E1-A2A9762FF2D1@slide.com> Lots of good suggestions; I would look to LVS and/or haproxy for going on the cheap; otherwise a NetScaler or F5 would do the trick. With multiple caches, there are three ways I see to handle it: 1) Duplicate cached data on all Varnish instances. This is a simple, stateless configuration, but it reduces your overall hit rate: 2 servers will halve your miss traffic; 3 servers will triple it, etc.. If your miss rate is low enough that your origin can handle the misses, this is simple, easy to implement, and offers good performance (CPU and link scalability). If you lose a host, you would see essentially no miss rate increase. But it won't scale forever. For servers with 8GB of RAM, the machines will only provide 8GB of RAM overall for caching, whether it's 4 machines or 400. (same applies to disk space) 2) Hash URLs or otherwise bucket incoming requests and send unique traffic to each Varnish instance. This requires some smarts in your load balancer, but this means you can add as many Varnish instances as you want without losing hit rate, and each server's RAM footprint is additive. 8 servers with 8GB of RAM will provide 64GB of RAM overall for caching. But there are caveats: 2a) If you lose a cache server, you will get a 100% miss rate for all objects that used to be directed to that server. This might overwhelm your origin. 2b) If you resize the cache server pool, the hash (or other algorithm) will send different objects to different machines, which will increase misses (possibly catastrophically) and may overwhelm your origin. Some implementations of URL hashing will cause a full rehashing of URLs if a single host even temporarily goes out of service. Additionally, some hash implementations may also reduce the effect of server loss. 3) Hash/bucket URLs to cache pairs. Same as 2), but for every hash bucket you would send those hits to two machines (think RAID-10). This provides redundancy from the effects of 2a), and gives essentially infinite scalability for the price of doubling your miss rate once (two machines per bucket caching the same data). The caveat from 2b) still applies. With the right hash/bucket algorithm, 3) is probably the best choice. But they all have drawbacks. I'd love to hear other ideas too. Hope it helps, -- kb John Norman wrote: > Folks, > > A couple more questions: > > (1) Are they any good strategies for splitting load across Varnish > front-ends? Or is the common practice to have just one Varnish server? > > (2) How do people avoid single-point-of-failure for Varnish? Do people > run Varnish on two servers, amassing similar local caches, but put > something in front of the two Varnishes? Or round-robin-DNS? > > John From phk at phk.freebsd.dk Fri Jan 15 23:13:07 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 15 Jan 2010 23:13:07 +0000 Subject: tool for dumping contents of cache In-Reply-To: Your message of "Fri, 15 Jan 2010 13:24:17 PST." Message-ID: <29816.1263597187@critter.freebsd.dk> In message , David Birdsong writes: >I know this would be a huge performance problem, but I'd really like a >tool that could examine the storage file(s) of a running varnish >instance that could dump out url's and hit counts. Play around with varnishlog and varnishtop. If you havn't yet, try: varnishtop -i rxurl -- 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 pubcrawler.com at gmail.com Fri Jan 15 23:39:30 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Fri, 15 Jan 2010 18:39:30 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: Message-ID: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> Have we considered adding pooling functionality to Varnish much like what they have in memcached? Run multiple Varnish(es) and load distributed amongst the identified Varnish server pool.... So an element in Varnish gets hashed and the hash identifies the server in the pool it's on. If the server isn't there or the element isn't there cold lookup to the backend server then we store it where it should be. Seems like an obvious feature - unsure of the performance implications though. The recommendation of load balancers in front on Varnish to facilitate this feature seems costly when talking about F5 gear. The open source solutions require at least two severs dedicated to this load balancing function for sanity sake (which is costly). Finally, Vanish already offers load balancing (although limited) to the back end servers - so lets do the same within Varnish to make sure Varnish scales horizontally and doesn't require these other aids to be deemed totally reliable. From michael at dynamine.net Fri Jan 15 23:46:02 2010 From: michael at dynamine.net (Michael Fischer) Date: Fri, 15 Jan 2010 15:46:02 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 3:39 PM, pub crawler wrote: > The recommendation of load balancers in front on Varnish to facilitate > this feature seems costly when talking about F5 gear. The open > source solutions require at least two severs dedicated to this load > balancing function for sanity sake (which is costly). You can use virtual machines for the front-end load balancers if you're concerned about cost. Alternatively, you can run the load balancers on the same hosts as the caches, provided the Varnish caches listen on different ports or different IP addresses than the load balancers. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb+varnish at slide.com Sat Jan 16 00:35:15 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Fri, 15 Jan 2010 16:35:15 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> Message-ID: On Jan 15, 2010, at 3:39 PM, pub crawler wrote: > Have we considered adding pooling functionality to Varnish much like > what they have in memcached? > > Run multiple Varnish(es) and load distributed amongst the identified > Varnish server pool.... So an element in Varnish gets hashed and the > hash identifies the server in the pool it's on. If the server isn't > there or the element isn't there cold lookup to the backend server > then we store it where it should be. > > Seems like an obvious feature - unsure of the performance implications though. At first glance, this is doing something that you can more cheaply and efficiently do at a higher level, with software dedicated to that purpose. It's interesting, but I'm not sure it's more than just a restatement of the same solution with it's own problems. > The recommendation of load balancers in front on Varnish to facilitate > this feature seems costly when talking about F5 gear. The open > source solutions require at least two severs dedicated to this load > balancing function for sanity sake (which is costly). F5/NetScaler is quite expensive, but they have significant functionality, too. The hardware required to run LVS/haproxy (for example) can be very cheap -- Small RAM, 1-2 CPU cores per ethernet interface. When you're already talking about scaling out to lots of big-RAM/disk Varnish boxes, the cost of a second load balancer is tiny, and the benefit of redundancy is huge. VMs don't solve the redundancy problem, and add significant overhead to network-intensive loads like high-traffic LVS or iptables configs. > Finally, Vanish > already offers load balancing (although limited) to the back end > servers - so lets do the same within Varnish to make sure Varnish > scales horizontally and doesn't require these other aids to be deemed > totally reliable. Squid has a peering feature; I think if you had ever tried it you would know why it's not a fabulous idea. :) It scales terribly. Also, Memcache pooling that I've seen scale involves logic in the app (a higher level). Varnish as a pool/cluster also doesn't provide redundancy to the client interface. A distributed Varnish cache (or perhaps a memcache storage option in Varnish?) is really interesting; it might be scalable, but not obviously. It also doesn't eliminate the need for a higher-level balancer. All just IMHO! -- Ken From rodrigo at mercadolibre.com Sat Jan 16 00:43:01 2010 From: rodrigo at mercadolibre.com (rodrigo at mercadolibre.com) Date: Sat, 16 Jan 2010 00:43:01 +0000 Subject: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> Message-ID: <2020179288-1263602582-cardhu_decombobulator_blackberry.rim.net-938470647-@bda677.bisx.prod.on.blackberry> we have F5 GTM on our main datacenter and some servers with varnish there, also we have have ha proxy with 3 varnish servers on local sites and use F5 gtm with geoip to server always the content from the local site. On each local datacenter we have 400mbts so ha proxy works great for us. Also we testes barracuda load balancer that can work. Enviado desde mi BlackBerry? de Claro Argentina -----Original Message----- From: Ken Brownfield Date: Fri, 15 Jan 2010 16:35:15 To: pub crawler Cc: Subject: Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? On Jan 15, 2010, at 3:39 PM, pub crawler wrote: > Have we considered adding pooling functionality to Varnish much like > what they have in memcached? > > Run multiple Varnish(es) and load distributed amongst the identified > Varnish server pool.... So an element in Varnish gets hashed and the > hash identifies the server in the pool it's on. If the server isn't > there or the element isn't there cold lookup to the backend server > then we store it where it should be. > > Seems like an obvious feature - unsure of the performance implications though. At first glance, this is doing something that you can more cheaply and efficiently do at a higher level, with software dedicated to that purpose. It's interesting, but I'm not sure it's more than just a restatement of the same solution with it's own problems. > The recommendation of load balancers in front on Varnish to facilitate > this feature seems costly when talking about F5 gear. The open > source solutions require at least two severs dedicated to this load > balancing function for sanity sake (which is costly). F5/NetScaler is quite expensive, but they have significant functionality, too. The hardware required to run LVS/haproxy (for example) can be very cheap -- Small RAM, 1-2 CPU cores per ethernet interface. When you're already talking about scaling out to lots of big-RAM/disk Varnish boxes, the cost of a second load balancer is tiny, and the benefit of redundancy is huge. VMs don't solve the redundancy problem, and add significant overhead to network-intensive loads like high-traffic LVS or iptables configs. > Finally, Vanish > already offers load balancing (although limited) to the back end > servers - so lets do the same within Varnish to make sure Varnish > scales horizontally and doesn't require these other aids to be deemed > totally reliable. Squid has a peering feature; I think if you had ever tried it you would know why it's not a fabulous idea. :) It scales terribly. Also, Memcache pooling that I've seen scale involves logic in the app (a higher level). Varnish as a pool/cluster also doesn't provide redundancy to the client interface. A distributed Varnish cache (or perhaps a memcache storage option in Varnish?) is really interesting; it might be scalable, but not obviously. It also doesn't eliminate the need for a higher-level balancer. All just IMHO! -- Ken _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From pubcrawler.com at gmail.com Sat Jan 16 01:33:15 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Fri, 15 Jan 2010 20:33:15 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> Message-ID: <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> > At first glance, this is doing something that you can more cheaply and efficiently do at a higher level, with >software dedicated to that purpose. ?It's interesting, but I'm not sure it's more than just a restatement of the >same solution with it's own problems. Varnish performs very well. Extending this to have a cluster functionality within Varnish I think just makes sense. The workaround solutions so far seem to involve quite a bit of hardware as well as having a miss rate of 50% in example of 2 Varnish instances. Sure it can hot populate fast, but it's two stacks of memory wasted for the same data per se. I suppose a custom solution to hash the inbound requests somehow and determine which Varnish should have the data can be done, but unsure if anyone now is doing that. > F5/NetScaler is quite expensive, but they have significant functionality, too. > > The hardware required to run LVS/haproxy (for example) can be very cheap -- Small RAM, 1-2 CPU cores > per ethernet interface. ?When you're already talking about scaling out to lots of big-RAM/disk Varnish > boxes, the cost of a second load balancer is tiny, and the benefit of redundancy is huge. F5 has always made good gear. The price point limits adoption to deep pockets. I am not convinced that most people need a hardware balancing solution. They have their limited adoption, and the N+1 purchase amounts - 2 minimum, 3 more optimally = $$$$$$. > Squid has a peering feature; I think if you had ever tried it you would know why it's not a fabulous idea. :) >?It scales terribly. ?Also, Memcache pooling that I've seen scale involves logic in the app (a higher level). Squid is a total disaster. If it wasn't none of us would be here using Varnish now would we :) It's amazing Squid even works at this point. The memcached pooling is a simple formula really - it's microsecond fast - yes typically done on the client: Most standard client hashing within memcache clients uses a simple modulus calculation on the value against the number of configured memcached servers. You can summarize the process in pseudocode as: @memcservers = ['a.memc','b.memc','c.memc']; $value = hash($key); $chosen = $value % length(@memcservers); Replacing the above with values: @memcservers = ['a.memc','b.memc','c.memc']; $value = hash('myid'); $chosen = 7009 % 3; In the above example, the client hashing algorithm will choose the server at index 1 (7009 % 3 = 1), and store or retrieve the key and value with that server. > Varnish as a pool/cluster also doesn't provide redundancy to the client interface. > > A distributed Varnish cache (or perhaps a memcache storage option in Varnish?) is really interesting; it might be scalable, but not obviously. ?It also doesn't eliminate the need for a higher-level balancer. > Well, in this instance, Varnish can do the modulus math versus the not Varnish servers in config pool. Wouldn't take any sort of time and the logic already seems to exist in the VCL config to work around when a backend server can be reached. Same logic could be adapted to the "front side" to try connecting to other Varnish instances and doing the failover dance as needed. I put in a feature request this evening for this functionality. We'll see what the official development folks think. If it can't be included in the core, then perhaps a front-end Varnish proxy is in order developmentally. I'll say this akin to Moxi in front of memcached instances: http://labs.northscale.com/moxi/ I think tying Varnish into Memcached is fairly interesting as it appears the market is allocating many resources towards memcached. At some point I believe memcached will become at least an unofficial standard for fast memory based storage. There a number of manufacturers making custom higher performance memcached solutions - Gear6 and Schooner come to mind foremost. That's my $1 worth :) From david.birdsong at gmail.com Sat Jan 16 02:01:45 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Fri, 15 Jan 2010 18:01:45 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 5:33 PM, pub crawler wrote: >> At first glance, this is doing something that you can more cheaply and efficiently do at a higher level, with >software dedicated to that purpose. ?It's interesting, but I'm not sure it's more than just a restatement of the >same solution with it's own problems. > > Varnish performs very well. ?Extending this to have a cluster > functionality within Varnish I think just makes sense. ?The workaround > solutions so far seem to involve quite a bit of hardware as well as > having a miss rate of 50% in example of 2 Varnish instances. ?Sure it > can hot populate fast, but it's two stacks of memory wasted for the > same data per se. ?I suppose a custom solution to hash the inbound > requests somehow and determine which Varnish should have the data can > be done, but unsure if anyone now is doing that. > I'm doing it on a decent scale. This makes the most sense. Let a load balancer load balance and a cache server cache. >> F5/NetScaler is quite expensive, but they have significant functionality, too. >> >> The hardware required to run LVS/haproxy (for example) can be very cheap -- Small RAM, 1-2 CPU cores > per ethernet interface. ?When you're already talking about scaling out to lots of big-RAM/disk Varnish >> boxes, the cost of a second load balancer is tiny, and the benefit of redundancy is huge. > > F5 has always made good gear. ?The price point limits adoption to deep > pockets. ?I am not convinced that most people need a hardware > balancing solution. ?They have their limited adoption, and the N+1 > purchase amounts - 2 minimum, 3 more optimally = $$$$$$. > >> Squid has a peering feature; I think if you had ever tried it you would know why it's not a fabulous idea. :) >?It scales terribly. ?Also, Memcache pooling that I've seen scale involves logic in the app (a higher level). > > Squid is a total disaster. ?If it wasn't none of us would be here > using Varnish now would we :) ?It's amazing Squid even works at this > point. > > The memcached pooling is a simple formula really - it's microsecond > fast - yes typically done on the client: > Most standard client hashing within memcache clients uses a simple > modulus calculation on the value against the number of configured > memcached servers. You can summarize the process in pseudocode as: > > @memcservers = ['a.memc','b.memc','c.memc']; > $value = hash($key); > $chosen = $value % length(@memcservers); > Replacing the above with values: > > @memcservers = ['a.memc','b.memc','c.memc']; > $value = hash('myid'); > $chosen = 7009 % 3; > In the above example, the client hashing algorithm will choose the > server at index 1 (7009 % 3 = 1), and store or retrieve the key and > value with that server. yes and from my experience, each client api has a different hashing implementation. you set a key on a pool of servers in php and you cannot retrieve the value for that key python. if you set a key in python, you can't retrieve it in the nginx module(it follows php iirc.) > >> Varnish as a pool/cluster also doesn't provide redundancy to the client interface. why should it? it's pretty busy dealing with memory management and io heavy threaded craziness. in it's current form, it doesn't care from where the request is coming from and it shouldn't. it should try to reach into it's cache or fetch from a backend. >> >> A distributed Varnish cache (or perhaps a memcache storage option in Varnish?) is really interesting; it might be scalable, but not obviously. ?It also doesn't eliminate the need for a higher-level balancer. >> > > Well, in this instance, Varnish can do the modulus math versus the not > Varnish servers in config pool. Wouldn't take any sort of time and the > logic already seems to exist in the VCL config to work around when a > backend server can be reached. ?Same logic could be adapted to the > "front side" to try connecting to other Varnish instances and doing > the failover dance as needed. > i love that it doesn't do this. i can debug haproxy separately, i can debug varnish sepately, i can debug nginx separately. they're all great tools. > I put in a feature request this evening for this functionality. ?We'll > see what the official development folks think. ?If it can't be > included in the core, then perhaps a front-end Varnish proxy is in > order developmentally. ?I'll say this akin to Moxi in front of > memcached instances: http://labs.northscale.com/moxi/ i vote for big no on this request. if this theoretical varnish performed a hash of a url and determined that it should fetch from a remote *peer* varnish and not from it's own cache file(or backend for that matter), then it would presumably fetch from a different machine, while a different uri would hash to the local cache and fetch from itself. so you'd have traffic going in and out of varnish ports talking to each other before you've even done a backend fetch. the logic of all this seems quite tortured. what you're describing is a load balancer(or a proxy.) haproxy is free and awesome, it does consistent hashing which last i checked a netscaler wont even do. you can add and detract servers all day and your url hashing doesn't clobber itself. sure you'll need more servers, but HA doesn't come for free -just close to it with open source. > > I think tying Varnish into Memcached is fairly interesting as it > appears the market is allocating many resources towards memcached. ?At > some point I believe memcached will become at least an unofficial > standard for fast memory based storage. There a number of > manufacturers making custom higher performance memcached solutions - > Gear6 and Schooner come to mind foremost. > > That's my $1 worth :) sure, tie varnish, memcached, netscaler, nginx all together and customize the architecture to fit your needs. i'm currently working on a way to populate memcache with the hottest of hot files that i want to serve above the varnish pool. varnish is a supremely cool server because devels wrote it to perform a single function very well and left it up to us admins to glue it together with other systems we need and use. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From michael at dynamine.net Sat Jan 16 02:14:43 2010 From: michael at dynamine.net (Michael Fischer) Date: Fri, 15 Jan 2010 18:14:43 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 5:33 PM, pub crawler wrote: Varnish performs very well. Extending this to have a cluster > functionality within Varnish I think just makes sense. haproxy and F5 equipment also both perform very well. > The workaround > solutions so far seem to involve quite a bit of hardware as well as > having a miss rate of 50% in example of 2 Varnish instances. Sure it > can hot populate fast, but it's two stacks of memory wasted for the > same data per se. If you hash your requests from a load balancer across a pool of n varnish instances, the most you lose in the event of a failure is 1/n. You don't cache objects in more than one instance. There's no "wasted" memory. I suppose a custom solution to hash the inbound > requests somehow and determine which Varnish should have the data can > be done, but unsure if anyone now is doing that. > That's precisely what L7 switches do. As David said, haproxy has this functionality, as do other implementations. > Squid is a total disaster. If it wasn't none of us would be here > using Varnish now would we :) It's amazing Squid even works at this > point. > Can you quantify this statement? Squid works very well at some installations. It's not like the code that was out there working spontaneously started to become buggier. > I put in a feature request this evening for this functionality. We'll > see what the official development folks think. If it can't be > included in the core, then perhaps a front-end Varnish proxy is in > order developmentally. I'll say this akin to Moxi in front of > memcached instances: http://labs.northscale.com/moxi/ I'm all for putting backend hashing into Varnish for the purpose of routing requests to backends based on a consistent hash of the request parameters -- and there's no reason why the backend can't be another Varnish instance. But the appropriate use of this is to more efficiently utilize cache memory by associating an object with a designated Varnish server in a pool, not for HA. This was one of my first requests that still (alas) has seen no traction. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at dynamine.net Sat Jan 16 02:20:22 2010 From: michael at dynamine.net (Michael Fischer) Date: Fri, 15 Jan 2010 18:20:22 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> Message-ID: On Fri, Jan 15, 2010 at 6:14 PM, Michael Fischer wrote: I'm all for putting backend hashing into Varnish for the purpose of routing > requests to backends based on a consistent hash of the request parameters -- > and there's no reason why the backend can't be another Varnish instance. > But the appropriate use of this is to more efficiently utilize cache memory > by associating an object with a designated Varnish server in a pool, not for > HA. This was one of my first requests that still (alas) has seen no > traction. > Although now that haproxy does it, my request may now be moot. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.birdsong at gmail.com Sat Jan 16 03:46:31 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Fri, 15 Jan 2010 19:46:31 -0800 Subject: how to purge via http Message-ID: I curl and the hit count is 3 curl -I http://localhost:6081/lru.10.cache.buster HTTP/1.1 200 OK Server: nginx/0.7.64 Content-Type: application/octet-stream Last-Modified: Sat, 16 Jan 2010 03:03:10 GMT X-Varnish-IP: 127.0.0.1 X-Varnish-Port: 6081 Content-Length: 104857600 Date: Sat, 16 Jan 2010 03:35:58 GMT X-Varnish: 1453995344 1453994021 Via: 1.1 varnish Connection: keep-alive X-Varnish-Hits: 3 age: 0 I try to purge using nc: nc localhost 6081 < /tmp/purge_reqest contents of purge_reqest: PURGE /lru.10.cache.buster HTTP/1.0 Host: www.example.com I get a 404. I curl again and the hit-count is incremented to 4. I even put the url in the error to see how varnish sees my handwritten http request: sub vcl_miss { if (req.request == "PURGE") { error 404 req.url; } } and the url looks valid: $ nc localhost 6081 < /tmp/purge_reqest HTTP/1.1 404 /lru.10.cache.buster Server: Varnish Retry-After: 0 Content-Type: text/html; charset=utf-8 Content-Length: 491 Date: Sat, 16 Jan 2010 03:41:45 GMT X-Varnish: 1453995582 Via: 1.1 varnish Connection: close X-Varnish-Hits: 0 age: 0 I checked to see that curl isn't manging up the url: # nc -l 6083 HEAD /lru.10.cache.buster HTTP/1.1 User-Agent: curl/7.18.2 (x86_64-redhat-linux-gnu) libcurl/7.18.2 NSS/3.12.1.1 zlib/1.2.3 libidn/0.6.14 libssh2/0.18 Host: localhost:6083 Accept: */* that looks ok. What am I doing wrong, why is the url not found in the cache between the different requests? From david.birdsong at gmail.com Sat Jan 16 03:49:29 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Fri, 15 Jan 2010 19:49:29 -0800 Subject: how to purge via http In-Reply-To: References: Message-ID: On Fri, Jan 15, 2010 at 7:46 PM, David Birdsong wrote: > I curl and the hit count is 3 > > curl -I http://localhost:6081/lru.10.cache.buster > HTTP/1.1 200 OK > Server: nginx/0.7.64 > Content-Type: application/octet-stream > Last-Modified: Sat, 16 Jan 2010 03:03:10 GMT > X-Varnish-IP: 127.0.0.1 > X-Varnish-Port: 6081 > Content-Length: 104857600 > Date: Sat, 16 Jan 2010 03:35:58 GMT > X-Varnish: 1453995344 1453994021 > Via: 1.1 varnish > Connection: keep-alive > X-Varnish-Hits: 3 > age: 0 > > I try to purge using nc: > nc localhost 6081 ?< /tmp/purge_reqest > > contents of purge_reqest: > PURGE /lru.10.cache.buster HTTP/1.0 > Host: www.example.com > > > I get a 404. ? I curl again and the hit-count is incremented to 4. ?I > even put the url in the error to see how varnish sees my handwritten > http request: > sub vcl_miss { > ?if (req.request == "PURGE") { > ? ?error 404 req.url; > ?} > } > > and the url looks valid: > > $ nc localhost 6081 ?< /tmp/purge_reqest > HTTP/1.1 404 /lru.10.cache.buster > Server: Varnish > Retry-After: 0 > Content-Type: text/html; charset=utf-8 > Content-Length: 491 > Date: Sat, 16 Jan 2010 03:41:45 GMT > X-Varnish: 1453995582 > Via: 1.1 varnish > Connection: close > X-Varnish-Hits: 0 > age: 0 > > > I checked to see that curl isn't manging up the url: > > # nc -l 6083 > HEAD /lru.10.cache.buster HTTP/1.1 > User-Agent: curl/7.18.2 (x86_64-redhat-linux-gnu) libcurl/7.18.2 > NSS/3.12.1.1 zlib/1.2.3 libidn/0.6.14 libssh2/0.18 > Host: localhost:6083 > Accept: */* > > > that looks ok. > > What am I doing wrong, why is the url not found in the cache between > the different requests? > For some reason it often takes me writing out my problem to solve it minutes after I send out the email for help. I didn't realize that Host: is hashed in with the url. From phk at phk.freebsd.dk Sat Jan 16 09:52:45 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 09:52:45 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Fri, 15 Jan 2010 16:35:15 PST." Message-ID: <1944.1263635565@critter.freebsd.dk> In message , Ken Brownfield wri tes: It is important to be absolutely clear about what your objective is here, availability, cache-hit-ratio or raw performance, the best solution will depend on what you are after. For a lot of purposes, you will get a lot of mileage out of a number of parallel Varnish machines with DNS round-robin, for all practical purposes, a zero-cost solution. In the other end, you have a load-balancer in front of your varnishes, which gives you all sorts of neat features at a pretty steep cost. The spectrum between is filled with things like pound, haproxy and other open-source solution, which may, or may not, run on their own hardware. There is no "perfect fit for all" solutions in this space, you will need to make your own choice. >Squid has a peering feature; [...] Squids peering feature was created for hit-rate only, the working scenario is two squids each behind a very slow line to the internet, asking each other before they pull down a file. -- 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 bheltne at gmail.com Sat Jan 16 09:54:27 2010 From: bheltne at gmail.com (Bendik Heltne) Date: Sat, 16 Jan 2010 10:54:27 +0100 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> Message-ID: <1a904f0f1001160154h623b2ee8g3031d9c2d5990a41@mail.gmail.com> > I'm all for putting backend hashing into Varnish for the purpose of routing > requests to backends based on a consistent hash of the request parameters -- > and there's no reason why the backend can't be another Varnish instance. > ?But the appropriate use of this is to more efficiently utilize cache memory > by associating an object with a designated Varnish server in a pool, not for > HA. ?This was one of my first requests that still (alas) has seen no > traction. I must say that i am a bit confused. I don't understand the need of routing requests to different varnish servers based on hash algorithm. So I am wondering what kind of sites are we talking about? If we talk about huge sites with a lot of traffic I find it strange that hardware costs are so problematic. The most common scenarios is that you want load-balancing and/or redundancy. Routing request to different servers will cause you to loose redundancy unless you add extra servers wich again will cost more than upgrade disk or RAM. If you have shared cache you will also loose redundancy unless you compansate on some ways. If you have a small site you could easily get both redundancy and loadbalancing by running HAProxy and Varnish on 2 or 3 servers with failover using Hearbeat or something else (I must admit that i am not familier with HAProxy, so it may support failover out of the box). Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB memory and the backends have a much easier life than before Varnish. We are about to upgrade RAM on the Varnish boxes, and eventually we can switch to disk cache if needed. Since we run a news/media site we know that a few pages gets most of the traffic so refilling the cache on restarts is not a problem. In my opinion refilling the cache should be a problem whatever type of site you are running, but hey, I could be wrong. Varnish should nevertheless not be an excuse for writing slow/poor applications making rebuilding slow or application server crash. Am I missing something here? - Bendik From phk at phk.freebsd.dk Sat Jan 16 09:59:58 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 09:59:58 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Fri, 15 Jan 2010 20:33:15 EST." <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> Message-ID: <1985.1263635998@critter.freebsd.dk> In message <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f at mail.gmail.com>, pub c rawler writes: >Varnish performs very well. Extending this to have a cluster >functionality within Varnish I think just makes sense. You can do some clever stuff with the hash director to distribute the content over a cluster of varnishes: varnish1 has: backend webserver {...} backend varnish2 {...} backend varnish3 {...} acl partner { "varnish1 ip" "varnish2 ip" "varnish3 ip" } director h1 hash { { .backend webserver; .weight 1; } { .backend varnish2; .weight 1; } { .backend varnish3; .weight 1; } } sub vcl_fetch { if (beresp.http.x-partner == "yes") { set beresp.ttl = 0s; unset beresp.http.x-partner; } } sub vcl_deliver { if (client.ip ~ partner) { set resp.http.x-partner = yes; } } On varnish2 you change the "h1" director to read: director h1 hash { { .backend varnish1; .weight 1; } { .backend webserver; .weight 1; } { .backend varnish3; .weight 1; } } On varnish3: director h1 hash { { .backend varnish1; .weight 1; } { .backend varnish2; .weight 1; } { .backend webserver; .weight 1; } } -- 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 michael at dynamine.net Sat Jan 16 15:32:28 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 07:32:28 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1a904f0f1001160154h623b2ee8g3031d9c2d5990a41@mail.gmail.com> References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> <1a904f0f1001160154h623b2ee8g3031d9c2d5990a41@mail.gmail.com> Message-ID: On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne wrote: > I must say that i am a bit confused. > I don't understand the need of routing requests to different varnish > servers based on hash algorithm. So I am wondering what kind of sites > are we talking about? > We're talking about sites that have a hot working set much larger than the amount of RAM you can fit in a single Varnish instance (i.e., 32-64GB). Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB > memory and the backends have a much easier life than before Varnish. > We are about to upgrade RAM on the Varnish boxes, and eventually we > can switch to disk cache if needed. If you receive more than 100 requests/sec per Varnish instance and you use a disk cache, you will die. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pubcrawler.com at gmail.com Sat Jan 16 15:38:14 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 16 Jan 2010 10:38:14 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1985.1263635998@critter.freebsd.dk> References: <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> <1985.1263635998@critter.freebsd.dk> Message-ID: <4c3149fb1001160738l2233481dn82c34c2ba1fcc968@mail.gmail.com> Poul, is anyone running the hash director distribution method like you provided (in production)? What sort of throughput and what sort of use limitations has anyone experienced with this? This is quite exciting - and seems like a fairly good solution to scale/cluster Varnish. -Paul > You can do some clever stuff with the hash director to distribute the > content over a cluster of varnishes: > > varnish1 has: > > ? ? ? ?backend webserver {...} > ? ? ? ?backend varnish2 {...} > ? ? ? ?backend varnish3 {...} > > ? ? ? ?acl partner { > ? ? ? ? ? ? ? ?"varnish1 ip" > ? ? ? ? ? ? ? ?"varnish2 ip" > ? ? ? ? ? ? ? ?"varnish3 ip" > ? ? ? ?} > > ? ? ? ?director h1 hash { > ? ? ? ? ? ? ? ?{ .backend webserver; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend varnish2; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend varnish3; .weight 1; } > ? ? ? ?} > > ? ? ? ?sub vcl_fetch { > ? ? ? ? ? ? ? ?if (beresp.http.x-partner == "yes") { > ? ? ? ? ? ? ? ? ? ? ? ?set beresp.ttl = 0s; > ? ? ? ? ? ? ? ? ? ? ? ?unset beresp.http.x-partner; > ? ? ? ? ? ? ? ?} > ? ? ? ?} > > ? ? ? ?sub vcl_deliver { > ? ? ? ? ? ? ? ?if (client.ip ~ partner) { > ? ? ? ? ? ? ? ? ? ? ? ?set resp.http.x-partner = yes; > ? ? ? ? ? ? ? ?} > ? ? ? ?} > > On varnish2 you change the "h1" director to read: > > ? ? ? ?director h1 hash { > ? ? ? ? ? ? ? ?{ .backend varnish1; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend webserver; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend varnish3; .weight 1; } > ? ? ? ?} > > On varnish3: > > ? ? ? ?director h1 hash { > ? ? ? ? ? ? ? ?{ .backend varnish1; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend varnish2; .weight 1; } > ? ? ? ? ? ? ? ?{ .backend webserver; .weight 1; } > ? ? ? ?} > > -- > 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 michael at dynamine.net Sat Jan 16 15:41:14 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 07:41:14 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1985.1263635998@critter.freebsd.dk> References: <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> <1985.1263635998@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp wrote: > director h1 hash { > { .backend webserver; .weight 1; } > { .backend varnish2; .weight 1; } > { .backend varnish3; .weight 1; } What happens when varnish2 or varnish3 dies? --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Sat Jan 16 17:18:44 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 17:18:44 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 10:38:14 EST." <4c3149fb1001160738l2233481dn82c34c2ba1fcc968@mail.gmail.com> Message-ID: <1811.1263662324@critter.freebsd.dk> In message <4c3149fb1001160738l2233481dn82c34c2ba1fcc968 at mail.gmail.com>, pub c rawler writes: >Poul, is anyone running the hash director distribution method like >you provided (in production)? No idea... -- 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 phk at phk.freebsd.dk Sat Jan 16 17:22:16 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 17:22:16 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 07:41:14 PST." Message-ID: <1837.1263662536@critter.freebsd.dk> In message , Micha el Fischer writes: >On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp wrote: > >> director h1 hash { >> { .backend webserver; .weight 1; } >> { .backend varnish2; .weight 1; } >> { .backend varnish3; .weight 1; } > > >What happens when varnish2 or varnish3 dies? If a particular backend in the director is unhealthy, the requests for it will be redistributed by rehashing over the healthy subset of directors. Once it becomes healthy, normality will be restored. So everything should work out fine, for some value around 99.9% of fine. -- 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 michael at dynamine.net Sat Jan 16 17:29:43 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 09:29:43 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1837.1263662536@critter.freebsd.dk> References: <1837.1263662536@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 9:22 AM, Poul-Henning Kamp wrote: > In message , > Micha > el Fischer writes: > > >On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp >wrote: > > > >> director h1 hash { > >> { .backend webserver; .weight 1; } > >> { .backend varnish2; .weight 1; } > >> { .backend varnish3; .weight 1; } > > > > > >What happens when varnish2 or varnish3 dies? > > If a particular backend in the director is unhealthy, the requests > for it will be redistributed by rehashing over the healthy subset > of directors. Once it becomes healthy, normality will be restored. > > So everything should work out fine, for some value around 99.9% of fine. For instance sizes larger than 2, I think a consistent hash is needed. Otherwise, the overall hit ratio will fall dramatically upon failure of an instance as the requests are rerouted. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Sat Jan 16 18:44:02 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 18:44:02 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 09:29:43 PST." Message-ID: <2131.1263667442@critter.freebsd.dk> In message , Micha el Fischer writes: >For instance sizes larger than 2, I think a consistent hash is needed. > Otherwise, the overall hit ratio will fall dramatically upon failure of an >instance as the requests are rerouted. If you have perfect 1/3 splitting between 3 varnishes, having one die will do bad things to your hitrate until the remaining two distribute the load between them. That's a matter of math, and has nothing to do with the hash algorithm. -- 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 michael at dynamine.net Sat Jan 16 18:45:55 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 10:45:55 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <2131.1263667442@critter.freebsd.dk> References: <2131.1263667442@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 10:44 AM, Poul-Henning Kamp wrote: > In message , > Micha > el Fischer writes: > > >For instance sizes larger than 2, I think a consistent hash is needed. > > Otherwise, the overall hit ratio will fall dramatically upon failure of > an > >instance as the requests are rerouted. > > If you have perfect 1/3 splitting between 3 varnishes, having one die > will do bad things to your hitrate until the remaining two distribute > the load between them. > > That's a matter of math, and has nothing to do with the hash algorithm. Let me put it this way and leave the math up to you: it will be way worse if you don't use a consistent hash. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.birdsong at gmail.com Sat Jan 16 20:58:38 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Sat, 16 Jan 2010 12:58:38 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <2131.1263667442@critter.freebsd.dk> References: <2131.1263667442@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 10:44 AM, Poul-Henning Kamp wrote: > In message , Micha > el Fischer writes: > >>For instance sizes larger than 2, I think a consistent hash is needed. >> Otherwise, the overall hit ratio will fall dramatically upon failure of an >>instance as the requests are rerouted. > > If you have perfect 1/3 splitting between 3 varnishes, having one die > will do bad things to your hitrate until the remaining two distribute > the load between them. > > That's a matter of math, and has nothing to do with the hash algorithm. Right, but those 2 remaining are at least still being asked for the same url's they were prior to the 1 dying. They're just now responsible for the dead varnish's urls in addition to their own working set. This is much better than the entire url space being hashed against 2 buckets. ...or is my understanding of consistent hashing flawed? > > -- > 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. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From phk at phk.freebsd.dk Sat Jan 16 21:19:01 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 21:19:01 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 12:58:38 PST." Message-ID: <2909.1263676741@critter.freebsd.dk> In message , David Birdsong writes: >Right, but those 2 remaining are at least still being asked for the >same url's they were prior to the 1 dying. Correct, the hashing is "canonical" in the sense that if the configured backend is up, all traffic for "its" objects will be sent to it. -- 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 michael at dynamine.net Sat Jan 16 21:32:11 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 13:32:11 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <2909.1263676741@critter.freebsd.dk> References: <2909.1263676741@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 1:19 PM, Poul-Henning Kamp wrote: > In message , > David > Birdsong writes: > > >Right, but those 2 remaining are at least still being asked for the > >same url's they were prior to the 1 dying. > > Correct, the hashing is "canonical" in the sense that if the > configured backend is up, all traffic for "its" objects will be > sent to it. Are you saying that the default hash is not a mod-n-type algorithm? If not, what happens when the failed backend is restored to service? --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Sat Jan 16 21:37:09 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 21:37:09 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 13:32:11 PST." Message-ID: <3105.1263677829@critter.freebsd.dk> In message , Micha el Fischer writes: >> In message , >> David >> Birdsong writes: >> >> >Right, but those 2 remaining are at least still being asked for the >> >same url's they were prior to the 1 dying. >> >> Correct, the hashing is "canonical" in the sense that if the >> configured backend is up, all traffic for "its" objects will be >> sent to it. > >Are you saying that the default hash is not a mod-n-type algorithm? Well, it is mod-n, with the footnote that n has nothing to do with the number of backends, because these have a configurable weight. >If not, what happens when the failed backend is restored to service? It's probably simplest to paraphrase the code: Calculate hash over full complement of backends. Is the selected backend sick Calculate hash over subset of healthy backends -- 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 michael at dynamine.net Sat Jan 16 21:55:07 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 13:55:07 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <3105.1263677829@critter.freebsd.dk> References: <3105.1263677829@critter.freebsd.dk> Message-ID: On Sat, Jan 16, 2010 at 1:37 PM, Poul-Henning Kamp wrote: >Are you saying that the default hash is not a mod-n-type algorithm? > > Well, it is mod-n, with the footnote that n has nothing to do with > the number of backends, because these have a configurable weight. > > >If not, what happens when the failed backend is restored to service? > > It's probably simplest to paraphrase the code: > > Calculate hash over full complement of backends. > Is the selected backend sick > Calculate hash over subset of healthy backends Ah, ok. That should behave reasonably in the event of a backend failure if you're implementing Varnish tiers. Thanks for the clarification. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pubcrawler.com at gmail.com Sat Jan 16 22:00:35 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Sat, 16 Jan 2010 17:00:35 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <3105.1263677829@critter.freebsd.dk> References: <3105.1263677829@critter.freebsd.dk> Message-ID: <4c3149fb1001161400n38a1ef1al18985bc3ad1ad41e@mail.gmail.com> Thanks again Poul for all you do. How does Varnish handle the hashing and locating of data where a backend returns to the pool? Wouldn't the hashing be wrong for prior loaded items since a machine has returned and the pool widens? Just trying to figure out the implications of this because in our environment we regularly find ourselves pulling servers offline. Wondering if the return of a Varnish would operate like a cold-cache miss or what magic in Varnish deals with the change in hashing per se. > It's probably simplest to paraphrase the code: > > ? ? ? ?Calculate hash over full complement of backends. > ? ? ? ?Is the selected backend sick > ? ? ? ? ? ? ? ?Calculate hash over subset of healthy backends > From phk at phk.freebsd.dk Sat Jan 16 22:06:59 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 16 Jan 2010 22:06:59 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Sat, 16 Jan 2010 17:00:35 EST." <4c3149fb1001161400n38a1ef1al18985bc3ad1ad41e@mail.gmail.com> Message-ID: <3419.1263679619@critter.freebsd.dk> In message <4c3149fb1001161400n38a1ef1al18985bc3ad1ad41e at mail.gmail.com>, pub c rawler writes: >Just trying to figure out the implications of this because in our >environment we regularly find ourselves pulling servers offline. >Wondering if the return of a Varnish would operate like a cold-cache >miss or what magic in Varnish deals with the change in hashing per se. There is no built-in magic for that[1]. One of the really powerful things Varnish can do, is chance VCL code on-the-fly, instantly. So it is possible to start your Varnish with one VCL program, and have a small script change to another one some minutes later. You can use that, to start with a VCL where it only uses its neighbors as backends, and then some minutes later when the cache has the most common objects loaded, switch to another VCL that goes directly to the backend. If you want to get fancy, you can use VCL restarts, to ask the neighbors and if they don't have it, go directly to the backend on restart. Poul-Henning [1] In general Varnish has no built in magic, all the magic is your responsibility to write in the VCL code :-) -- 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 david.birdsong at gmail.com Sat Jan 16 22:46:11 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Sat, 16 Jan 2010 14:46:11 -0800 Subject: push button lru nuking Message-ID: I'm trying to hack my way around a push-button like lru nuking like feature. The short description of how I'm doing it follows, I'll explain why farther down. I have a job that watches sm_bfree / (sm_bfree + sm_balloc). Once storage file utilization is past some percentage(yet to be determined) I connect to upstream load balancers and slowly drain traffic away from varnish. Once traffic is off and I can beat the hell out of that box, it's time to free up some space. In the past this has been done with restarts. Upon restarts, the cache hit ratio is destroyed, but the box can keep up and rebuild the cache in a stable way. What I'd like to do is dump everything in the storage files that have a very low obj.hits. Lru nuking on the surface seems like the best thing to initiate, but it usually only kicks in pretty late and puts the machine into a state that is unstable while serving. While not serving, I don't know how to kick it off, furthermore I want it to run hard and free up lots more space than it usually does. ie. cache file is ~200GB, I'd like it to run until sm_free is like 50GB. My idea is to load balance as I've described above. Pull 50GB of trash files through the cache + enough to kick off lru, purge the trash files, monitor sm_bfree and once it's high enough instruct the upstream load balancers to start sending traffic gently for a warm up period. Rinse and repeat into infinity replacing the ssd storage drives as they fail. Is this crazy? Am I uninformed on a better way? Also, I've had to keep making my trash files smaller and smaller. I started with a 10 and 1G files which crashed varnish immediately, then reduced to 500MB files and successfully pulled 200 through - then crashed both my python interpreter (libcurl) and varnish: varnishd[2664]: Child (14772) Panic message: Assert error in STV_alloc(), stevedore.c line 183:#012 Condition((st) != NULL) not true.#012thread = (cache-worker)#012Backtrace:#012 0x421f95: pan_ic+85#012 0x4369e5: STV_alloc+125#012 0x41a1b6: FetchBody+496#012 0x4114dd: cnt_fetch+63d#012 0x412a3d: CNT_Session+35d#012 0x424273: wrk_do_cnt_sess+93#012 0x42362e: wrk_thread_real+26e#012 0x7f2cf51b83da: _end+7f2cf4b47c1a#012 0x7f2cf4a862bd: _end+7f2cf4415afd#012sp = 0x7f2ced387008 {#012 fd = 58, id = 58, xid = 1454039386,#012 client = 127.0.0.1:7057,#012 step = STP_FETCH,#012 handling = deliver,#012 err_code = 200, err_reason = (null),#012 restarts = 0, esis = 0#012 ws = 0x7f2ced387078 { #012 id = "sess",#012 {s,f,r,e} = {0x7f2ced387800,+144,(nil),+4096},#012 },#012 http[req] = {#012 ws = 0x7f2ced387078[sess]#012 "GET",#012 "/lru.10.cache.buster.80.12994",#012 "HTTP/1.1",#012 "User-Agent: PycURL/7.18.2",#012 "Host: localhost:6081",#012 "Accept: */*",#012 },#012 worker = 0x7ef439f06390 {#012 ws = 0x7ef439f068f0 { #012 id = "wrk",#012 {s,f,r,e} = {0x7ef439f03350,+2143,(nil),+4096},#012 },#012 http[bereq] = {#012 ws = 0x7ef439f068f0[wrk]#012 "GET",#012 "/lru.10.cache.buster.80.12994",#012 "HTTP/1.1",#012 "User-Agent: PycURL/7.18.2",#012 "Host: localhost:6081",#012 "Accept: */*",#012 "X-Varnish: 1454039386",#012 "X-Forwarded-For: 127.0.0.1",#012 },#012 http[beresp] = {#012 ws = 0x7ef439f068f0[wrk]#012 "HTTP/1.1",#012 "200",#012 "OK",#012 "Server: nginx/0.7.64",#012 "Date: Sat, 16 Jan 2010 21:11:09 GMT",#012 "Content-Type: application/octet-stream",#012 "Content-Length: 524288000",#012 "Last-Modified: Sat, 16 Jan 2010 21:08:11 GMT",#012 "Connection: keep-alive",#012 "Accept-Ranges: bytes",#012 "X-Varnish-IP: 127.0.0.1",#012 "X-Varnish-Port: 6081",#012 },#012 },#012 Are big files bad? I expect that I'll have to close a pretty big gap normally given that my 4 storage files are 75GB each (SSD). I'd like to start this process before lru nuking happens on it's own while varnish is not unloaded by upstream load balancers. My guess based on loose recollection is that varnish will start lru nuking at 90% capacity. It may just prove not feasible given that I'll have to pull roughly 60GB through to achieve the goal....perhaps freeing up a smaller percentage would be acceptable too though. I'm still playing with this, but wanted to share my uber-hacky idea and let you guys tear it apart if it's a dumb idea. Why: Identifying the working set has been difficult. It's large, the long tail is very long. I've tried adaptive ttls to expire objects constantly that shouldn't be in cache: in vcl_fetch: set every new object to a 2hr ttl. in vcl_hit: if obt.hits == N ; then obj.ttl = 36 hours, where N is some number that is high enough to cache another permutation, update the vcl every 30 mins such that obj.ttl was set to expire exactly at the trough of traffic (2300 - 2350 PST) in vcl_hit: if obt.hits = N ; then obj.ttl = 12h or 10h, or 3h (depending on time of day) This just ended up affecting cache hit ratio such that it was never favorable and the box was just busier as it was constantly expiring objects over the day. Restarts were still better than this. Setup: 3 haproxy load balancer machines consistently hashing to 6 varnish instances. It's a prototype and will be scaled to a larger pool, so the impact of the downtime of a single varnish instance while it goes through a cache storage scrubbing is will be greatly reduced. From michael at dynamine.net Sat Jan 16 23:55:05 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 15:55:05 -0800 Subject: push button lru nuking In-Reply-To: References: Message-ID: This scheme seems very baroque. Why not just reduce the size of your caches so you don't page-thrash and let Varnish's builtin LRU algorithm handle the eviction? --Michael On Sat, Jan 16, 2010 at 2:46 PM, David Birdsong wrote: > I'm trying to hack my way around a push-button like lru nuking like > feature. The short description of how I'm doing it follows, I'll > explain why farther down. > > I have a job that watches sm_bfree / (sm_bfree + sm_balloc). Once > storage file utilization is past some percentage(yet to be determined) > I connect to upstream load balancers and slowly drain traffic away > from varnish. > > Once traffic is off and I can beat the hell out of that box, it's time > to free up some space. In the past this has been done with restarts. > Upon restarts, the cache hit ratio is destroyed, but the box can keep > up and rebuild the cache in a stable way. What I'd like to do is dump > everything in the storage files that have a very low obj.hits. Lru > nuking on the surface seems like the best thing to initiate, but it > usually only kicks in pretty late and puts the machine into a state > that is unstable while serving. While not serving, I don't know how > to kick it off, furthermore I want it to run hard and free up lots > more space than it usually does. > > ie. cache file is ~200GB, I'd like it to run until sm_free is like 50GB. > > My idea is to load balance as I've described above. Pull 50GB of > trash files through the cache + enough to kick off lru, purge the > trash files, monitor sm_bfree and once it's high enough instruct the > upstream load balancers to start sending traffic gently for a warm up > period. Rinse and repeat into infinity replacing the ssd storage > drives as they fail. Is this crazy? Am I uninformed on a better way? > > Also, I've had to keep making my trash files smaller and smaller. I > started with a 10 and 1G files which crashed varnish immediately, then > reduced to 500MB files and successfully pulled 200 through - then > crashed both my python interpreter (libcurl) and varnish: > varnishd[2664]: Child (14772) Panic message: Assert error in > STV_alloc(), stevedore.c line 183:#012 Condition((st) != NULL) not > true.#012thread = (cache-worker)#012Backtrace:#012 0x421f95: > pan_ic+85#012 0x4369e5: STV_alloc+125#012 0x41a1b6: > FetchBody+496#012 0x4114dd: cnt_fetch+63d#012 0x412a3d: > CNT_Session+35d#012 0x424273: wrk_do_cnt_sess+93#012 0x42362e: > wrk_thread_real+26e#012 0x7f2cf51b83da: _end+7f2cf4b47c1a#012 > 0x7f2cf4a862bd: _end+7f2cf4415afd#012sp = 0x7f2ced387008 {#012 fd = > 58, id = 58, xid = 1454039386,#012 client = 127.0.0.1:7057,#012 step > = STP_FETCH,#012 handling = deliver,#012 err_code = 200, err_reason > = (null),#012 restarts = 0, esis = 0#012 ws = 0x7f2ced387078 { #012 > id = "sess",#012 {s,f,r,e} = > {0x7f2ced387800,+144,(nil),+4096},#012 },#012 http[req] = {#012 > ws = 0x7f2ced387078[sess]#012 "GET",#012 > "/lru.10.cache.buster.80.12994",#012 "HTTP/1.1",#012 > "User-Agent: PycURL/7.18.2",#012 "Host: localhost:6081",#012 > "Accept: */*",#012 },#012 worker = 0x7ef439f06390 {#012 ws = > 0x7ef439f068f0 { #012 id = "wrk",#012 {s,f,r,e} = > {0x7ef439f03350,+2143,(nil),+4096},#012 },#012 http[bereq] = > {#012 ws = 0x7ef439f068f0[wrk]#012 "GET",#012 > "/lru.10.cache.buster.80.12994",#012 "HTTP/1.1",#012 > "User-Agent: PycURL/7.18.2",#012 "Host: localhost:6081",#012 > "Accept: */*",#012 "X-Varnish: 1454039386",#012 > "X-Forwarded-For: 127.0.0.1",#012 },#012 http[beresp] = {#012 > ws = 0x7ef439f068f0[wrk]#012 "HTTP/1.1",#012 > "200",#012 "OK",#012 "Server: nginx/0.7.64",#012 > "Date: Sat, 16 Jan 2010 21:11:09 GMT",#012 "Content-Type: > application/octet-stream",#012 "Content-Length: 524288000",#012 > "Last-Modified: Sat, 16 Jan 2010 21:08:11 GMT",#012 > "Connection: keep-alive",#012 "Accept-Ranges: bytes",#012 > "X-Varnish-IP: 127.0.0.1",#012 "X-Varnish-Port: 6081",#012 > },#012 },#012 > > Are big files bad? I expect that I'll have to close a pretty big gap > normally given that my 4 storage files are 75GB each (SSD). I'd like > to start this process before lru nuking happens on it's own while > varnish is not unloaded by upstream load balancers. My guess based on > loose recollection is that varnish will start lru nuking at 90% > capacity. It may just prove not feasible given that I'll have to pull > roughly 60GB through to achieve the goal....perhaps freeing up a > smaller percentage would be acceptable too though. I'm still playing > with this, but wanted to share my uber-hacky idea and let you guys > tear it apart if it's a dumb idea. > > Why: > Identifying the working set has been difficult. It's large, the long > tail is very long. I've tried adaptive ttls to expire objects > constantly that shouldn't be in cache: > > in vcl_fetch: set every new object to a 2hr ttl. > in vcl_hit: if obt.hits == N ; then obj.ttl = 36 hours, where N is > some number that is high enough to cache > another permutation, update the vcl every 30 mins such that obj.ttl > was set to expire exactly at the trough of traffic (2300 - 2350 PST) > in vcl_hit: if obt.hits = N ; then obj.ttl = 12h or 10h, or 3h > (depending on time of day) > > This just ended up affecting cache hit ratio such that it was never > favorable and the box was just busier as it was constantly expiring > objects over the day. Restarts were still better than this. > > Setup: > > 3 haproxy load balancer machines consistently hashing to 6 varnish > instances. It's a prototype and will be scaled to a larger pool, so > the impact of the downtime of a single varnish instance while it goes > through a cache storage scrubbing is will be greatly reduced. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.birdsong at gmail.com Sun Jan 17 00:10:43 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Sat, 16 Jan 2010 16:10:43 -0800 Subject: push button lru nuking In-Reply-To: References: Message-ID: On Sat, Jan 16, 2010 at 3:55 PM, Michael Fischer wrote: > This scheme seems very baroque. ?Why not just reduce the size of your caches > so you don't page-thrash and let Varnish's builtin LRU algorithm handle the > eviction? Then I wont be able to cache nearly as much. I want to originate as much content as possible on the varnish servers ie. reduce backend fetches. There is no way I could fit any useful amount of my working set into a storage that could handle the evictions without spending an unreasonable amount of money (basically fit it in RAM.) -I'd love to be proven wrong though. As far as random reads go, the SSD's are really good; it's just the writes that kill me. Right now a mostly filled cache server with ~80-160GB allocated can maintain between 90-92% cache hit ratio at 400-500Mb/sec. When it fills up completely eviction cause the machine to keel over, parent can't ping the child, health checks fail -general badness. I'd like to let the eviction run under supervision (automated supervision) and augment the eviction such that it buys back a few hours not minutes. > --Michael > > On Sat, Jan 16, 2010 at 2:46 PM, David Birdsong > wrote: >> >> I'm trying to hack my way around a push-button like lru nuking like >> feature. ?The short description of how I'm doing it follows, I'll >> explain why farther down. >> >> I have a job that watches sm_bfree / (sm_bfree + sm_balloc). ?Once >> storage file utilization is past some percentage(yet to be determined) >> I connect to upstream load balancers and slowly drain traffic away >> from varnish. >> >> Once traffic is off and I can beat the hell out of that box, it's time >> to free up some space. ?In the past this has been done with restarts. >> Upon restarts, the cache hit ratio is destroyed, but the box can keep >> up and rebuild the cache in a stable way. ?What I'd like to do is dump >> everything in the storage files that have a very low obj.hits. ?Lru >> nuking on the surface seems like the best thing to initiate, but it >> usually only kicks in pretty late and puts the machine into a state >> that is unstable while serving. ?While not serving, I don't know how >> to kick it off, furthermore I want it to run hard and free up lots >> more space than it usually does. >> >> ie. ?cache file is ~200GB, I'd like it to run until sm_free is like 50GB. >> >> My idea is to load balance as I've described above. ? Pull 50GB of >> trash files through the cache + enough to kick off lru, purge the >> trash files, monitor sm_bfree and once it's high enough instruct the >> upstream load balancers to start sending traffic gently for a warm up >> period. ?Rinse and repeat into infinity replacing the ssd storage >> drives as they fail. ?Is this crazy? ?Am I uninformed on a better way? >> >> Also, I've had to keep making my trash files smaller and smaller. ?I >> started with a 10 and 1G files which crashed varnish immediately, then >> reduced to 500MB files and successfully pulled 200 through - then >> crashed both my python interpreter (libcurl) and varnish: >> varnishd[2664]: Child (14772) Panic message: Assert error in >> STV_alloc(), stevedore.c line 183:#012 ?Condition((st) != NULL) not >> true.#012thread = (cache-worker)#012Backtrace:#012 ?0x421f95: >> pan_ic+85#012 ?0x4369e5: STV_alloc+125#012 ?0x41a1b6: >> FetchBody+496#012 ?0x4114dd: cnt_fetch+63d#012 ?0x412a3d: >> CNT_Session+35d#012 ?0x424273: wrk_do_cnt_sess+93#012 ?0x42362e: >> wrk_thread_real+26e#012 ?0x7f2cf51b83da: _end+7f2cf4b47c1a#012 >> 0x7f2cf4a862bd: _end+7f2cf4415afd#012sp = 0x7f2ced387008 {#012 ?fd = >> 58, id = 58, xid = 1454039386,#012 ?client = 127.0.0.1:7057,#012 ?step >> = STP_FETCH,#012 ?handling = deliver,#012 ?err_code = 200, err_reason >> = (null),#012 ?restarts = 0, esis = 0#012 ?ws = 0x7f2ced387078 { #012 >> ?id = "sess",#012 ? ?{s,f,r,e} = >> {0x7f2ced387800,+144,(nil),+4096},#012 ?},#012 ?http[req] = {#012 >> ws = 0x7f2ced387078[sess]#012 ? ? ?"GET",#012 >> "/lru.10.cache.buster.80.12994",#012 ? ? ?"HTTP/1.1",#012 >> "User-Agent: PycURL/7.18.2",#012 ? ? ?"Host: localhost:6081",#012 >> "Accept: */*",#012 ?},#012 ?worker = 0x7ef439f06390 {#012 ? ?ws = >> 0x7ef439f068f0 { #012 ? ? ?id = "wrk",#012 ? ? ?{s,f,r,e} = >> {0x7ef439f03350,+2143,(nil),+4096},#012 ? ?},#012 ? ?http[bereq] = >> {#012 ? ? ?ws = 0x7ef439f068f0[wrk]#012 ? ? ? ?"GET",#012 >> "/lru.10.cache.buster.80.12994",#012 ? ? ? ?"HTTP/1.1",#012 >> "User-Agent: PycURL/7.18.2",#012 ? ? ? ?"Host: localhost:6081",#012 >> ? ?"Accept: */*",#012 ? ? ? ?"X-Varnish: 1454039386",#012 >> "X-Forwarded-For: 127.0.0.1",#012 ? ?},#012 ? ?http[beresp] = {#012 >> ?ws = 0x7ef439f068f0[wrk]#012 ? ? ? ?"HTTP/1.1",#012 >> "200",#012 ? ? ? ?"OK",#012 ? ? ? ?"Server: nginx/0.7.64",#012 >> "Date: Sat, 16 Jan 2010 21:11:09 GMT",#012 ? ? ? ?"Content-Type: >> application/octet-stream",#012 ? ? ? ?"Content-Length: 524288000",#012 >> ? ? ? "Last-Modified: Sat, 16 Jan 2010 21:08:11 GMT",#012 >> "Connection: keep-alive",#012 ? ? ? ?"Accept-Ranges: bytes",#012 >> ?"X-Varnish-IP: 127.0.0.1",#012 ? ? ? ?"X-Varnish-Port: 6081",#012 >> },#012 ? ?},#012 >> >> Are big files bad? ?I expect that I'll have to close a pretty big gap >> normally given that my 4 storage files are 75GB each (SSD). I'd like >> to start this process before lru nuking happens on it's own while >> varnish is not unloaded by upstream load balancers. ?My guess based on >> loose recollection is that varnish will start lru nuking at 90% >> capacity. ?It may just prove not feasible given that I'll have to pull >> roughly 60GB through to achieve the goal....perhaps freeing up a >> smaller percentage would be acceptable too though. ?I'm still playing >> with this, but wanted to share my uber-hacky idea and let you guys >> tear it apart if it's a dumb idea. >> >> Why: >> Identifying the working set has been difficult. ?It's large, the long >> tail is very long. ?I've tried adaptive ttls to expire objects >> constantly that shouldn't be in cache: >> >> ?in vcl_fetch: set every new object to a 2hr ttl. >> ?in vcl_hit: if obt.hits == N ; then obj.ttl = 36 hours, where N is >> some number that is high enough to cache >> another permutation, update the vcl every 30 mins such that obj.ttl >> was set to expire exactly at the trough of traffic (2300 - 2350 PST) >> ?in vcl_hit: if obt.hits = N ; then obj.ttl = 12h or 10h, or 3h >> (depending on time of day) >> >> This just ended up affecting cache hit ratio such that it was never >> favorable and the box was just busier as it was constantly expiring >> objects over the day. Restarts were still better than this. >> >> Setup: >> >> 3 haproxy load balancer machines consistently hashing to 6 varnish >> instances. ?It's a prototype and will be scaled to a larger pool, so >> the impact of the downtime of a single varnish instance while it goes >> through a cache storage scrubbing is will be greatly reduced. >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > From michael at dynamine.net Sun Jan 17 00:27:37 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 16 Jan 2010 16:27:37 -0800 Subject: push button lru nuking In-Reply-To: References: Message-ID: On Sat, Jan 16, 2010 at 4:16 PM, Michael Fischer wrote: > On Sat, Jan 16, 2010 at 4:10 PM, David Birdsong wrote: > >> On Sat, Jan 16, 2010 at 3:55 PM, Michael Fischer >> wrote: >> > This scheme seems very baroque. Why not just reduce the size of your >> caches >> > so you don't page-thrash and let Varnish's builtin LRU algorithm handle >> the >> > eviction? >> >> Then I wont be able to cache nearly as much. I want to originate as >> much content as possible on the varnish servers ie. reduce backend >> fetches. There is no way I could fit any useful amount of my working >> set into a storage that could handle the evictions without spending an >> unreasonable amount of money (basically fit it in RAM.) -I'd love to >> be proven wrong though. As far as random reads go, the SSD's are >> really good; it's just the writes that kill me. >> >> Right now a mostly filled cache server with ~80-160GB allocated can >> maintain between 90-92% cache hit ratio at 400-500Mb/sec. When it >> fills up completely eviction cause the machine to keel over, parent >> can't ping the child, health checks fail -general badness. I'd like >> to let the eviction run under supervision (automated supervision) and >> augment the eviction such that it buys back a few hours not minutes. > > > What OS are you running? This might be one of those rare cases where a > little more "swappiness" (i.e., aggressiveness of the pageout algorithm) > might buy you something. > This page may be useful if you're running on Linux: http://www.westnet.com/~gsmith/content/linux-pdflush.htm --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.birdsong at gmail.com Sun Jan 17 00:56:22 2010 From: david.birdsong at gmail.com (David Birdsong) Date: Sat, 16 Jan 2010 16:56:22 -0800 Subject: push button lru nuking In-Reply-To: References: Message-ID: On Sat, Jan 16, 2010 at 4:27 PM, Michael Fischer wrote: > On Sat, Jan 16, 2010 at 4:16 PM, Michael Fischer > wrote: >> >> On Sat, Jan 16, 2010 at 4:10 PM, David Birdsong >> wrote: >>> >>> On Sat, Jan 16, 2010 at 3:55 PM, Michael Fischer >>> wrote: >>> > This scheme seems very baroque. ?Why not just reduce the size of your >>> > caches >>> > so you don't page-thrash and let Varnish's builtin LRU algorithm handle >>> > the >>> > eviction? >>> >>> Then I wont be able to cache nearly as much. ?I want to originate as >>> much content as possible on the varnish servers ie. reduce backend >>> fetches. ?There is no way I could fit any useful amount of my working >>> set into a storage that could handle the evictions without spending an >>> unreasonable amount of money (basically fit it in RAM.) ?-I'd love to >>> be proven wrong though. ?As far as random reads go, the SSD's are >>> really good; it's just the writes that kill me. >>> >>> Right now a mostly filled cache server with ~80-160GB allocated can >>> maintain between 90-92% cache hit ratio at 400-500Mb/sec. ?When it >>> fills up completely eviction cause the machine to keel over, parent >>> can't ping the child, health checks fail -general badness. ?I'd like >>> to let the eviction run under supervision (automated supervision) and >>> augment the eviction such that it buys back a few hours not minutes. >> >> What OS are you running? ?This might be one of those rare cases where a >> little more "swappiness" (i.e., aggressiveness of the pageout algorithm) >> might buy you something. > > This page may be useful if you're running on Linux: > http://www.westnet.com/~gsmith/content/linux-pdflush.htm > --Michael yes, this page was very helpful back when I had hopes of tuning my way around this load problem. From ross at trademe.co.nz Sun Jan 17 20:17:14 2010 From: ross at trademe.co.nz (Ross Brown) Date: Mon, 18 Jan 2010 09:17:14 +1300 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <3419.1263679619@critter.freebsd.dk> References: Your message of "Sat, 16 Jan 2010 17:00:35 EST." <4c3149fb1001161400n38a1ef1al18985bc3ad1ad41e@mail.gmail.com> <3419.1263679619@critter.freebsd.dk> Message-ID: <1FF67D7369ED1A45832180C7C1109BCA13E23E700B@tmmail0.trademe.local> > So it is possible to start your Varnish with one VCL program, and have > a small script change to another one some minutes later. What would this small script look like? Sorry if it's a dumb question :) From phk at phk.freebsd.dk Sun Jan 17 20:38:30 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 17 Jan 2010 20:38:30 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 09:17:14 +1300." <1FF67D7369ED1A45832180C7C1109BCA13E23E700B@tmmail0.trademe.local> Message-ID: <9329.1263760710@critter.freebsd.dk> In message <1FF67D7369ED1A45832180C7C1109BCA13E23E700B at tmmail0.trademe.local>, Ross Brown writes: >> So it is possible to start your Varnish with one VCL program, and have >> a small script change to another one some minutes later. > >What would this small script look like?=20 sleep 600 varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" varnishadm vcl.use real_thing -- 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 ross at trademe.co.nz Sun Jan 17 21:10:12 2010 From: ross at trademe.co.nz (Ross Brown) Date: Mon, 18 Jan 2010 10:10:12 +1300 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <9329.1263760710@critter.freebsd.dk> References: Your message of "Mon, 18 Jan 2010 09:17:14 +1300." <1FF67D7369ED1A45832180C7C1109BCA13E23E700B@tmmail0.trademe.local> <9329.1263760710@critter.freebsd.dk> Message-ID: <1FF67D7369ED1A45832180C7C1109BCA13E23E7013@tmmail0.trademe.local> I hadn't used varnishadm before. Looks useful. Thanks! -----Original Message----- From: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] On Behalf Of Poul-Henning Kamp Sent: Monday, 18 January 2010 9:38 a.m. To: Ross Brown Cc: varnish-misc at projects.linpro.no Subject: Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In message <1FF67D7369ED1A45832180C7C1109BCA13E23E700B at tmmail0.trademe.local>, Ross Brown writes: >> So it is possible to start your Varnish with one VCL program, and have >> a small script change to another one some minutes later. > >What would this small script look like?=20 sleep 600 varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" varnishadm vcl.use real_thing -- 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 john at 7fff.com Mon Jan 18 00:40:51 2010 From: john at 7fff.com (John Norman) Date: Sun, 17 Jan 2010 19:40:51 -0500 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1FF67D7369ED1A45832180C7C1109BCA13E23E7013@tmmail0.trademe.local> References: <1FF67D7369ED1A45832180C7C1109BCA13E23E700B@tmmail0.trademe.local> <9329.1263760710@critter.freebsd.dk> <1FF67D7369ED1A45832180C7C1109BCA13E23E7013@tmmail0.trademe.local> Message-ID: Hey, folks, I just want to thank for this great thread -- I think it would be well worth breaking it up into Q/A for the FAQ. We're still a bit undecided as to how we're going to configure our systems, but we feel like we have options now. On Sun, Jan 17, 2010 at 4:10 PM, Ross Brown wrote: > I hadn't used varnishadm before. Looks useful. > > Thanks! > > -----Original Message----- > From: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] On Behalf Of Poul-Henning Kamp > Sent: Monday, 18 January 2010 9:38 a.m. > To: Ross Brown > Cc: varnish-misc at projects.linpro.no > Subject: Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? > > In message <1FF67D7369ED1A45832180C7C1109BCA13E23E700B at tmmail0.trademe.local>, > Ross Brown writes: >>> So it is possible to start your Varnish with one VCL program, and have >>> a small script change to another one some minutes later. >> >>What would this small script look like?=20 > > ? ? ? ?sleep 600 > ? ? ? ?varnishadm vcl.load real_thing "/usr/local/etc/varnish/real.vcl" > ? ? ? ?varnishadm vcl.use real_thing > > -- > 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. > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From jfbustarret at tf1.fr Mon Jan 18 08:53:37 2010 From: jfbustarret at tf1.fr (BUSTARRET, Jean-francois) Date: Mon, 18 Jan 2010 09:53:37 +0100 Subject: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure? In-Reply-To: <3105.1263677829@critter.freebsd.dk> Message-ID: <53C652A09719C54DA24741D0157CB26904C5F464@TFPRDEXS1.tf1.groupetf1.fr> -----Message d'origine----- > It's probably simplest to paraphrase the code: > > Calculate hash over full complement of backends. > Is the selected backend sick > Calculate hash over subset of healthy backends Let's get back to consistent hashing and it's use... Correct me if I am wrong, but doesn't this mean that adding a new varnish instance implies a full rehash ? This can be a problem for scalability. Memcached clients typically solve this by using consistent hashing (a key stays on the same node, even in case of a node failure or node addition/removal). Jean-Fran?ois From tfheen at redpill-linpro.com Mon Jan 18 09:01:58 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 18 Jan 2010 10:01:58 +0100 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <1567ACB3-AB6A-4B5C-82E1-A2A9762FF2D1@slide.com> (Ken Brownfield's message of "Fri, 15 Jan 2010 13:49:40 -0800") References: <1a904f0f1001151009scc57533r9b4378a39f786a8c@mail.gmail.com> <1567ACB3-AB6A-4B5C-82E1-A2A9762FF2D1@slide.com> Message-ID: <87y6jvdbw9.fsf@qurzaw.linpro.no> ]] Ken Brownfield | 3) Hash/bucket URLs to cache pairs. | | Same as 2), but for every hash bucket you would send those hits to two | machines (think RAID-10). This provides redundancy from the effects | of 2a), and gives essentially infinite scalability for the price of | doubling your miss rate once (two machines per bucket caching the same | data). The caveat from 2b) still applies. I've pondered having a semi-stable hash algorithm which would hash to one host, say, 90% of the time and another 10% of the time. This would allow you much more flexible scalability here as you would not need twice the number of servers, only the number you need to have redundant. And you could tune the extra cache miss rate versus how much redundancy you need. I don't know of any products having this out of the box. I am fairly sure you could do it on F5s using iRules, and I would not be surprised if HAProxy or nginx can either do it or be taught how to do this. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From phk at phk.freebsd.dk Mon Jan 18 09:24:55 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 09:24:55 +0000 Subject: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 09:53:37 +0100." <53C652A09719C54DA24741D0157CB26904C5F464@TFPRDEXS1.tf1.groupetf1.fr> Message-ID: <2196.1263806695@critter.freebsd.dk> In message <53C652A09719C54DA24741D0157CB26904C5F464 at TFPRDEXS1.tf1.groupetf1.fr >> It's probably simplest to paraphrase the code: >> >> Calculate hash over full complement of backends. >> Is the selected backend sick >> Calculate hash over subset of healthy backends > >Let's get back to consistent hashing and it's use... > >Correct me if I am wrong, but doesn't this mean that adding a new >varnish instance implies a full rehash ? Yes, that is pretty much guaranteed to be the cost with any stateless hashing. -- 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 tfheen at redpill-linpro.com Mon Jan 18 09:25:22 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 18 Jan 2010 10:25:22 +0100 Subject: sess_timeout not working in 2.0.6? In-Reply-To: <20100115170759.9fb65144.se@5mm.de> (Simon Effenberg's message of "Fri, 15 Jan 2010 17:07:59 +0100") References: <20100115170759.9fb65144.se@5mm.de> Message-ID: <87tyujdat9.fsf@qurzaw.linpro.no> ]] Simon Effenberg Hi, | Is there anything which was changed between 2.0.3 and 2.0.6 which can | cause this issue? It's an intentional change (see r4298). What is the problem you are seeing? As in, why is it a problem that it does not time out until you send data? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 18 09:26:26 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 18 Jan 2010 10:26:26 +0100 Subject: Another question - after clearing cache (or restart), avoiding killing the backend? In-Reply-To: (John Norman's message of "Fri, 15 Jan 2010 16:16:44 -0500") References: Message-ID: <87pr57darh.fsf@qurzaw.linpro.no> ]] John Norman Hi, | Since the cache is cleared after a restart, how do people avoid | slamming their backends as the cache is refilled? You can set max_connections on the backend. That will give 503s to any clients that can't get a backend connection, but this might be preferably to having your backends explode from too much traffic. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From se at 5mm.de Mon Jan 18 09:41:06 2010 From: se at 5mm.de (Simon Effenberg) Date: Mon, 18 Jan 2010 10:41:06 +0100 Subject: sess_timeout not working in 2.0.6? In-Reply-To: <87tyujdat9.fsf@qurzaw.linpro.no> References: <20100115170759.9fb65144.se@5mm.de> <87tyujdat9.fsf@qurzaw.linpro.no> Message-ID: <20100118104106.f66e39e4.se@5mm.de> On Mon, 18 Jan 2010 10:25:22 +0100 Tollef Fog Heen wrote: > ]] Simon Effenberg > > Hi, > > | Is there anything which was changed between 2.0.3 and 2.0.6 which can > | cause this issue? > > It's an intentional change (see r4298). What is the problem you are > seeing? As in, why is it a problem that it does not time out until you > send data? Yes sorry i didn't see this. I never heard about TCP_DEFER_ACCEPT so i was wondering why the requests hangs around (not ESTABLISHED but with another status). Now it's clear (the kernel seems to drop this half established connections only if really many connections coming in without sending any data). Thx again. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > -- B.Sc. Simon Effenberg Software-Entwickler 5mm GmbH Almstadtstra?e 7 10119 Berlin se at 5mm.de 5mm GmbH, Berlin / Amtsgericht Charlottenburg HRB 106932 Gesch?ftsf?hrer: Christian Laase, Andreas Richter This e-mail may contain confidential information. If you are not the intended recipient please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From tfheen at redpill-linpro.com Mon Jan 18 13:20:47 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 18 Jan 2010 14:20:47 +0100 Subject: Handling of cache-control Message-ID: <87bpgrczww.fsf@qurzaw.linpro.no> Hi all, we are considering changing the defaults on how the cache-control header is handled in Varnish. Currently, we only look at s-maxage and maxage to decide if and how long an object should be cached. (We also look at expires, but that's not relevant here.) My suggestion is to also look at Cache-control: no-cache, possibly also private and no-store and obey those. You would still be able to override this in vcl by setting obj.cacheable to true and the ttl to some value. The reason I think we should at least consider changing this is the principle of least surprise: we support max-age and s-maxage, so we should also support the other common values of the cache-control header field. Feedback very welcome, -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From l at lrowe.co.uk Mon Jan 18 14:04:46 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Mon, 18 Jan 2010 14:04:46 +0000 Subject: Handling of cache-control In-Reply-To: <87bpgrczww.fsf@qurzaw.linpro.no> References: <87bpgrczww.fsf@qurzaw.linpro.no> Message-ID: 2010/1/18 Tollef Fog Heen : > > Hi all, > > we are considering changing the defaults on how the cache-control header > is handled in Varnish. ?Currently, we only look at s-maxage and maxage > to decide if and how long an object should be cached. ?(We also look at > expires, but that's not relevant here.) > > My suggestion is to also look at Cache-control: no-cache, possibly also > private and no-store and obey those. ?You would still be able to > override this in vcl by setting obj.cacheable to true and the ttl to > some value. > > The reason I think we should at least consider changing this is the > principle of least surprise: we support max-age and s-maxage, so we > should also support the other common values of the cache-control header > field. > > Feedback very welcome, Given the proposed move away from having the default vcl, it would seem logical to move cache-control header logic into VCL. The less magic that happens behind the scenes, the easier it is to understand what a particular configuration will do. Laurence From michael at dynamine.net Mon Jan 18 17:49:09 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 09:49:09 -0800 Subject: Handling of cache-control In-Reply-To: <87bpgrczww.fsf@qurzaw.linpro.no> References: <87bpgrczww.fsf@qurzaw.linpro.no> Message-ID: On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: > we are considering changing the defaults on how the cache-control header > is handled in Varnish. Currently, we only look at s-maxage and maxage > to decide if and how long an object should be cached. (We also look at > expires, but that's not relevant here.) > > My suggestion is to also look at Cache-control: no-cache, possibly also > private and no-store and obey those. Why wasn't it doing it all along? --Michael From kb+varnish at slide.com Mon Jan 18 20:34:05 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 18 Jan 2010 12:34:05 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> <1a904f0f1001160154h623b2ee8g3031d9c2d5990a41@mail.gmail.com> Message-ID: <14B75F07-969A-43D1-8CC9-9605A2642C9C@slide.com> On Jan 16, 2010, at 7:32 AM, Michael Fischer wrote: > On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne wrote: > > Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB > memory and the backends have a much easier life than before Varnish. > We are about to upgrade RAM on the Varnish boxes, and eventually we > can switch to disk cache if needed. > > If you receive more than 100 requests/sec per Varnish instance and you use a disk cache, you will die. I was surprised by this, what appears to be grossly irresponsible guidance, given how large the installed base is that does thousands per second quite happily. Perhaps there's missing background for this statement? Do you mean swap instead of Varnish file/mmap? Disk could just as easily mean SSD these days. Even years ago on Squid and crappy EIDE drives you could manage 1-2,000 requests per second. -- Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablort+varnish at gmail.com Mon Jan 18 20:47:30 2010 From: pablort+varnish at gmail.com (pablort) Date: Mon, 18 Jan 2010 18:47:30 -0200 Subject: Release schedule for saint mode. Message-ID: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> Hey there, Anybody knows what's the plan to release saint mode ? :D Thanks a lot, -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at dynamine.net Mon Jan 18 20:47:57 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 12:47:57 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: References: <4c3149fb1001151539u53f1b28ege094b41bd910fd25@mail.gmail.com> <4c3149fb1001151733g73f7a5dfjc84342b9df7f078f@mail.gmail.com> <1a904f0f1001160154h623b2ee8g3031d9c2d5990a41@mail.gmail.com> Message-ID: <43A238D7-433D-4000-8AA5-6C574882D40C@dynamine.net> On Jan 18, 2010, at 12:31 PM, Ken Brownfield wrote: > On Jan 16, 2010, at 7:32 AM, Michael Fischer wrote: > >> On Sat, Jan 16, 2010 at 1:54 AM, Bendik Heltne >> wrote: >> >> Our Varnish servers have ~ 120.000 - 150.000 objects cached in ~ 4GB >> memory and the backends have a much easier life than before Varnish. >> We are about to upgrade RAM on the Varnish boxes, and eventually we >> can switch to disk cache if needed. >> >> If you receive more than 100 requests/sec per Varnish instance and >> you use a disk cache, you will die. > > I was surprised by this, what appears to be grossly irresponsible > guidance, given how large the installed base is that does thousands > per second quite happily. > > Perhaps there's missing background for this statement? Do you mean > swap instead of Varnish file/mmap? Disk could just as easily mean > SSD these days. Even years ago on Squid and crappy EIDE drives you > could manage 1-2,000 requests per second I should have been more clear. If you overcommit and use disk you will die. Even SSD is a problem as the write latencies are high. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jan 18 20:50:05 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 20:50:05 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 12:34:05 PST." <14B75F07-969A-43D1-8CC9-9605A2642C9C@slide.com> Message-ID: <66487.1263847805@critter.freebsd.dk> In message <14B75F07-969A-43D1-8CC9-9605A2642C9C at slide.com>, Ken Brownfield wri tes: >> If you receive more than 100 requests/sec per Varnish instance and you >use a disk cache, you will die. > >I was surprised by this, what appears to be grossly irresponsible >guidance, given how large the installed base is that does thousands per >second quite happily. Just for the record: I didn't comment onthat one, since I sort of assumed that everybody could see that a blanket statement like that could never be universally true. Obviously, if your 100 requests are for DVD images, you have tough row to hoe when it comes to designing a disk subsystem, but for more reasonable loads, the above is patently wrong. And yes, if your're worried about diskperformance SSD is the way to go. Poul-Henning -- 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 pubcrawler.com at gmail.com Mon Jan 18 20:58:09 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 18 Jan 2010 15:58:09 -0500 Subject: Varnish use for purely binary files Message-ID: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> This is an inquiry for the Varnish community. Wondering how many folks are using Varnish purely for binary storage and caching (graphic files, archives, audio files, video files, etc.)? Interested specifically in large Varnish installations with either high number of files or where files are large in size. Can anyone out there using Varnish for such care to say they are? Thanks! Paul From phk at phk.freebsd.dk Mon Jan 18 21:05:19 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 21:05:19 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 12:47:57 PST." <43A238D7-433D-4000-8AA5-6C574882D40C@dynamine.net> Message-ID: <75053.1263848719@critter.freebsd.dk> In message <43A238D7-433D-4000-8AA5-6C574882D40C at dynamine.net>, "Michael S. Fis cher" writes: >I should have been more clear. If you overcommit and use disk you >will die. Even SSD is a problem as the write latencies are high. That is still very much dependent on the quality of the VM subsystem in your OS kernel. And I will admit that most kernels can be curdled with a solid varnish-load, but hopefully this will improve over time. Poul-Henning -- 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 michael at dynamine.net Mon Jan 18 21:40:25 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 13:40:25 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <75053.1263848719@critter.freebsd.dk> References: <75053.1263848719@critter.freebsd.dk> Message-ID: On Jan 18, 2010, at 1:05 PM, Poul-Henning Kamp wrote: > In message <43A238D7-433D-4000-8AA5-6C574882D40C at dynamine.net>, "Michael S. Fis > cher" writes: > >> I should have been more clear. If you overcommit and use disk you >> will die. Even SSD is a problem as the write latencies are high. > > That is still very much dependent on the quality of the VM subsystem > in your OS kernel. What VM can overcome page-thrashing incurred by constantly referencing a working set that is significantly larger than RAM? --Michael From michael at dynamine.net Mon Jan 18 21:50:17 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 13:50:17 -0800 Subject: Varnish use for purely binary files In-Reply-To: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> Message-ID: <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> On Jan 18, 2010, at 12:58 PM, pub crawler wrote: > This is an inquiry for the Varnish community. > > Wondering how many folks are using Varnish purely for binary storage > and caching (graphic files, archives, audio files, video files, etc.)? > > Interested specifically in large Varnish installations with either > high number of files or where files are large in size. > > Can anyone out there using Varnish for such care to say they are? I guess it depends on your precise configuration. Most kernels cache recently-accessed files in RAM, and so common web servers such as Apache can already serve up static objects very quickly if they are located in the buffer cache. (Varnish's apparent speed is largely based on the same phenomenon.) If the data is already cached in the origin server's buffer caches, then interposing an additional caching layer may actually be somewhat harmful because it will add some additional latency. If you've evenly distributed your objects among a number of origin servers, assuming they do nothing but serve up these static objects, and the origin servers have a sum total of RAM larger than your caching servers, then you might be better off just serving directly from the origin servers. On the other hand, there are some use cases, such as edge-caching, where interposing a caching layer can be quite helpful even if the origin servers are fast, because making the object available closer to the requestor can conserve network latency. (In fact, overcommit may be OK in this situation if the I/O queue depth is reasonably shallow if you can guarantee that any additional I/O overhead is less than network latency incurred by having to go to the origin server.) --Michael From phk at phk.freebsd.dk Mon Jan 18 21:52:52 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 21:52:52 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 13:40:25 PST." Message-ID: <10658.1263851572@critter.freebsd.dk> In message , "Michael S. Fis cher" writes: >What VM can overcome page-thrashing incurred by constantly referencing a >working set that is significantly larger than RAM? No VM can "overcome" the task at hand, but some work a lot better than others. Varnish has a significant responsibility, not yet fully met, to tell the VM system as much about what is going on as possible. Poul-Henning -- 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 michael at dynamine.net Mon Jan 18 21:54:23 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 13:54:23 -0800 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <10658.1263851572@critter.freebsd.dk> References: <10658.1263851572@critter.freebsd.dk> Message-ID: <8C3F8D23-3E20-4E2C-BA7C-902D843FF964@dynamine.net> On Jan 18, 2010, at 1:52 PM, Poul-Henning Kamp wrote: > In message , "Michael S. Fis > cher" writes: > >> What VM can overcome page-thrashing incurred by constantly referencing a >> working set that is significantly larger than RAM? > > No VM can "overcome" the task at hand, but some work a lot better than > others. > > Varnish has a significant responsibility, not yet fully met, to tell > the VM system as much about what is going on as possible. Can you describe in more detail your comparative analysis and plans? Thanks, --Michael From pubcrawler.com at gmail.com Mon Jan 18 22:16:50 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 18 Jan 2010 17:16:50 -0500 Subject: Varnish use for purely binary files In-Reply-To: <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> Message-ID: <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> > Most kernels cache recently-accessed files in RAM, and so common web servers such as Apache can ?>already serve up static objects very quickly if they are located in the buffer cache. ?(Varnish's apparent >speed is largely based on the same phenomenon.) ?If the data is already cached in the origin server's buffer >caches, then interposing an additional caching layer may actually be somewhat harmful because it will add >some additional latency. So far Varnish is performing very well for us as a web server of these cached objects. The connection time for an item out of Varnish is noticeably faster than with web servers we have used - even where the items have been cached. We are mostly using 3rd party tools like webpagetest.org to look at the item times. > If you've evenly distributed your objects among a number of origin servers, assuming they do nothing but >serve up these static objects, and the origin servers have a sum total of RAM larger than your caching >servers, then you might be better off just serving directly from the origin servers. Varnish is good as a slice in a few different place in a cluster and a few more when running distributed geographic clusters. Aside from Nginx or something highly optimized I am fairly certain Varnish provides faster serving of cached objects as an out of the box default experience. I'll eventually find some time to test it in our environment against web servers we use. > On the other hand, there are some use cases, such as edge-caching, where interposing a caching layer >can be quite helpful even if the origin servers are fast, because making the object available closer to the Edge caching and distributed cache front ends are exactly what's needed. It's a poor mans CDN but can be very effective if done well. The question I posed is to see if this type of use (binary almost purely) is being done and scaling well at large scale (50GB and beyond). Binary data usually poses more overhead as the data is larger - less stored elements in RAM, often it can't be compressed further, more FIFO type of purging due to this, etc. -Paul From michael at dynamine.net Mon Jan 18 22:27:36 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 14:27:36 -0800 Subject: Varnish use for purely binary files In-Reply-To: <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> Message-ID: <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> On Jan 18, 2010, at 2:16 PM, pub crawler wrote: >> Most kernels cache recently-accessed files in RAM, and so common web servers such as Apache can ?>already serve up static objects very quickly if they are located in the buffer cache. (Varnish's apparent >speed is largely based on the same phenomenon.) If the data is already cached in the origin server's buffer >caches, then interposing an additional caching layer may actually be somewhat harmful because it will add >some additional latency. > > So far Varnish is performing very well for us as a web server of these > cached objects. The connection time for an item out of Varnish is > noticeably faster than with web servers we have used - even where the > items have been cached. We are mostly using 3rd party tools like > webpagetest.org to look at the item times. > > Varnish is good as a slice in a few different place in a cluster and a > few more when running distributed geographic clusters. Aside from > Nginx or something highly optimized I am fairly certain Varnish > provides faster serving of cached objects as an out of the box default > experience. I'll eventually find some time to test it in our > environment against web servers we use. I have a hard time believing that any difference in the total response time of a cached static object between Varnish and a general-purpose webserver will be statistically significant, especially considering typical Internet network latency. If there's any difference it should be well under a millisecond. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From kb+varnish at slide.com Mon Jan 18 23:08:08 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 18 Jan 2010 15:08:08 -0800 Subject: Varnish use for purely binary files In-Reply-To: <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> Message-ID: <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> > I have a hard time believing that any difference in the total response time of a cached static object between Varnish and a general-purpose webserver will be statistically significant, especially considering typical Internet network latency. If there's any difference it should be well under a millisecond. I would suggest that you get some real-world experience, or at least do some research in this area. Like your earlier assertion, this is patently untrue as a general conclusion. Differences in latency of serving static content can vary widely based on the web server in use, easily tens of milliseconds or more. There are dozens of web servers out there, some written in interpreted languages, many custom-written for a specific application, many with add-ons and modules and other hijinx that can effect the latency of serving static content. Additionally, very few of these implement their own managed cache; the rest accidentally rely on filesystem cache which may or may not perform with low or predictable latency, and may not be large enough for a working set. In the real world, sites run their applications through web servers, and this fact does (and should) guide the decision on the base web server to use, not static file serving. Thus the primary importance IMHO of software like reverse-Squid and Varnish. If you're serving pure static content with no need for application logic, then yes, there is little benefit to choosing a two-tier infrastructure when a one-tier out-of-the-box nginx/lighttpd/thttpd will do just fine. But, if your content does not fit in memory, you're back to reverse-Squid or Varnish. (Though nginx may have an on-disk cache? And don't get me started on Apache caching. :-) -- Ken > --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at dynamine.net Mon Jan 18 23:16:56 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 15:16:56 -0800 Subject: Varnish use for purely binary files In-Reply-To: <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> Message-ID: On Jan 18, 2010, at 3:08 PM, Ken Brownfield wrote: >> I have a hard time believing that any difference in the total response time of a cached static object between Varnish and a general-purpose webserver will be statistically significant, especially considering typical Internet network latency. If there's any difference it should be well under a millisecond. > > I would suggest that you get some real-world experience, or at least do some research in this area. Like your earlier assertion, this is patently untrue as a general conclusion. > Differences in latency of serving static content can vary widely based on the web server in use, easily tens of milliseconds or more. There are dozens of web servers out there, some written in interpreted languages, many custom-written for a specific application, many with add-ons and modules and other hijinx that can effect the latency of serving static content. That's why you don't use those webservers as origin servers for that purpose. But you don't use Varnish for it either. It's not an origin server anyway. > In the real world, sites run their applications through web servers, and this fact does (and should) guide the decision on the base web server to use, not static file serving. I meant webservers that more than 50%+ of the world uses, which do not include those. I was assuming, perhaps incorrectly, that the implementor would have at least the wisdom/laziness to use a popular general-purpose webserver such as Apache for the purpose of serving static objects from the filesystem. And that's not even really a stretch as it's the default for most servers. > (Though nginx may have an on-disk cache? And don't get me started on Apache caching. :-) Doctor, heal thyself before you call me inexperienced. Using application-level caching for serving objects from the filesystem rarely works, which is the main point of Varnish. Just because *you* can't get good performance out of Apache doesn't mean it's not worth using. --Michael From pubcrawler.com at gmail.com Mon Jan 18 23:37:01 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 18 Jan 2010 18:37:01 -0500 Subject: Varnish use for purely binary files In-Reply-To: <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> Message-ID: <4c3149fb1001181537n12d1d6a2jf0c5b264f6dcfc4d@mail.gmail.com> > Differences in latency of serving static content can vary widely based on > the web server in use, easily tens of milliseconds or more. ?There are > dozens of web servers out there, some written in interpreted languages, many > custom-written for a specific application, many with add-ons and modules and Most webservers as shipped are simply not very speedy. Nginx, Cherokee, Lighty are three exceptions :) Latency is all over the place in web server software. Caching is a black art still no matter where you are talking about having one or lacking one :) Ten milliseconds is easily wasted in a web server, connection pooling, negotiating the transfer, etc. Most sites have so many latency issues and such a lack of performance. Most folks seem to just ignore it though and think all is well with low performance. That's why Varnish and the folks here are so awesome. A band of data crushers, bandwidth abusers and RAM junkies with lower latency in mind. Latency is an ugly multiplier - it gets multiplied by every request, multiple requests per user, multiplied by all the use in a period of time. If your page has 60 elements to be served and you add a mere 5ms to each element that's 300ms of latency just on serving static items. There are other scenarios too like dealing with people on slow connections (if your audience has lots of these). > ?If you're serving pure static content with no need for application logic, > then yes, there is little benefit to choosing a two-tier infrastructure when > a one-tier out-of-the-box nginx/lighttpd/thttpd will do just fine. ?But, if > your content does not fit in memory, you're back to reverse-Squid or > Varnish. ?(Though nginx may have an on-disk cache? ?And don't get me started > on Apache caching. :-) Static sites will still be aided in scaling fronting them with Varnish or similar cache front end if they are big enough. A small for instance might be offloading images or items that require longer connection timeouts to Varnish - reducing the disk IO perhaps and being able to cut your open connections on your web server. You could do the same obviously by dissecting your site into multiple servers and dividing the load ~ lose some of the functionality that is appealing in Varnish and the ability to dynamically adjust traffic, load, direction, etc. within Varnish. Unsure if anything similar exists in Nginx - but then you are turning a web server into something else and likely some performance reduction. Mind you, most people here *I think* are dealing with big scaling - busy sites, respectable and sometimes awe inspiring amounts of data. Then there are those slow as can be app servers the might have to work around too. So the scale of latency issues is a huge cost center for most folks. Plenty of papers have been wrote about latency and the user experience. The slower the load the less people interact and in commerce terms spend with the site. From phk at phk.freebsd.dk Mon Jan 18 23:44:43 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 23:44:43 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 17:16:50 EST." <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> Message-ID: <59009.1263858283@critter.freebsd.dk> In message <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2 at mail.gmail.com>, pub c rawler writes: >So far Varnish is performing very well for us as a web server of these >cached objects. The connection time for an item out of Varnish is >noticeably faster than with web servers we have used - even where the >items have been cached. We are mostly using 3rd party tools like >webpagetest.org to look at the item times. The average workload of a cache hit, last I looked, was 7 system calls, with typical service times, from request received from kernel until response ready to be written to kernel, of 10-20 microseconds. Compared to the amount of work real webservers do for the same task, that is essentially nothing. I don't know if that is THE best performance, but I know of a lot of software doing a lot worse. Try running varnishhist if you have not already :-) Poul-Henning -- 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 phk at phk.freebsd.dk Mon Jan 18 23:47:53 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 23:47:53 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 15:16:56 PST." Message-ID: <59040.1263858473@critter.freebsd.dk> In message , "Michael S. Fis cher" writes: >That's why you don't use those webservers as origin servers for >that purpose. But you don't use Varnish for it either. It's not >an origin server anyway. Actually, for protocol purposes, Varnish is an origin server. If you read RFC2616 very carefully, you can find the one place where they failed to evict server-side caches from the text, when they realized that a cache under the control of the webmaster, is indistinguisable from a webserver, for protocol purposes. Poul-Henning -- 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 michael at dynamine.net Mon Jan 18 23:47:58 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 15:47:58 -0800 Subject: Varnish use for purely binary files In-Reply-To: <4c3149fb1001181537n12d1d6a2jf0c5b264f6dcfc4d@mail.gmail.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> <4c3149fb1001181537n12d1d6a2jf0c5b264f6dcfc4d@mail.gmail.com> Message-ID: <02D0EC1A-D0B0-40EE-B278-B57714E54BAE@dynamine.net> On Jan 18, 2010, at 3:37 PM, pub crawler wrote: >> Differences in latency of serving static content can vary widely based on >> the web server in use, easily tens of milliseconds or more. There are >> dozens of web servers out there, some written in interpreted languages, many >> custom-written for a specific application, many with add-ons and modules and > > Most webservers as shipped are simply not very speedy. Nginx, > Cherokee, Lighty are three exceptions :) > Latency is all over the place in web server software. Caching is a > black art still no matter where you are talking about having one or > lacking one :) Ten milliseconds is easily wasted in a web server, > connection pooling, negotiating the transfer, etc. Most sites have so > many latency issues and such a lack of performance. Let me clear, in case I have not been clear enough already: I am not talking about the edge cases of those low-concurrency, high-latency, scripted-language webservers that are becoming tied to web application frameworks like Rails and Django and that are the best fit for front-end caching because they are slow at serving dynamic content. But we are not discussing serving dynamic content in this thread anyway. We are talking about binary files, aren't we? Yes? Blobs on disk? Unless everyone is living on a different plane then me, then I think that's what we're talking about. For those you should be using a general purpose webserver. There's no reason you can't run both side by side. And I stand by my original statement about their performance relative to Varnish. --Michael From michael at dynamine.net Mon Jan 18 23:49:03 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 15:49:03 -0800 Subject: Varnish use for purely binary files In-Reply-To: <59040.1263858473@critter.freebsd.dk> References: <59040.1263858473@critter.freebsd.dk> Message-ID: <75923D26-9766-47A2-AE00-08A662A4CB24@dynamine.net> On Jan 18, 2010, at 3:47 PM, Poul-Henning Kamp wrote: > In message , "Michael S. Fis > cher" writes: > >> That's why you don't use those webservers as origin servers for >> that purpose. But you don't use Varnish for it either. It's not >> an origin server anyway. > > Actually, for protocol purposes, Varnish is an origin server. > > If you read RFC2616 very carefully, you can find the one place where > they failed to evict server-side caches from the text, when they > realized that a cache under the control of the webmaster, is > indistinguisable from a webserver, for protocol purposes. I meant it for practical purposes, Poul-Henning. But I'm sure you knew that. :) --Michael From pubcrawler.com at gmail.com Mon Jan 18 23:50:41 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 18 Jan 2010 18:50:41 -0500 Subject: Varnish use for purely binary files In-Reply-To: <59009.1263858283@critter.freebsd.dk> References: <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <59009.1263858283@critter.freebsd.dk> Message-ID: <4c3149fb1001181550q535423b5x74f1de36bc3a5fdb@mail.gmail.com> > The average workload of a cache hit, last I looked, was 7 system > calls, with typical service times, from request received from kernel > until response ready to be written to kernel, of 10-20 microseconds. Well that explains some of the performance difference in Varnish (in our experience) versus web servers. 7 calls isn't much and you said MICROSECONDS. :) > I don't know if that is THE best performance, but I know of a lot > of software doing a lot worse. I haven't done the reproduceable testing to share with everyone yet. But using 3rd party remotely hosted analysis services we know for certain our page elements are starting faster and the average object load time has gone down significantly. We are using one or more of the fast webservers and still are - just behind Varnish now :) From kb+varnish at slide.com Mon Jan 18 23:54:56 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 18 Jan 2010 15:54:56 -0800 Subject: Varnish use for purely binary files In-Reply-To: References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> Message-ID: <5E2A26C0-284B-4A13-AE88-34462CB2055E@slide.com> On Jan 18, 2010, at 3:16 PM, Michael S. Fischer wrote: > On Jan 18, 2010, at 3:08 PM, Ken Brownfield wrote: > >> In the real world, sites run their applications through web servers, and this fact does (and should) guide the decision on the base web server to use, not static file serving. > > I meant webservers that more than 50%+ of the world uses, which do not include those. Depends on whether you mean 50% of companies, or 50% of web property traffic. The latter? Definitely. > I was assuming, perhaps incorrectly, that the implementor would have at least the wisdom/laziness to use a popular general-purpose webserver such as Apache for the purpose of serving static objects from the filesystem. And that's not even really a stretch as it's the default for most servers. This is true, though default Apache configurations vary the gamut from clean to bloated (>1ms variation I would say) > >> (Though nginx may have an on-disk cache? And don't get me started on Apache caching. :-) > > Doctor, heal thyself before you call me inexperienced. Using application-level caching for serving objects from the filesystem rarely works, which is the main point of Varnish. Just because *you* can't get good performance out of Apache doesn't mean it's not worth using. I'm not sure what your definition of application-level is, here. Much of Apache's functionality could be considered an application. But if you mean an embedded app running "inside" Apache, then that distinction has almost no bearing on whether file serving "works" or not -- an app can serve files just as fast as Apache, assuming C/C++. Adding unnecessary software overhead will add latency to requests to the filesystem, and obviously should be avoided. However, a cache in front of a general web server will 1) cause an object miss to have additional latency (though small) and 2) guarantee object hits will be as low as possible. A cache in front of a dedicated static file server is unnecessary, but worst-case would introduce additional latency only for cache misses. I'm not sure what your comment on Apache is about, since I never said Apache isn't worth using. I've been using it in production for 11+ years now. Does it perform "well" for static files in the absence of any other function? Yes. Would I choose it for anything other than an application server? No. There are much better solutions out there, and the proof is in the numbers. -- Ken > --Michael From phk at phk.freebsd.dk Mon Jan 18 23:59:03 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Jan 2010 23:59:03 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: Your message of "Mon, 18 Jan 2010 13:54:23 PST." <8C3F8D23-3E20-4E2C-BA7C-902D843FF964@dynamine.net> Message-ID: <69965.1263859143@critter.freebsd.dk> In message <8C3F8D23-3E20-4E2C-BA7C-902D843FF964 at dynamine.net>, "Michael S. Fis cher" writes: >On Jan 18, 2010, at 1:52 PM, Poul-Henning Kamp wrote: >Can you describe in more detail your comparative analysis and plans? =20 First of all, the major player in this are the 'stevedores' like "malloc", "file" and "persistent". I'm trying to apply what I have learned so far to the persistent stevedore and it has much more VM-hintable behaviour than the "file" stevedore, and hopefully a much more disk-scheduling friendly (ie: sequential) layout policy. In particular, I'm trying to make the "persistent" stevedore as "cheap-SSD" friendly as possible, by optmising for sequential writes where at all possile. Exactly how much help this will be, depends on everything in your world, including what your kernel does for madvise(), and if you have a usable sendfile() syscall, and therefore giving any specific promises is pretty impossible for me. Poul-Henning -- 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 kb+varnish at slide.com Mon Jan 18 23:59:19 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 18 Jan 2010 15:59:19 -0800 Subject: Varnish use for purely binary files In-Reply-To: <02D0EC1A-D0B0-40EE-B278-B57714E54BAE@dynamine.net> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> <4c3149fb1001181537n12d1d6a2jf0c5b264f6dcfc4d@mail.gmail.com> <02D0EC1A-D0B0-40EE-B278-B57714E54BAE@dynamine.net> Message-ID: <364F5E3E-0D1E-4C95-B101-B7A00C276435@slide.com> > Let me clear, in case I have not been clear enough already: > > I am not talking about the edge cases of those low-concurrency, high-latency, scripted-language webservers that are becoming tied to web application frameworks like Rails and Django and that are the best fit for front-end caching because they are slow at serving dynamic content. > > But we are not discussing serving dynamic content in this thread anyway. We are talking about binary files, aren't we? Yes? Blobs on disk? Unless everyone is living on a different plane then me, then I think that's what we're talking about. > > For those you should be using a general purpose webserver. There's no reason you can't run both side by side. And I stand by my original statement about their performance relative to Varnish. Definitely wasn't clear until now. But now I'm not sure what we're discussing, since comparing the performance of a reverse-proxy cache to an origin server is rather pointless. A cache hit under Varnish will be comparable in latency to a dedicated static server hit, regardless of the backend. The rate of misses will determine whether a dedicated static server would be required, and this is a growth path that many companies follow. -- Ken > --Michael From michael at dynamine.net Tue Jan 19 00:03:12 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 16:03:12 -0800 Subject: Varnish use for purely binary files In-Reply-To: <5E2A26C0-284B-4A13-AE88-34462CB2055E@slide.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> <5E2A26C0-284B-4A13-AE88-34462CB2055E@slide.com> Message-ID: On Jan 18, 2010, at 3:54 PM, Ken Brownfield wrote: > Adding unnecessary software overhead will add latency to requests to the filesystem, and obviously should be avoided. However, a cache in front of a general web server will 1) cause an object miss to have additional latency (though small) and 2) guarantee object hits will be as low as possible. A cache in front of a dedicated static file server is unnecessary, but worst-case would introduce additional latency only for cache misses. Agreed. This is what I was trying to communicate all along. It was my understanding that this was what the thread was about. > Does [Apache] perform "well" for static files in the absence of any other function? Yes. Would I choose it for anything other than an application server? No. There are much better solutions out there, and the proof is in the numbers. Not sure what you mean here... at my company it's used for everything but proxying (because Apache's process model is contraindicated at high concurrencies if you want to support Keep-Alive connections). And we serve a lot of traffic at very low latencies. --Michael From phk at phk.freebsd.dk Tue Jan 19 00:06:34 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 00:06:34 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 15:47:58 PST." <02D0EC1A-D0B0-40EE-B278-B57714E54BAE@dynamine.net> Message-ID: <71941.1263859594@critter.freebsd.dk> In message <02D0EC1A-D0B0-40EE-B278-B57714E54BAE at dynamine.net>, "Michael S. Fis cher" writes: >But we are not discussing serving dynamic content in this thread >anyway. We are talking about binary files, aren't we? Yes? Blobs >on disk? Unless everyone is living on a different plane then me, >then I think that's what we're talking about. > >For those you should be using a general purpose webserver. There's >no reason you can't run both side by side. And I stand by my >original statement about their performance relative to Varnish. Why would you use a general purpose webserver, if Varnish can deliver 80 or 90% of your content much faster and much cheaper ? It sounds to me like you have not done your homework with respect to Varnish. For your information, here is the approximate sequence of systemcalls Varnish performs for a cache hit: read (get the HTTP request) timestamp timestamp timestamp timestamp writev (write the response) With some frequency, depending on your system and OS, you will also see a few mutex operations. The difference between the first and the last timestamp is typically on the order of 10-20 microseconds. The middle to timestamps are mostly for my pleasure and could be optimized out, if they made any difference. This is why people who run synthetic benchmarks do insane amounts of req/s on varnish boxes, for values of insane >> 100.000. I suggest you look at how many systems calls and how long time your "general purpose webserver" spends doing the same job. Once you have done that, I can recommend you read the various architects notes I've written, and maybe browse through http://phk.freebsd.dk/pubs/varnish_perf.pdf Where you decide to deposit your "conventional wisdom" afterwards is for you to decide, but it is unlikely to be applicable. Poul-Henning -- 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 phk at phk.freebsd.dk Tue Jan 19 00:12:48 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 00:12:48 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 15:59:19 PST." <364F5E3E-0D1E-4C95-B101-B7A00C276435@slide.com> Message-ID: <82627.1263859968@critter.freebsd.dk> In message <364F5E3E-0D1E-4C95-B101-B7A00C276435 at slide.com>, Ken Brownfield wri tes: >A cache hit under Varnish will be comparable in latency to a >dedicated static server hit, regardless of the backend. Only provided the "dedicated static server" is written to work in a modern SMP/VM system, which few, if any, of them are. Poul-Henning -- 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 kb+varnish at slide.com Tue Jan 19 00:15:14 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 18 Jan 2010 16:15:14 -0800 Subject: Varnish use for purely binary files In-Reply-To: References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> <5E2A26C0-284B-4A13-AE88-34462CB2055E@slide.com> Message-ID: <97F066DD-4044-46A7-B3E1-34CE928E81F3@slide.com> On Jan 18, 2010, at 4:03 PM, Michael S. Fischer wrote: >> Does [Apache] perform "well" for static files in the absence of any other function? Yes. Would I choose it for anything other than an application server? No. There are much better solutions out there, and the proof is in the numbers. > > > Not sure what you mean here... at my company it's used for everything but proxying (because Apache's process model is contraindicated at high concurrencies if you want to support Keep-Alive connections). And we serve a lot of traffic at very low latencies. The concurrency issue is really Apache's achilles tendon. Real world example: being limited to 70 concurrent application workers on a 16GB machine is a bad joke. Like you said, simultaneous (especially slow) connections will kill Apache dead very quickly. mpm_event could be a huge boon (if Apache insists on continuing with a pure process/thread model) but I'm not sure it's every going to "arrive". Ironically and IMHO, one of the barriers to Varnish scalability is its thread model, though this problem strikes in the thousands of connections. Apache is fast at pure static, but it isn't the fastest. nginx/lighttpd/thttpd can be simpler and faster, and they don't rely on the process/thread model. But whether or not you need that 100th percentile of speed depends on a huge number of variables. Apache's ubiquity is a strong argument, and it would take heavy loads to differentiate Apache from the others above. -- Ken > --Michael From michael at dynamine.net Tue Jan 19 00:17:59 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 16:17:59 -0800 Subject: Varnish use for purely binary files In-Reply-To: <71941.1263859594@critter.freebsd.dk> References: <71941.1263859594@critter.freebsd.dk> Message-ID: <87F6439F-76FE-416C-B750-5A53A9712A29@dynamine.net> On Jan 18, 2010, at 4:06 PM, Poul-Henning Kamp wrote: > In message <02D0EC1A-D0B0-40EE-B278-B57714E54BAE at dynamine.net>, "Michael S. Fis > cher" writes: > >> But we are not discussing serving dynamic content in this thread >> anyway. We are talking about binary files, aren't we? Yes? Blobs >> on disk? Unless everyone is living on a different plane then me, >> then I think that's what we're talking about. >> >> For those you should be using a general purpose webserver. There's >> no reason you can't run both side by side. And I stand by my >> original statement about their performance relative to Varnish. > > Why would you use a general purpose webserver, if Varnish can > deliver 80 or 90% of your content much faster and much cheaper ? There's no question that Varnish is faster and that it can handle more peak requests per second than a general-purpose webserver at a near-100% cache hit rate. I'm merely contending that the small amount of added latency for a cache hit, where neither server is operating at full capacity, is not enough to significantly affect the user experience. There are many competing factors that need to go into the planning process other than pure peak capacity, among them the cache hit ratio, the cost of a cache miss, and where your money is better spent: installing RAM in cache servers or in origin servers. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Jan 19 00:21:30 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 00:21:30 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 16:17:59 PST." <87F6439F-76FE-416C-B750-5A53A9712A29@dynamine.net> Message-ID: <84780.1263860490@critter.freebsd.dk> In message <87F6439F-76FE-416C-B750-5A53A9712A29 at dynamine.net>, "Michael S. Fis cher" writes: >I'm merely contending that the small amount of added = >latency for a cache hit, where neither server is operating at full = >capacity, is not enough to significantly affect the user experience. Which translated to plain english becomes: If you don't need varnish, you don't need varnish. I'm not sure how much useful information that statement contains :-) -- 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 phk at phk.freebsd.dk Tue Jan 19 00:35:16 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 00:35:16 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 16:15:14 PST." <97F066DD-4044-46A7-B3E1-34CE928E81F3@slide.com> Message-ID: <84880.1263861316@critter.freebsd.dk> In message <97F066DD-4044-46A7-B3E1-34CE928E81F3 at slide.com>, Ken Brownfield wri tes: >Ironically and IMHO, one of the barriers to Varnish scalability >is its thread model, though this problem strikes in the thousands >of connections. It's only a matter of work to pool slow clients in Varnish into eventdriven writer clusters, but so far I have not seen a credible argument for doing it. A thread is pretty cheap to have around if it doesn't do anything, and the varnish threads typically do not do anything during the delivery-phase: They are stuck in the kernel in a writev(2) or sendfile(2) system call. In terms of machine resources, there is no cheaper way to do it. An important but not often spotted advantage is that the object overhead does not depend on the size of the object: a 1 megabyte object takes exactly as few resources as a 1 byte object. If you change to an eventdriven model, you will have many more system-calls, scaling O(n) with object sizes, and you will get a lot more locking in the kernel, resulting in contention on fd's and pcbs. At the higher level, you will have threads getting overwhelmed if/when we misestimate the amount of bandwidth they have to deal with, and you will need complicated code to mitigate this. For 32bit machines, having thousands of threads is an issue, because you run ou of address-space, but on a 64bit system, having 1000 threads or even 10k threads is not really an issue. Again: Don't let the fact that people have doen this simple datamoving job wrong in the past, mislead you think it cannot be done right. The trick to getting high performance, is not doing work you don't need to do, no architecture or performance trick can eve beat that. Poul-Henning -- 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 phk at phk.freebsd.dk Tue Jan 19 00:37:04 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 00:37:04 +0000 Subject: Handling of cache-control In-Reply-To: Your message of "Mon, 18 Jan 2010 09:49:09 PST." Message-ID: <84910.1263861424@critter.freebsd.dk> In message , "Michael S. Fis cher" writes: >On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: >> My suggestion is to also look at Cache-control: no-cache, possibly also >> private and no-store and obey those. > >Why wasn't it doing it all along? Because we wanted to give the backend a chance to tell Varnish one thing with respect to caching, and the client another. I'm not saying we hit the right decision, and welcome any consistent, easily explainable policy you guys can agree on. -- 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 michael at dynamine.net Tue Jan 19 00:39:48 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 16:39:48 -0800 Subject: Varnish use for purely binary files In-Reply-To: <97F066DD-4044-46A7-B3E1-34CE928E81F3@slide.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <85FCEF02-5B7B-40E3-9C63-4CD04FD42E17@dynamine.net> <4c3149fb1001181416r7cd1c1c2n923a438d6a0dfae2@mail.gmail.com> <3FFD58D8-14EE-4BCD-9F9A-97BC0221EBF4@dynamine.net> <6FB088F4-AFE7-464C-9295-81C35921E981@slide.com> <5E2A26C0-284B-4A13-AE88-34462CB2055E@slide.com> <97F066DD-4044-46A7-B3E1-34CE928E81F3@slide.com> Message-ID: <823AB95B-84FB-426C-B893-11B22A6DE9E7@dynamine.net> On Jan 18, 2010, at 4:15 PM, Ken Brownfield wrote: > Ironically and IMHO, one of the barriers to Varnish scalability is its thread model, though this problem strikes in the thousands of connections. Agreed. In an early thread on varnish-misc in February 2008 I concluded that reducing thread_pool_max to well below the default value (to 16 threads/CPU) was instrumental in attaining maximum performance on high-hit-ratio workloads. (This was with Varnish 1.1; things may have changed since then but the theory remains.) Funny how there's always a tradeoff: Overcommit -> page-thrashing death Undercommit -> context-switch death :) --Michael From michael at dynamine.net Tue Jan 19 00:45:57 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Mon, 18 Jan 2010 16:45:57 -0800 Subject: Varnish use for purely binary files In-Reply-To: <84880.1263861316@critter.freebsd.dk> References: <84880.1263861316@critter.freebsd.dk> Message-ID: On Jan 18, 2010, at 4:35 PM, Poul-Henning Kamp wrote: > In message <97F066DD-4044-46A7-B3E1-34CE928E81F3 at slide.com>, Ken Brownfield wri > tes: > >> Ironically and IMHO, one of the barriers to Varnish scalability >> is its thread model, though this problem strikes in the thousands >> of connections. > > It's only a matter of work to pool slow clients in Varnish into > eventdriven writer clusters, but so far I have not seen a > credible argument for doing it. > > A thread is pretty cheap to have around if it doesn't do anything, > and the varnish threads typically do not do anything during the > delivery-phase: They are stuck in the kernel in a writev(2) > or sendfile(2) system call. Does Varnish already try to utilize CPU caches efficiently by employing some sort of LIFO thread reuse policy or by pinning thread pools to specific CPUs? If not, there might be some opportunity for optimization there. --Michael From pubcrawler.com at gmail.com Tue Jan 19 01:11:58 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Mon, 18 Jan 2010 20:11:58 -0500 Subject: Varnish use for purely binary files In-Reply-To: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> Message-ID: <4c3149fb1001181711y14ff4c3bpf9e52f53b269fe65@mail.gmail.com> Wanted in inject another discussion heady item into this thread and see if the idea is confirmed in other folks current architecture. Sorry in advance for being verbose. Often web servers (my experience) are smaller servers, less RAM and fewer CPUs than the app servers and databases. A typical webserver might be a 2GB or 4GB machine with a dual CPU. But, the disk storage on any given webserver will far exceed the RAM in the machine. This means disk IO even when attempting to cache as much as possible in a webserver due to the limited RAM. In this "normal" web server size model, simply plugging a bigger RAM Varnish in upstream means less disk IO, faster web servers, less memory consumption managing threads, etc. This is well proven basic Varnish adopter model. Here's a concept that is not specific to the type of data being stored in Varnish: With some additional hashing in the mix, you could limit your large Varnish cache server to the very high repetitively accessed items and use the hash to go to the backend webservers where ideally you hit a smaller Varnish instance with the item cached on the 2-4GB webserver downriver and have it talk to the webserver directly on localhost if it didn't have the data. Anyone doing anything remotely like this? Lots of big RAM installations for Varnish. I like the Google or mini Google model of many smaller machines distributing the load. Seem feasible? 2-4GB machines are very affordable compared to the 16GB and above machines. Certainly more collective horsepower with the individual smaller servers - perhaps a better performance-per-watt also (another one of my interests). Thanks again everyone. I enjoy hearing about all the creative ways folks are using Varnish in their very different environments. The more scenarios for Varnish, the more adoption and ideally the more resources and expertise that become available for future development. There is some sort of pruning of the cache that is beyond me at the moment to keep Varnish from being overpopulated with non used items and similarly from wasting RAM on the webservers for such. Simple concept and probably very typical. Oh yeah, plus it scales horizontally on lower cost dummy server nodes. From martin.boer at netclever.nl Tue Jan 19 08:12:09 2010 From: martin.boer at netclever.nl (Martin Boer) Date: Tue, 19 Jan 2010 09:12:09 +0100 Subject: feature request cache refresh Message-ID: <4B556959.1000106@netclever.nl> Hi all, I would like to see the following feature in varnish; during the grace period varnish will serve requests from the cache but simultaniously does a backend request and stores the new object. As varnish is much faster than backend servers this will give the end user the fastest experience possible and at the same time dynamic web pages will be both dynamicish and cached at the same time. If anyone has a workable workaround to achieve the same results I'm very interested. The reason I would like this feature is because our webshop has almost hourly changing prices. This means we can't cache all related pages (or not for very long) and at the same time that the backends receive a requests they have to rebuild data from several databases which is slow. Regards, Martin From rtshilston at gmail.com Tue Jan 19 08:22:46 2010 From: rtshilston at gmail.com (Rob S) Date: Tue, 19 Jan 2010 08:22:46 +0000 Subject: feature request cache refresh In-Reply-To: <4B556959.1000106@netclever.nl> References: <4B556959.1000106@netclever.nl> Message-ID: <4B556BD6.5050001@gmail.com> Martin Boer wrote: > I would like to see the following feature in varnish; > during the grace period varnish will serve requests from the cache but > simultaniously does a backend request and stores the new object. > This would also be of interest to us. I'm not sure if it's best to have a parameter to vary the behaviour of 'grace', or to have an additional parameter for "max age of stale content to serve". > If anyone has a workable workaround to achieve the same results I'm very > interested. > Anyone? Rob From phk at phk.freebsd.dk Tue Jan 19 08:46:27 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 08:46:27 +0000 Subject: Varnish use for purely binary files In-Reply-To: Your message of "Mon, 18 Jan 2010 16:45:57 PST." Message-ID: <86335.1263890787@critter.freebsd.dk> In message , "Michael S. Fis cher" writes: >Does Varnish already try to utilize CPU caches efficiently by employing = >some sort of LIFO thread reuse policy or by pinning thread pools to = >specific CPUs? If not, there might be some opportunity for optimization = >there. You should really read the varnish_perf.pdf slides I linked to yesteday... -- 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 h.paulissen at qbell.nl Tue Jan 19 10:38:22 2010 From: h.paulissen at qbell.nl (Henry Paulissen) Date: Tue, 19 Jan 2010 11:38:22 +0100 Subject: feature request cache refresh In-Reply-To: <4B556BD6.5050001@gmail.com> References: <4B556959.1000106@netclever.nl> <4B556BD6.5050001@gmail.com> Message-ID: <000301ca98f3$8659fe00$930dfa00$@paulissen@qbell.nl> As far as I know, varnish does this by default? To expire content you have to serve proper expire and last-modified headers. Some (dynamic) applications sets inproper or even non of those headers at all. =================== @Martin Boer (DTCH) Neem ff contact met mij op via email. Ik heb redelijk wat ervarting opgeboewd met varnish en kan je mogelijk van dienst zijn. =================== Reagrds, Henry -----Original Message----- From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Rob S Sent: dinsdag 19 januari 2010 9:23 To: Martin Boer Cc: Varnish misc Subject: Re: feature request cache refresh Martin Boer wrote: > I would like to see the following feature in varnish; > during the grace period varnish will serve requests from the cache but > simultaniously does a backend request and stores the new object. > This would also be of interest to us. I'm not sure if it's best to have a parameter to vary the behaviour of 'grace', or to have an additional parameter for "max age of stale content to serve". > If anyone has a workable workaround to achieve the same results I'm very > interested. > Anyone? Rob _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From antonivillalonga at dorna.com Tue Jan 19 12:37:07 2010 From: antonivillalonga at dorna.com (Antoni Villalonga) Date: Tue, 19 Jan 2010 13:37:07 +0100 Subject: Cache invalidation (not PURGE) Message-ID: <20100119123707.GA9217@motogp.com> Hi! I'm looking for a method to invalidate some url. http://example.com/invalidate.html, for example. If I PURGE using 'purge()' function and 2 diferent users GET "http://example.com/invalidate.html" at time, varnish ask for the url to the backend server twice. When a url cache expires, and 2 diferent users GET the url at time, varnish ask only one time to the backend and serve an expired version to the "second" user. (yes, we use "grace time"). In short, I also want to use "grace time" when urls are "purged". Thanks! From quasirob at googlemail.com Tue Jan 19 13:25:38 2010 From: quasirob at googlemail.com (Rob Ayres) Date: Tue, 19 Jan 2010 13:25:38 +0000 Subject: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure? In-Reply-To: <4B508E8B.7030906@gmail.com> References: <4B508E8B.7030906@gmail.com> Message-ID: 2010/1/15 Rob S > John Norman wrote: > > Folks, > > > > A couple more questions: > > > > (1) Are they any good strategies for splitting load across Varnish > > front-ends? Or is the common practice to have just one Varnish server? > > > > (2) How do people avoid single-point-of-failure for Varnish? Do people > > run Varnish on two servers, amassing similar local caches, but put > > something in front of the two Varnishes? Or round-robin-DNS? > > > We're running with two instances and round-robin DNS. The varnish > servers are massively underused, and splitting the traffic also means we > get half the hit rate. But it avoids the SPOF. > > Is anyone running LVS or similar in front of Varnish and can share their > experience? > We run two varnish servers behind a netscaler load balancer to eliminate SPOF. Works fine, as the previous poster mentions you lower your hit rate - but not as much as I expected. As far as load is concerned, we could easily use just one server and it would probably still be 99% idle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From h.paulissen at qbell.nl Tue Jan 19 15:04:14 2010 From: h.paulissen at qbell.nl (Henry Paulissen) Date: Tue, 19 Jan 2010 16:04:14 +0100 Subject: Feature REQ: Match header value against acl Message-ID: <002501ca9918$aa519aa0$fef4cfe0$@paulissen@qbell.nl> I noticed it is impossible to match a header value against a acl. What I tried to do is as follow: if ( !req.http.X-Forwarded-For ~ purge ) { remove req.http.Cache-Control; } This is to reduce the number of forced refreshes due to bots. And normally you would use client.ip (what works with acl's), but I have a load balancer in front of varnish. So all client ip addresses are in the X-Forwarded-For header. A dirty quick fix for now is to use regex, but this gives a lot of extra code (as I have to match against serval ip's). Current version: varnish-trunk SVN 4444 Regards, Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at dynamine.net Tue Jan 19 16:17:17 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Tue, 19 Jan 2010 08:17:17 -0800 Subject: Varnish use for purely binary files In-Reply-To: <86335.1263890787@critter.freebsd.dk> References: <86335.1263890787@critter.freebsd.dk> Message-ID: On Jan 19, 2010, at 12:46 AM, Poul-Henning Kamp wrote: > In message , "Michael S. Fis > cher" writes: > >> Does Varnish already try to utilize CPU caches efficiently by employing = >> some sort of LIFO thread reuse policy or by pinning thread pools to = >> specific CPUs? If not, there might be some opportunity for optimization = >> there. > > You should really read the varnish_perf.pdf slides I linked to yesteday... They appear to only briefly mention the LIFO issue (in one bullet point toward the end), and do not discuss the CPU affinity issue. --Michael From phk at phk.freebsd.dk Tue Jan 19 17:24:25 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 17:24:25 +0000 Subject: Feature REQ: Match header value against acl In-Reply-To: Your message of "Tue, 19 Jan 2010 16:04:14 +0100." <002501ca9918$aa519aa0$fef4cfe0$@paulissen@qbell.nl> Message-ID: <1726.1263921865@critter.freebsd.dk> In message <002501ca9918$aa519aa0$fef4cfe0$@paulissen at qbell.nl>, "Henry Pauliss en" writes: >What I tried to do is as follow: > >if ( !req.http.X-Forwarded-For ~ purge ) { I have decided what the syntax for this will be, but I have still not implemented it. In general all type conversions, except to string, will be explicit and provide a default, so the above would become: if (!IP(req.http.X-Forwarded-For, 127.0.0.2) ~ purge) { ... If the X-F-F header is not there, or does not contain an IP#, 127.0.0.2 will be used instead. -- 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 h.paulissen at qbell.nl Tue Jan 19 17:54:19 2010 From: h.paulissen at qbell.nl (Henry Paulissen) Date: Tue, 19 Jan 2010 18:54:19 +0100 Subject: Feature REQ: Match header value against acl In-Reply-To: <1726.1263921865@critter.freebsd.dk> References: Your message of "Tue, 19 Jan 2010 16:04:14 +0100." <002501ca9918$aa519aa0$fef4cfe0$@paulissen@qbell.nl> <1726.1263921865@critter.freebsd.dk> Message-ID: <003401ca9930$71b1ad30$55150790$@paulissen@qbell.nl> Nice.... When will this be in trunk? Regards, @Paul, sorry... forgot to include varnish-misc -----Oorspronkelijk bericht----- Van: phk at critter.freebsd.dk [mailto:phk at critter.freebsd.dk] Namens Poul-Henning Kamp Verzonden: dinsdag 19 januari 2010 18:24 Aan: Henry Paulissen CC: varnish-misc at projects.linpro.no Onderwerp: Re: Feature REQ: Match header value against acl In message <002501ca9918$aa519aa0$fef4cfe0$@paulissen at qbell.nl>, "Henry Pauliss en" writes: >What I tried to do is as follow: > >if ( !req.http.X-Forwarded-For ~ purge ) { I have decided what the syntax for this will be, but I have still not implemented it. In general all type conversions, except to string, will be explicit and provide a default, so the above would become: if (!IP(req.http.X-Forwarded-For, 127.0.0.2) ~ purge) { ... If the X-F-F header is not there, or does not contain an IP#, 127.0.0.2 will be used instead. -- 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 michael at dynamine.net Tue Jan 19 18:26:22 2010 From: michael at dynamine.net (Michael Fischer) Date: Tue, 19 Jan 2010 10:26:22 -0800 Subject: Handling of cache-control In-Reply-To: <84910.1263861424@critter.freebsd.dk> References: <84910.1263861424@critter.freebsd.dk> Message-ID: On Mon, Jan 18, 2010 at 4:37 PM, Poul-Henning Kamp wrote: > In message , "Michael > S. Fis > cher" writes: > >On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: > > >> My suggestion is to also look at Cache-control: no-cache, possibly also > >> private and no-store and obey those. > > > >Why wasn't it doing it all along? > > Because we wanted to give the backend a chance to tell Varnish one > thing with respect to caching, and the client another. > > I'm not saying we hit the right decision, and welcome any consistent, > easily explainable policy you guys can agree on. Well, the problem is that application engineers who understand what that header does have a reasonable expectation that the caches will obey them, and so I think Vanish should honor them as Squid does. Otherwise surprising results will occur when the caching platform is changed. Cache-Control: private certainly meets the goal you stated, at least insofar as making Varnish behave differently than the client -- it states that the client can cache, but Varnish (as an intermediate cache) cannot. I assume, however, that some engineers want a way to do the opposite - to inform Varnish that it can cache, but inform the client that it cannot. Ordinarily I'd think this is not a very good idea, since you almost always want to keep the cached copy as close to the user as possible. But I guess there are some circumstances where an engineer would want to preload a cache with prerendered data that is expensive to generate, and, also asynchronously force updates by flushing stale objects with a PURGE or equivalent. In that case the cache TTL would be very high, but not necessarily meaningful. I'm not sure it makes sense to extend the Cache-Control: header here, because there could be secondary intermediate caches downstream that are not under the engineer's control; so we need a way to inform only authorized intermediate caches that they should cache the response with the specified TTL. One way I've seen to accomplish this goal is to inject a custom header in the response, but we need to ensure it is either encrypted (so that non-authorized caches can't see it -- but this could be costly in terms of CPU) or removed by the last authorized intermediate cache as the response is passed back downstream. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at 7fff.com Tue Jan 19 19:52:42 2010 From: john at 7fff.com (John Norman) Date: Tue, 19 Jan 2010 14:52:42 -0500 Subject: Health check -- just connect, or full response? Message-ID: Folks, For the health check (or, ahem, "backend probe," as the docs has it -- ouch!), does "health" constitute ability to connect? Or does it check for a 200? Or get an entire page and verify that it's the right number of bytes . . . ? Or . . . ? In short, what constitutes a successful probe? I'm using .url not .request John From slink at schokola.de Tue Jan 19 20:09:44 2010 From: slink at schokola.de (Nils Goroll) Date: Tue, 19 Jan 2010 21:09:44 +0100 Subject: Time to replace the hit ratio with something more intuitive? Message-ID: <4B561188.8090408@schokola.de> Hi, in http://varnish.projects.linpro.no/ticket/613 I have suggested to add a measure to varnishstat which I thought could be called the "efficiency ratio". Tollef has commented that we'd need the community's (YOUR) opinion on this: The varnishstat cache hit rate basically gives a ratio for how many requests being directed to the cache component of varnish have been answered from it. It does not say anything about the number of requests being passed onto the backend for whatever reason. So it is possible to see cache hit rates of 0.9999 (99.99%) but still 99% of the client requests hit your backend, if only 1% of the requests qualify for being served from the cache. I am suggesting to amend (or replace ?) this figure by a ratio of client requests being handled by the cache by total number of requests. In other words, a measure for how many of the client requests do not result in a backend request. My experience is that this figure is far more important, because cache users will mostly be interested in saving backend requests. The cache hit rate is probably of secondary importance, and it can be confusing to get a high cache hit rate while still (too) many requests are hitting the backend. Here's how the two figures look like on a production system: Hitrate ratio: 10 100 1000 Hitrate avg: 0.9721 0.9721 0.9731 Efficiency ratio: 10 100 1000 Efficiency avg: 0.9505 0.9522 0.9533 55697963 200.97 256.93 Client connections accepted 402992210 1518.81 1858.98 Client requests received 390022582 1471.82 1799.15 Cache hits 1549 0.00 0.01 Cache hits for pass 9053637 22.00 41.76 Cache misses Now it's up to you, what do you think about this? Nils From john at 7fff.com Tue Jan 19 20:26:49 2010 From: john at 7fff.com (John Norman) Date: Tue, 19 Jan 2010 15:26:49 -0500 Subject: In management port: vcl.discard Message-ID: Folks, I've been loading new VCL files with a timestamp on the name (e.g., cfg100119151756). vcl.discard is great if you know the name. But it could be very useful to have a command such as "vcl.purge" to get rid of all configs except for the active one. John From rtshilston at gmail.com Tue Jan 19 20:31:14 2010 From: rtshilston at gmail.com (Rob S) Date: Tue, 19 Jan 2010 20:31:14 +0000 Subject: Handling of cache-control In-Reply-To: References: <84910.1263861424@critter.freebsd.dk> Message-ID: <4B561692.7000906@gmail.com> Michael Fischer wrote: > On Mon, Jan 18, 2010 at 4:37 PM, Poul-Henning Kamp > wrote: > > In message >, > "Michael S. Fis > cher" writes: > >On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: > > >> My suggestion is to also look at Cache-control: no-cache, > possibly also > >> private and no-store and obey those. > > > >Why wasn't it doing it all along? > > Because we wanted to give the backend a chance to tell Varnish one > thing with respect to caching, and the client another. > > I'm not saying we hit the right decision, and welcome any consistent, > easily explainable policy you guys can agree on. > > > Well, the problem is that application engineers who understand what > that header does have a reasonable expectation that the caches will > obey them, and so I think Vanish should honor them as Squid does. > Otherwise surprising results will occur when the caching platform is > changed. > > Cache-Control: private certainly meets the goal you stated, at least > insofar as making Varnish behave differently than the client -- it > states that the client can cache, but Varnish (as an intermediate > cache) cannot. > > I assume, however, that some engineers want a way to do the opposite - > to inform Varnish that it can cache, but inform the client that it > cannot. Ordinarily I'd think this is not a very good idea, since you > almost always want to keep the cached copy as close to the user as > possible. But I guess there are some circumstances where an engineer > would want to preload a cache with prerendered data that is expensive > to generate, and, also asynchronously force updates by flushing stale > objects with a PURGE or equivalent. In that case the cache TTL would > be very high, but not necessarily meaningful. > > I'm not sure it makes sense to extend the Cache-Control: header here, > because there could be secondary intermediate caches downstream that > are not under the engineer's control; so we need a way to inform only > authorized intermediate caches that they should cache the response > with the specified TTL. > > One way I've seen to accomplish this goal is to inject a custom header > in the response, but we need to ensure it is either encrypted (so that > non-authorized caches can't see it -- but this could be costly in > terms of CPU) or removed by the last authorized intermediate cache as > the response is passed back downstream. > > --Michael Michael, You've obviously got some strong views about varnish, as we've all seen from the mailing list over the past few days! When we deployed varnish, we did so in front of applications that weren't prepared to have a cache in front of them. Accordingly, we disabled all caching on HTML and RSS type content in Varnish, and instead just cached CSS / JS / images. This was a good outcome because we could stop using round robin DNS (which is a bit questionable, imho, if it includes more than two or three hosts) to the web servers, and instead just point 2 A records at Varnish. We elected to use X-External-Cache-Control AND X-Internal-TTL as a headers that we'd set in Varnish-aware applications. So, old apps that emit cache-control headers are completely uncached by Varnish), and new-apps can benefit to a certain degree of caching by Varnish. PHK's plans for 2010 will enable us to fully exploit our X-Internal-TTL headers because it'll be able to parse TTL values out of headers. In the meantime, these are hard-set in Varnish to a value that's appropriate for our apps. The X-External-Cache-Control is then presented as Cache-Control to public HTTP requests. This describes how we've chosen to deploy varnish, without causing our application developers huge headaches. In parallel, we've changed many of our sites to use local cookies+javascript to add personalisation to the most popular pages. Overall, deploying Varnish has seen a big reduction in back end requests, PLUS the ability to load balance over a large pool whilst still implementing sticky-sessions where our apps still need them. Varnish is, as the name suggests, a lovely layer in front of our platform which makes it perform better. Now, to answer your points: 1) Application developers to be aware of caching headers: I'd disagree here. Our approach is to use code libraries to deliver functionality to the developers which the sysadmins can maintain. There's always some overlap here, but we're comfortable with our position. We're a PHP company, and so we've a class that's used statically, with methods such as Cacheability::noCache(), Cacheability::setExternalExpiryTime($secs), and Cacheability::setInternalExpiryTime($secs), as well as Cacheability::purgeCache($path). Just as, I'm sure, your developers are using abstraction layers for database access, then they could use a similar approach for cacheability. 2) Preloading the cache: This is something we do. We set InternalExpiryTime to be high, and ExternalExpiryTime to be very low. Then, when there's a change, the app calls a purge. 3) Downstream caches: You either have to decide if the caches are under your control, or are public. You should make the edge of your estate behave as you want, and let third parties worry about themselves. Get your outer most caches to strip all headers other than those you want retained. In summary, I think you need to partition what's done by your sysadmins and what's the job of your developers. I also think it'd help me (and probably the mailing list) if you could give a little more detail about the site(s) you're running behind Varnish, and your main troubles are with your architecture / why you thought Varnish would help. (For the information of others, we're predominantly using Varnish to balance traffic between a pool of servers that deliver a news website. Combined with memcache and gluster, Varnish works well as a frontend to the estate. Rob From darryl.dixon at winterhouseconsulting.com Tue Jan 19 21:05:07 2010 From: darryl.dixon at winterhouseconsulting.com (Darryl Dixon - Winterhouse Consulting) Date: Wed, 20 Jan 2010 10:05:07 +1300 (NZDT) Subject: Time to replace the hit ratio with something more intuitive? In-Reply-To: <4B561188.8090408@schokola.de> References: <4B561188.8090408@schokola.de> Message-ID: <64290.58.28.124.90.1263935107.squirrel@services.directender.co.nz> > Hi, > > in http://varnish.projects.linpro.no/ticket/613 I have suggested to add a > measure to varnishstat which I thought could be called the "efficiency > ratio". > > Here's how the two figures look like on a production system: > > Hitrate ratio: 10 100 1000 > Hitrate avg: 0.9721 0.9721 0.9731 > Efficiency ratio: 10 100 1000 > Efficiency avg: 0.9505 0.9522 0.9533 > > 55697963 200.97 256.93 Client connections accepted > 402992210 1518.81 1858.98 Client requests received > 390022582 1471.82 1799.15 Cache hits > 1549 0.00 0.01 Cache hits for pass > 9053637 22.00 41.76 Cache misses > > > Now it's up to you, what do you think about this? +1 regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com From michael at dynamine.net Tue Jan 19 21:09:16 2010 From: michael at dynamine.net (Michael Fischer) Date: Tue, 19 Jan 2010 13:09:16 -0800 Subject: Time to replace the hit ratio with something more intuitive? In-Reply-To: <4B561188.8090408@schokola.de> References: <4B561188.8090408@schokola.de> Message-ID: On Tue, Jan 19, 2010 at 12:09 PM, Nils Goroll wrote: > The varnishstat cache hit rate basically gives a ratio for how many > requests > being directed to the cache component of varnish have been answered from > it. It > does not say anything about the number of requests being passed onto the > backend > for whatever reason. So it is possible to see cache hit rates of 0.9999 > (99.99%) > but still 99% of the client requests hit your backend, if only 1% of the > requests qualify for being served from the cache. > I am suggesting to amend (or replace ?) this figure by a ratio of client > requests being handled by the cache by total number of requests. In other > words, > a measure for how many of the client requests do not result in a backend > request. I vote for the replacement option. In my view, the ratio should be (total requests)/(requests satisfied from cache). --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtshilston at gmail.com Tue Jan 19 21:40:03 2010 From: rtshilston at gmail.com (Rob S) Date: Tue, 19 Jan 2010 21:40:03 +0000 Subject: Time to replace the hit ratio with something more intuitive? In-Reply-To: References: <4B561188.8090408@schokola.de> Message-ID: <4B5626B3.2090409@gmail.com> Michael Fischer wrote: > On Tue, Jan 19, 2010 at 12:09 PM, Nils Goroll > wrote: > > I am suggesting to amend (or replace ?) this figure by a ratio of > client > requests being handled by the cache by total number of requests. > In other words, > a measure for how many of the client requests do not result in a > backend request. > > > I vote for the replacement option. In my view, the ratio should be > (total requests)/(requests satisfied from cache). That'd give odd figures (eg 1.25), when you'd expect to see 0.8. Can we flip it the other way up? I'd also caution against replacing, as people may have monitoring against the old figures... Rob From ric at digitalmarbles.com Tue Jan 19 21:48:23 2010 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Tue, 19 Jan 2010 13:48:23 -0800 Subject: [varnish] Re: Handling of cache-control In-Reply-To: <84910.1263861424@critter.freebsd.dk> References: <84910.1263861424@critter.freebsd.dk> Message-ID: <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> On Jan 18, 2010, at 4:37 PM, Poul-Henning Kamp wrote: > In message , > "Michael S. Fis > cher" writes: >> On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: > >>> My suggestion is to also look at Cache-control: no-cache, possibly >>> also >>> private and no-store and obey those. >> >> Why wasn't it doing it all along? > > Because we wanted to give the backend a chance to tell Varnish one > thing with respect to caching, and the client another. > > I'm not saying we hit the right decision, and welcome any consistent, > easily explainable policy you guys can agree on. IMHO, the private token should be added to the list that Varnish supports out-of-the-box as there is probably a very good reason why the backend wants to keep private responses out of any shared caches. I'm ambivalent about the others. The no-store and no-cache tokens can be a problem for IE in certain usecases so I try to discourage their use. Instead I just set maxage=0 with no etag/lastmodified which for most practical cases is pretty much equivalent. In practice, I usually add all three tokens (private, no-store, no-cache) to vcl anyway just to cover my bases. Other than the private token, the other thing I used to do to tell Varnish and clients to cache differently is to attach a special header like X-CacheInVarnishOnly or some such (support in Varnish for Surrogate-Control would be a better solution). But recently, I came across another strategy. As far as I can tell, there is no good usecase for a non-zero s-maxage token outside your reverse-proxy. So now I just use the s-maxage token to tell Varnish how to cache and then strip it from the response headers (or reset to s-maxage=0) to avoid contaminating any forward proxies downstream. Cheers, Ricardo Newbery http://digitalmarbles.com From michael at dynamine.net Tue Jan 19 21:50:53 2010 From: michael at dynamine.net (Michael Fischer) Date: Tue, 19 Jan 2010 13:50:53 -0800 Subject: Time to replace the hit ratio with something more intuitive? In-Reply-To: <4B5626B3.2090409@gmail.com> References: <4B561188.8090408@schokola.de> <4B5626B3.2090409@gmail.com> Message-ID: On Tue, Jan 19, 2010 at 1:40 PM, Rob S wrote: > Michael Fischer wrote: > > On Tue, Jan 19, 2010 at 12:09 PM, Nils Goroll > slink at schokola.de>> wrote: >> >> I am suggesting to amend (or replace ?) this figure by a ratio of >> client >> requests being handled by the cache by total number of requests. >> In other words, >> a measure for how many of the client requests do not result in a >> backend request. >> >> >> I vote for the replacement option. In my view, the ratio should be (total >> requests)/(requests satisfied from cache). >> > That'd give odd figures (eg 1.25), when you'd expect to see 0.8. Can we > flip it the other way up? > Oops! Yes. I'd also caution against replacing, as people may have monitoring against > the old figures... > Well, under the current regime, the figures may lead to a false sense of complacency since the hit ratio may be falsely high. If changing it causes additional alerts to be raised, they probably needed to know all along. :) --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Jan 19 21:57:20 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 19 Jan 2010 21:57:20 +0000 Subject: Health check -- just connect, or full response? In-Reply-To: Your message of "Tue, 19 Jan 2010 14:52:42 EST." Message-ID: <3053.1263938240@critter.freebsd.dk> In message , John No rman writes: >Folks, > >For the health check (or, ahem, "backend probe," as the docs has it -- >ouch!), does "health" constitute ability to connect? > >Or does it check for a 200? It checks 200 -- 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 michael at dynamine.net Tue Jan 19 22:03:05 2010 From: michael at dynamine.net (Michael Fischer) Date: Tue, 19 Jan 2010 14:03:05 -0800 Subject: [varnish] Re: Handling of cache-control In-Reply-To: <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> References: <84910.1263861424@critter.freebsd.dk> <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> Message-ID: On Tue, Jan 19, 2010 at 1:48 PM, Ricardo Newbery wrote: Other than the private token, the other thing I used to do to tell > Varnish and clients to cache differently is to attach a special header > like X-CacheInVarnishOnly or some such (support in Varnish for > Surrogate-Control would be a better solution). But recently, I came > across another strategy. As far as I can tell, there is no good > usecase for a non-zero s-maxage token outside your reverse-proxy. So > now I just use the s-maxage token to tell Varnish how to cache and > then strip it from the response headers (or reset to s-maxage=0) to > avoid contaminating any forward proxies downstream. This seems logical to me. Are there any drawbacks to using Surrogate-Control? --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From ric at digitalmarbles.com Tue Jan 19 22:04:00 2010 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Tue, 19 Jan 2010 14:04:00 -0800 Subject: [varnish] Re: Handling of cache-control In-Reply-To: References: <84910.1263861424@critter.freebsd.dk> Message-ID: On Jan 19, 2010, at 10:26 AM, Michael Fischer wrote: > Cache-Control: private certainly meets the goal you stated, at least > insofar as making Varnish behave differently than the client -- it > states that the client can cache, but Varnish (as an intermediate > cache) cannot. I'm being pedantic but... technically I believe private is just ignored by browsers, which amounts to the same thing :-) > I assume, however, that some engineers want a way to do the opposite > - to inform Varnish that it can cache, but inform the client that it > cannot. Ordinarily I'd think this is not a very good idea, since > you almost always want to keep the cached copy as close to the user > as possible. But I guess there are some circumstances where an > engineer would want to preload a cache with prerendered data that is > expensive to generate, and, also asynchronously force updates by > flushing stale objects with a PURGE or equivalent. In that case the > cache TTL would be very high, but not necessarily meaningful. > > I'm not sure it makes sense to extend the Cache-Control: header > here, because there could be secondary intermediate caches > downstream that are not under the engineer's control; so we need a > way to inform only authorized intermediate caches that they should > cache the response with the specified TTL. > > One way I've seen to accomplish this goal is to inject a custom > header in the response, but we need to ensure it is either encrypted > (so that non-authorized caches can't see it -- but this could be > costly in terms of CPU) or removed by the last authorized > intermediate cache as the response is passed back downstream. Storing responses only in your reverse-proxy and out of the browser cache is a common usecase for a CMS. Otherwise, a content change may not propagate to your users unless you force them all to do conditional requests to your backend. A custom header works. So would the Surrogate-Control header if Varnish supported it -- this is exactly the usecase this header was intended for. But these days, I've begun using s-maxage as a surrogate for Surrogate-Control and just stripping it from the final response -- not as flexible as Surrogate-Control but it does everything I need right now. Regards, Ricardo Newbery http://digitalmarbles.com From ric at digitalmarbles.com Tue Jan 19 22:05:54 2010 From: ric at digitalmarbles.com (Ricardo Newbery) Date: Tue, 19 Jan 2010 14:05:54 -0800 Subject: [varnish] Re: [varnish] Re: Handling of cache-control In-Reply-To: References: <84910.1263861424@critter.freebsd.dk> <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> Message-ID: <670ABC7B-093A-4687-90D2-C1B50038F082@digitalmarbles.com> On Jan 19, 2010, at 2:03 PM, Michael Fischer wrote: > On Tue, Jan 19, 2010 at 1:48 PM, Ricardo Newbery > wrote: > > Other than the private token, the other thing I used to do to tell > Varnish and clients to cache differently is to attach a special header > like X-CacheInVarnishOnly or some such (support in Varnish for > Surrogate-Control would be a better solution). But recently, I came > across another strategy. As far as I can tell, there is no good > usecase for a non-zero s-maxage token outside your reverse-proxy. So > now I just use the s-maxage token to tell Varnish how to cache and > then strip it from the response headers (or reset to s-maxage=0) to > avoid contaminating any forward proxies downstream. > > This seems logical to me. Are there any drawbacks to using > Surrogate-Control? > > --Michael Not that I'm aware of. Except that only Squid 3.x supports it right now ;-) Cheers, Ricardo Newbery http://digitalmarbles.com From tfheen at redpill-linpro.com Wed Jan 20 08:33:08 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 20 Jan 2010 09:33:08 +0100 Subject: Release schedule for saint mode. In-Reply-To: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> (pablort's message of "Mon, 18 Jan 2010 18:47:30 -0200") References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> Message-ID: <878wbtqipn.fsf@qurzaw.linpro.no> ]] pablort | Anybody knows what's the plan to release saint mode ? :D It's in trunk. It's not going to be backported to 2.0 itself as some of its requirements are not in 2.0 and considered hard to backport without backporting significant changes from trunk leading to what I believe is an unacceptable risk of breakages. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From bedis9 at gmail.com Wed Jan 20 09:19:24 2010 From: bedis9 at gmail.com (Bedis 9) Date: Wed, 20 Jan 2010 10:19:24 +0100 Subject: [varnish] Re: [varnish] Re: Handling of cache-control In-Reply-To: <670ABC7B-093A-4687-90D2-C1B50038F082@digitalmarbles.com> References: <84910.1263861424@critter.freebsd.dk> <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> <670ABC7B-093A-4687-90D2-C1B50038F082@digitalmarbles.com> Message-ID: <30b80c9f1001200119p1e69b0b3jb20f5714fc574e0e@mail.gmail.com> Hi, Netcache devices had the X-Accel-Cache-Control headers in order to allow an origin server to setup different Cache-Control parameters for the cache and the end-user. The netcache will follow the X-Accel-Cache-Control while the end user will follow the Cache-Control. I've a few customer using this, mainly for sports events where "live" is the key. They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is set to no-cache. That way, all the load generated by thousends of request per second for "live" stuff is offloaded to the cache layer. Only a few request goes back to the origin. I was able to reproduce such behavior with the following inline C: sub vcl_fetch { [...] # Check if X-Accel-Cache-Control exists and follow it if (obj.http.X-Accel-Cache-Control) { C{ char *cache; int max_age = 0; cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:"); if(cache) { char *s = NULL; /* Looking for max-age */ if (s = strstr(cache, "max-age=")) { s+=8; max_age = strtoul(s, 0, 0); if (max_age) { VRT_l_obj_ttl(sp, max_age); } } } }C unset obj.http.X-Accel-Cache-Control; } # Cache-Control and Pragma headers preventing caching if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)")) { pass; } } [...] } Maybe it can be useful to somebody else :) cheers From tfheen at redpill-linpro.com Wed Jan 20 09:42:22 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 20 Jan 2010 10:42:22 +0100 Subject: feature request cache refresh In-Reply-To: <4B556959.1000106@netclever.nl> (Martin Boer's message of "Tue, 19 Jan 2010 09:12:09 +0100") References: <4B556959.1000106@netclever.nl> Message-ID: <871vhlqfi9.fsf@qurzaw.linpro.no> ]] Martin Boer | If anyone has a workable workaround to achieve the same results I'm very | interested. | | The reason I would like this feature is because our webshop has almost | hourly changing prices. This means we can't cache all related pages (or | not for very long) and at the same time that the backends receive a | requests they have to rebuild data from several databases which is slow. You could just purge the pages that refer to a given product by doing something like: - Make sure all products on a page are listed in a X-Products header, so you have something like: X-Products: 123, 456, 789. - When the price of product 123 changes, issue a purge obj.http.x-products ~ 123 - Magically, all relevant product pages should be purged. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 20 09:43:52 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 20 Jan 2010 10:43:52 +0100 Subject: feature request cache refresh In-Reply-To: <4B556BD6.5050001@gmail.com> (Rob S.'s message of "Tue, 19 Jan 2010 08:22:46 +0000") References: <4B556959.1000106@netclever.nl> <4B556BD6.5050001@gmail.com> Message-ID: <87wrzdp0vb.fsf@qurzaw.linpro.no> ]] Rob S | Martin Boer wrote: | > I would like to see the following feature in varnish; | > during the grace period varnish will serve requests from the cache but | > simultaniously does a backend request and stores the new object. | > | This would also be of interest to us. I'm not sure if it's best to have | a parameter to vary the behaviour of 'grace', or to have an additional | parameter for "max age of stale content to serve". What is the difference between ?max age of stale content to serve? and grace? I might not be seeing your use case here? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From rtshilston at gmail.com Wed Jan 20 09:53:53 2010 From: rtshilston at gmail.com (Rob S) Date: Wed, 20 Jan 2010 09:53:53 +0000 Subject: feature request cache refresh In-Reply-To: <87wrzdp0vb.fsf@qurzaw.linpro.no> References: <4B556959.1000106@netclever.nl> <4B556BD6.5050001@gmail.com> <87wrzdp0vb.fsf@qurzaw.linpro.no> Message-ID: <4B56D2B1.9090502@gmail.com> Tollef Fog Heen wrote: > ]] Rob S > > | Martin Boer wrote: > | > I would like to see the following feature in varnish; > | > during the grace period varnish will serve requests from the cache but > | > simultaniously does a backend request and stores the new object. > | > > | This would also be of interest to us. I'm not sure if it's best to have > | a parameter to vary the behaviour of 'grace', or to have an additional > | parameter for "max age of stale content to serve". > > What is the difference between ?max age of stale content to serve? and > grace? I might not be seeing your use case here? > > Our experience of grace is that the first client who requests content after expiry is held up talking to the backend, whilst other subsequent clients get delivered the graced stale content. But, if that's not intended, perhaps our config isn't quite right. Rob From tfheen at redpill-linpro.com Wed Jan 20 10:00:26 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 20 Jan 2010 11:00:26 +0100 Subject: Health check -- just connect, or full response? In-Reply-To: <3053.1263938240@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 19 Jan 2010 21:57:20 +0000") References: <3053.1263938240@critter.freebsd.dk> Message-ID: <87ska1p03p.fsf@qurzaw.linpro.no> ]] "Poul-Henning Kamp" | In message , John No | rman writes: | >Folks, | > | >For the health check (or, ahem, "backend probe," as the docs has it -- | >ouch!), does "health" constitute ability to connect? | > | >Or does it check for a 200? | | It checks 200 Actually, it checks for .expected_response (which does default to 200), so you can override it if you need that. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 20 10:14:31 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 20 Jan 2010 11:14:31 +0100 Subject: Time to replace the hit ratio with something more intuitive? In-Reply-To: <4B5626B3.2090409@gmail.com> (Rob S.'s message of "Tue, 19 Jan 2010 21:40:03 +0000") References: <4B561188.8090408@schokola.de> <4B5626B3.2090409@gmail.com> Message-ID: <87ockpozg8.fsf@qurzaw.linpro.no> ]] Rob S | I'd also caution against replacing, as people may have monitoring | against the old figures... Given this number only is displayed in interactive mode and not oneshot mode, people should not be running automated checks against it. Also, as this would be quite confusing to people running 2.0, it'll not be backported. And it'll be marked well in the documentation that the behaviour has changed. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From phk at phk.freebsd.dk Wed Jan 20 10:34:33 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 20 Jan 2010 10:34:33 +0000 Subject: feature request cache refresh In-Reply-To: Your message of "Wed, 20 Jan 2010 09:53:53 GMT." <4B56D2B1.9090502@gmail.com> Message-ID: <42502.1263983673@critter.freebsd.dk> In message <4B56D2B1.9090502 at gmail.com>, Rob S writes: >Our experience of grace is that the first client who requests content >after expiry is held up talking to the backend, whilst other subsequent >clients get delivered the graced stale content. But, if that's not >intended, perhaps our config isn't quite right. That is indeed the correct behaviour. -- 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 rtshilston at gmail.com Wed Jan 20 10:41:33 2010 From: rtshilston at gmail.com (Rob S) Date: Wed, 20 Jan 2010 10:41:33 +0000 Subject: feature request cache refresh In-Reply-To: <42502.1263983673@critter.freebsd.dk> References: <42502.1263983673@critter.freebsd.dk> Message-ID: <4B56DDDD.2020206@gmail.com> Poul-Henning Kamp wrote: > In message <4B56D2B1.9090502 at gmail.com>, Rob S writes: > > >> Our experience of grace is that the first client who requests content >> after expiry is held up talking to the backend, whilst other subsequent >> clients get delivered the graced stale content. But, if that's not >> intended, perhaps our config isn't quite right. >> > > That is indeed the correct behaviour. > Great. So, going back to my original post: > I'm not sure if it's best to have > a parameter to vary the behaviour of 'grace', or to have an additional > parameter for "max age of stale content to serve". If grace stays as it is, then I'd like to have the ability for that "first client who requests content after expiry" to get stale content, and have a parallel process update the cached content. Ro*b* From phk at phk.freebsd.dk Wed Jan 20 10:50:08 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 20 Jan 2010 10:50:08 +0000 Subject: feature request cache refresh In-Reply-To: Your message of "Wed, 20 Jan 2010 10:41:33 GMT." <4B56DDDD.2020206@gmail.com> Message-ID: <49133.1263984608@critter.freebsd.dk> In message <4B56DDDD.2020206 at gmail.com>, Rob S writes: >Poul-Henning Kamp wrote: > > I'm not sure if it's best to have > > a parameter to vary the behaviour of 'grace', or to have an additional > > parameter for "max age of stale content to serve". That is why grace is split in two. You have obj.grace and req.grace, and the minimum of the two is what governs grace mode. >If grace stays as it is, then I'd like to have the ability for that >"first client who requests content after expiry" to get stale content, >and have a parallel process update the cached content. Yes, and since it is my birthday, I'll wish for a pony as well :-) Doing grace the way we did was relatively simple, doing it the way it really should work is not, so that improvement is somewhere in the queue. -- 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 rtshilston at gmail.com Wed Jan 20 10:53:16 2010 From: rtshilston at gmail.com (Rob S) Date: Wed, 20 Jan 2010 10:53:16 +0000 Subject: feature request cache refresh In-Reply-To: <49133.1263984608@critter.freebsd.dk> References: <49133.1263984608@critter.freebsd.dk> Message-ID: <4B56E09C.2040004@gmail.com> Poul-Henning Kamp wrote: > That is why grace is split in two. > You have obj.grace and req.grace, and the minimum of the two is what > governs grace mode. > Thanks for the clarification. I'll do some experimenting, then update the documentation at http://varnish.projects.linpro.no/wiki/Performance > >> If grace stays as it is, then I'd like to have the ability for that >> "first client who requests content after expiry" to get stale content, >> and have a parallel process update the cached content. >> > > Yes, and since it is my birthday, I'll wish for a pony as well :-) > > I hope you have an extra nice day, and that you get some time to relax and do things you want! Best wishes for the year ahead, and thank you for your hard work on Varnish. > Doing grace the way we did was relatively simple, doing it the way > it really should work is not, so that improvement is somewhere in > the queue. > > From a.hongens at netmatch.nl Wed Jan 20 14:29:34 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Wed, 20 Jan 2010 15:29:34 +0100 Subject: comparing 2 headers Message-ID: <4B57134E.8010300@netmatch.nl> Hey, I'm new to Varnish.. We currenly have 4 simple caching balancers running squid+haproxy in front of some large webapps (2000 req/sec, 200Mbit), and I get the feeling we're growing out of Squid.. So I am investigating an in-place replacement of Squid by Varnish. The project looks really great, and the fact that the lead developer is such a FreeBSD guru is really comforting as well ;) And yes, the talk about the 1970's VAX machine approach to software architecture made a good point. I have some questions though. I am used to Squid's way of doing thing, so please forgive me if my questions are too biased to the squid-way of doing things. 1. What will happen when the dataset I want to pass through Varnish is much larger than the Varnish machines could store? I would expect the cache hit ratio to go down, and Varnish to start evicting objects from the cache more frequently. Or will Varnish just crash and burn with a 'cache is full' message? :) The reason I ask this, is we have balancers with 200GB of local storage, and the total amount of data that could be served could theoretically be several terabytes.. I think objects would expire before the cache is full, but just in case... 2. I run the varnishncsa daemon to write to logfile. However, I would really like to see some extra information like whether it was a cache hit or miss, and the last time to byte to the client in the logfile, like squid does in it's access.log. This is really really handy for post-mortem analysis. (We read everything into a database sometimes and let the dba's do their thing.) Is there any way to do this, or can you point me in the right direction? 3. I want to compare some headers, but I'm getting a compile error: Message from VCC-compiler: Expected CSTR got 'server.ip' (program line 266), at (input Line 1279 Pos 24) if (req.http.host == server.ip) { error 200 ok; } -----------------------#########-------------------- Running VCC-compiler failed, exit 1 VCL compilation failed I want to make sure that when I point my browser to http://w.x.y.z, I get a message "200 ok". Am I doing something wrong? I'm using Varnish-2.0.4 from ports by the way. 4. Is there some documentation on what the ReqEnd and StatSess values mean in the varnishlog output? The values seem interesting, but I have no idea what they are. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From l at lrowe.co.uk Wed Jan 20 22:04:23 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed, 20 Jan 2010 22:04:23 +0000 Subject: Varnish use for purely binary files In-Reply-To: <4c3149fb1001181711y14ff4c3bpf9e52f53b269fe65@mail.gmail.com> References: <4c3149fb1001181258p39e13080tff190bf8a7c352ac@mail.gmail.com> <4c3149fb1001181711y14ff4c3bpf9e52f53b269fe65@mail.gmail.com> Message-ID: 2010/1/19 pub crawler : > Wanted in inject another discussion heady item into this thread and > see if the idea is confirmed in other folks current architecture. > Sorry in advance for being verbose. > > Often web servers (my experience) are smaller servers, less RAM and > fewer CPUs than the app servers and databases. ?A typical webserver > might be a 2GB or 4GB machine with a dual CPU. ?But, the disk storage > on any given webserver will far exceed the RAM in the machine. This > means disk IO even when attempting to cache as much as possible in a > webserver due to the limited RAM. > > In this "normal" web server size model, simply plugging a bigger RAM > Varnish in upstream means less disk IO, faster web servers, less > memory consumption managing threads, etc. ?This is well proven basic > Varnish adopter model. > > Here's a concept that is not specific to the type of data being stored > in Varnish: > > With some additional hashing in the mix, you could limit your large > Varnish cache server to the very high repetitively accessed items and > use the hash to go to the backend webservers where ideally you hit a > smaller Varnish instance with the item cached on the 2-4GB webserver > downriver and have it talk to the webserver directly on localhost if > it didn't have the data. Given that you've already taken care of the common requests upstream, you are unlikely to see much benefit from any form of caching - performance will be determined by disk seek time. I suspect you would see much more of a benefit in moving to SSDs for storage. Even cheap MLC SSDs like Intel's X25-M will give great read performance. Laurence From l at lrowe.co.uk Wed Jan 20 22:18:34 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed, 20 Jan 2010 22:18:34 +0000 Subject: Cache invalidation (not PURGE) In-Reply-To: <20100119123707.GA9217@motogp.com> References: <20100119123707.GA9217@motogp.com> Message-ID: 2010/1/19 Antoni Villalonga : > Hi! > > I'm looking for a method to invalidate some url. > http://example.com/invalidate.html, for example. > > If I PURGE using 'purge()' function and 2 diferent users GET > "http://example.com/invalidate.html" at time, varnish ask for the url to the > backend server twice. > > When a url cache expires, and 2 diferent users GET the url at time, varnish ask > only one time to the backend and serve an expired version to the "second" user. > (yes, we use "grace time"). > > In short, I also want to use "grace time" when urls are "purged". There are two ways to invalidate objects, purge(expression); and set obj.ttl = 0; If you use the second form you should get the behaviour you want. Note that if you use Vary: you must purge each vary with a separate request. http://varnish.projects.linpro.no/wiki/VCLExamplePurging Laurence From martin.boer at netclever.nl Thu Jan 21 11:25:16 2010 From: martin.boer at netclever.nl (Martin Boer) Date: Thu, 21 Jan 2010 12:25:16 +0100 Subject: feature request cache refresh In-Reply-To: <49133.1263984608@critter.freebsd.dk> References: <49133.1263984608@critter.freebsd.dk> Message-ID: <4B58399C.9060909@netclever.nl> > Doing grace the way we did was relatively simple, doing it the way > it really should work is not, so that improvement is somewhere in > the queue. > > I can understand that, although personally I could live with a slightly changed version of grace. I'm not saying you should, but just that you could. Well, at least I think it would be a smallish change but I might be wrong. If you'd change it so that varnish would return the stale page also to 'the first user during grace' while retrieving and storing the fresh one it would already do what I need. I would lower the ttl's of the objects and use a longish stale period and be very happy with the result. But I don't know if that would create serious havoc with other people or introduce other problems. Anyway, just a thought. (leaves the room puzzling himzelf) From pablort+varnish at gmail.com Thu Jan 21 18:57:31 2010 From: pablort+varnish at gmail.com (pablort) Date: Thu, 21 Jan 2010 16:57:31 -0200 Subject: Release schedule for saint mode. In-Reply-To: <878wbtqipn.fsf@qurzaw.linpro.no> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> Message-ID: <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> And how about 2.1 ? Any release date on the horizon ? :D On Wed, Jan 20, 2010 at 6:33 AM, Tollef Fog Heen wrote: > ]] pablort > > | Anybody knows what's the plan to release saint mode ? :D > > It's in trunk. It's not going to be backported to 2.0 itself as some of > its requirements are not in 2.0 and considered hard to backport without > backporting significant changes from trunk leading to what I believe is > an unacceptable risk of breakages. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at 7fff.com Thu Jan 21 21:07:37 2010 From: john at 7fff.com (John Norman) Date: Thu, 21 Jan 2010 16:07:37 -0500 Subject: use new VCL -- drops cache? Message-ID: When you switch to a new VCL on the fly (vcl.use config), is the cache dumped? (I think the answer is "no," but I just want to make sure.) (Munin shows a drastic sudden reduction in memory usage -- but I don't think Varnish restarted.) John From plfgoa at gmail.com Fri Jan 22 05:32:07 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Fri, 22 Jan 2010 11:02:07 +0530 Subject: Varnish Prefetch Message-ID: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> Hi, Is prefetch by default enabled in varnish ? I have following in VCL . A value of -30 seconds would mean that the object would be checked 30 seconds before its expiry time is reached to see if its modified on backend ? sub vcl_fetch { set obj.grace = 30s; if (!obj.cacheable) { pass; } if (obj.http.Set-Cookie) { pass; } set obj.prefetch = -30s; deliver; } I see following from varnishlog . What doe that mean ? 26 VCL_info c XID 3904284923: obj.prefetch (-30) less than ttl (-1.26414e+09), ignored. 0 VCL_call - prefetch 0 ExpPick - 3903448954 prefetch Thank you. -Paras -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Fri Jan 22 08:11:32 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 22 Jan 2010 08:11:32 +0000 Subject: use new VCL -- drops cache? In-Reply-To: Your message of "Thu, 21 Jan 2010 16:07:37 EST." Message-ID: <14900.1264147892@critter.freebsd.dk> In message , John Norman writes: >When you switch to a new VCL on the fly (vcl.use config), is the cache dumped? No. That's the entire point. Also, we keep polling backends in inactive VCL's, so that the health/sick status is ready at all times. -- 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 kristian at redpill-linpro.com Fri Jan 22 14:01:58 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Fri, 22 Jan 2010 15:01:58 +0100 Subject: vim syntax In-Reply-To: <200911241957.54742.glen@delfi.ee> References: <200911241957.54742.glen@delfi.ee> Message-ID: <20100122140158.GA9672@kjeks.varnish-cache.com> On Tue, Nov 24, 2009 at 07:57:54PM +0200, Elan Ruusam?e wrote: > @phk mentioned in the irc, that somebody has written varnish syntax for vim. i > tried to search the archives but found no info about it. > > anyone knows? would be pity to start writing one from scratch if somebody > already spend some time of yours on it. I've heard rumours too, but never seen it. Since it's close to C, I usually get by with C-syntax. There are some differences (ie: set foo = bar, not foo = bar, and ~...) but I suppose using C as a base will save you a lot of time. If you do write one, drop it here and I wouldn't mind testing it, I do work with VCL from time to time ;) -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From kristian at redpill-linpro.com Fri Jan 22 14:08:46 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Fri, 22 Jan 2010 15:08:46 +0100 Subject: X-Forwarded-Forand 2 layers of Varnish In-Reply-To: <4B157BFB.2090401@syspark.com> References: <4B157BFB.2090401@syspark.com> Message-ID: <20100122140846.GB9672@kjeks.varnish-cache.com> (A bit of necroposting, hopefully still relevant) On Tue, Dec 01, 2009 at 03:26:35PM -0500, Jean-Christophe Petit wrote: > we use 2 layers of Varnish and it proved to be highly scalable and > efficient. > But on the second layer, we are not able to get the X-Forwarded-For from > the first layer to sent it to the Backend (Apache) > In fact, on the second layer we have 2 X-Forwarded-For (Visitor + first > Varnish layer) > Is there something we can do on the first Varnish layer to only transmit > the X-Forwarded-For of the visitor ? This is "fixed" in trunk, in that X-F-F is moved into the default VCL and appends correctly. In Varnish 2.0 you could work around it by having the first set X-Original-Forwarded-For, then on the second tier, you overwrite X-Forwarded-For with X-Original_forwarded-For... It's not horribly pretty, but should get you what you want until the trunk-fixes are in a release. -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From pubcrawler.com at gmail.com Fri Jan 22 15:36:03 2010 From: pubcrawler.com at gmail.com (pub crawler) Date: Fri, 22 Jan 2010 10:36:03 -0500 Subject: X-Forwarded-Forand 2 layers of Varnish In-Reply-To: <20100122140846.GB9672@kjeks.varnish-cache.com> References: <4B157BFB.2090401@syspark.com> <20100122140846.GB9672@kjeks.varnish-cache.com> Message-ID: <4c3149fb1001220736s2b706dc3q8535d79deb45cfa6@mail.gmail.com> X-F-F will be nice. For now our solution on our application layer (where we log IP info) is to loop through the X-FORWARDED-FOR data and look the for the actual IP in there, discarding localhost info and any other that are related to our infrastructure which requests traverse through. On Fri, Jan 22, 2010 at 9:08 AM, Kristian Lyngstol wrote: > (A bit of necroposting, hopefully still relevant) > > On Tue, Dec 01, 2009 at 03:26:35PM -0500, Jean-Christophe Petit wrote: >> we use 2 layers of Varnish and it proved to be highly scalable and >> efficient. >> But on the second layer, we are not able to get the X-Forwarded-For from >> the first layer to sent it to the Backend (Apache) >> In fact, on the second layer we have 2 X-Forwarded-For (Visitor + first >> Varnish layer) >> Is there something we can do on the first Varnish layer to only transmit >> the X-Forwarded-For of the visitor ? > > This is "fixed" in trunk, in that X-F-F is moved into the default VCL and > appends correctly. > > In Varnish 2.0 you could work around it by having the first set > X-Original-Forwarded-For, then on the second tier, you overwrite > X-Forwarded-For with X-Original_forwarded-For... It's not horribly pretty, > but should get you what you want until the trunk-fixes are in a release. > > -- > Kristian Lyngst?l > Redpill Linpro AS > Mob: +47 99014497 > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > From jcpetit at syspark.com Fri Jan 22 15:46:18 2010 From: jcpetit at syspark.com (Jean-Christophe Petit) Date: Fri, 22 Jan 2010 10:46:18 -0500 Subject: X-Forwarded-Forand 2 layers of Varnish In-Reply-To: <20100122140846.GB9672@kjeks.varnish-cache.com> References: <4B157BFB.2090401@syspark.com> <20100122140846.GB9672@kjeks.varnish-cache.com> Message-ID: <4B59C84A.8000904@syspark.com> Thank you Kristian. I'll give it a try and hopefully we will have a new release soon ;) Best Regards, JC From a.hongens at netmatch.nl Sat Jan 23 10:20:49 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sat, 23 Jan 2010 11:20:49 +0100 Subject: varnish crashes Message-ID: <4B5ACD81.3000903@netmatch.nl> (second try, I found out I was subscribed using a wrong email address) Hey, I am having some problems with Varnish. Unfortunately (depends on how you look at it), I had to replace our Squid cluster with Varnish in a day.. And now, we are finding out we're having some issues with it, sometimes Varnish just stops working. We have 4 balancers, each running FreeBSD 7.2 with 'device carp' compiled in. I haven't dared upgrade to 8.0 yet, because I had problems on my testmachine earlier with ipv6 and carp interfaces on 8.0. [angelo at nmt-nlb-06 ~]$ uname -a FreeBSD nmt-nlb-06.netmatchcolo1.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon Jun 15 19:25:03 CEST 2009 root at nmt-nlb-06.netmatchcolo1.local:/usr/obj/usr/src/sys/NMT-NLB-06 amd64 Here's an example of a varnishd crashing, this is in /var/log/messages: Jan 23 09:49:39 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 10:49:43 nmt-nlb-06 kernel: pid 47479 (varnishd), uid 80: exited on signal 3 Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: child (54810) Started Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Pushing vcls failed: CLI communication error Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Closed fds: 4 5 6 7 11 12 14 15 Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Child starts Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said managed to mmap 2319266349056 bytes of 2319266349056 Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said Ready Does anyone know what could cause this? Some more info below. Thanks in advance for your thoughts.. [angelo at nmt-nlb-06 ~]$ cat /etc/sysctl.conf net.carp.log=2 net.inet.icmp.icmplim=0 kern.ipc.nmbclusters=65536 kern.ipc.somaxconn=16384 kern.maxfiles=131072 kern.maxfilesperproc=104856 kern.threads.max_threads_per_proc=4096 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=16384 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.inflight.enable=0 net.inet.tcp.hostcache.expire=1 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.hifirst=49152 net.inet.ip.portrange.hilast=65535 Here's an output from top: last pid: 56537; load averages: 0.06, 0.12, 0.13 up 24+21:37:27 11:09:41 270 processes: 2 running, 268 sleeping CPU: 2.7% user, 0.0% nice, 1.2% system, 1.5% interrupt, 94.6% idle Mem: 765M Active, 22M Inact, 293M Wired, 280K Cache, 399M Buf, 6830M Free Swap: 4096M Total, 78M Used, 4018M Free, 1% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56440 haproxy 1 4 0 27136K 20584K kqread 3 0:23 3.76% haproxy 31203 root 1 44 0 29616K 2328K select 3 11:15 0.00% snmpd 1912 root 1 44 0 10484K 808K select 0 1:36 0.00% ntpd 2036 root 1 44 0 83468K 13884K select 0 0:47 0.00% httpd 37934 root 1 4 0 64196K 5392K kqread 0 0:13 0.00% squid 1815 root 1 44 0 5692K 660K select 0 0:13 0.00% syslogd 2056 root 1 8 0 6748K 404K nanslp 0 0:05 0.00% cron 2023 root 1 4 0 5808K 460K kqread 3 0:05 0.00% master 2031 postfix 1 4 0 5808K 436K kqread 0 0:03 0.00% qmgr 56479 www 218 44 0/('.-..-,(K 726M ucond 3 0:00 0.00% varnishd 22829 www 1 20 0 82408K 428K lockf 2 0:00 0.00% httpd 38741 www 1 20 0 83468K 432K lockf 2 0:00 0.00% httpd My config file is too long to post (760kB), because of 350 backends declarations and 7600 host names pointing to those backends. But I can make an extract if someone thinks it helps them to understand my issue.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From phk at phk.freebsd.dk Sat Jan 23 10:27:00 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 23 Jan 2010 10:27:00 +0000 Subject: varnish crashes In-Reply-To: Your message of "Sat, 23 Jan 2010 11:20:49 +0100." <4B5ACD81.3000903@netmatch.nl> Message-ID: <77695.1264242420@critter.freebsd.dk> In message <4B5ACD81.3000903 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: >We have 4 balancers, each running FreeBSD 7.2 with 'device carp' >compiled in. I haven't dared upgrade to 8.0 yet, because I had problems >on my testmachine earlier with ipv6 and carp interfaces on 8.0. It sounds mostly like a resource issue, but I can't say exactly from what you have provided. You can consider increasing the "cli_timeout" parameter a bit and see if it is simply a matter of a busy machine. Are you running on 32 bit or 64 bit machines ? If 32bit, you have to be pretty careful about not overrunning the VM space available (only approx 2G) Use FreeBSD's gstat to see what your disk-activity is like, pay particular attention to the service times (ms/r & ms/w cols) Also check your varnishlog and varnishstat for signs of trouble... -- 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 a.hongens at netmatch.nl Sat Jan 23 11:08:32 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sat, 23 Jan 2010 12:08:32 +0100 Subject: varnish crashes In-Reply-To: <77695.1264242420@critter.freebsd.dk> References: <77695.1264242420@critter.freebsd.dk> Message-ID: <4B5AD8B0.6090103@netmatch.nl> On 23-1-2010 11:27, Poul-Henning Kamp wrote: > In message <4B5ACD81.3000903 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr > ites: > >> We have 4 balancers, each running FreeBSD 7.2 with 'device carp' >> compiled in. I haven't dared upgrade to 8.0 yet, because I had problems >> on my testmachine earlier with ipv6 and carp interfaces on 8.0. > > It sounds mostly like a resource issue, but I can't say exactly from > what you have provided. I get that feeling as well, but I can't seem to find anything wrong. Thanks for your reaction, I hope you can give me some more pointers.. By the way: the balancers do a total of 2000 req/sec now, but when stresstesting I can easily get 9000 cache/hits persec. So I don't think it's hanging on the upper limits of its performance. Even worse, I just had to reboot one of the balancers, it (almost) completely locked up. Ping responds, but ssh dies, and the local console on the machine does not respond either (it does not show any messages). The machines ran a heavy squid load for over a year, but never hung. Grrr.. > You can consider increasing the "cli_timeout" parameter a bit > and see if it is simply a matter of a busy machine. ok, will try. I now have in my /etc/rc.conf: varnishd_enable="YES" varnishd_listen=":80" varnishd_storage="file,/cache,80%" varnishd_config="/usr/local/etc/varnish/default.vcl" I just changed this (after reading the tuning page some more) to: varnishd_enable="YES" varnishd_flags="-P /var/run/varnishd.pid -a :80 -T localhost:81 -f /usr/local/etc/varnish/default.vcl -s file,/cache,80% -u www -g www -p cli_timeout=30 -p lru_interval=20" Let's see what happens.. > > Are you running on 32 bit or 64 bit machines ? 64-bit.. > Use FreeBSD's gstat to see what your disk-activity is like, > pay particular attention to the service times (ms/r & ms/w cols) wow, that's a nice tool, I only knew iostat ;) The disk system is a gmirror of 2 sata disks, and I see on average it does 33 iops, with a response time of 8.3ms/r, and 4.2ms/w.. Not really shocking. > > Also check your varnishlog and varnishstat for signs of trouble... Did that, everything looks peachy. Varnishlog produces too much output (and I would not know what to filter), and varnishstat looks ok as well. Are there specific counters that could indicate trouble? 0+01:16:24 nmt-nlb-04.netmatchcolo1.local Hitrate ratio: 10 100 199 Hitrate avg: 0.7894 0.8059 0.8054 362508 133.35 79.08 Client connections accepted 1807294 366.95 394.26 Client requests received 1261936 260.68 275.29 Cache hits 130026 30.08 28.37 Cache hits for pass 323451 64.17 70.56 Cache misses 545215 106.28 118.94 Backend conn. success 995 0.00 0.22 Fetch head 543052 98.26 118.47 Fetch with Length 209 0.00 0.05 Fetch chunked 453 0.00 0.10 Fetch wanted close 1215 . . N struct sess_mem 510 . . N struct sess 121156 . . N struct object 120051 . . N struct objecthead 242414 . . N struct smf 809 . . N small free smf 1 . . N large free smf 122 . . N struct vbe_conn 438 . . N struct bereq 467 . . N worker threads 699 0.00 0.15 N worker threads created 0 0.00 0.00 N queued work requests 8000 0.00 1.75 N overflowed work requests 317 . . N backends 202676 . . N expired objects 698992 . . N LRU moved objects 1356134 264.69 295.84 Objects sent with write 47428 38.10 10.35 Total Sessions -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From phk at phk.freebsd.dk Sat Jan 23 12:02:53 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 23 Jan 2010 12:02:53 +0000 Subject: varnish crashes In-Reply-To: Your message of "Sat, 23 Jan 2010 12:08:32 +0100." <4B5AD8B0.6090103@netmatch.nl> Message-ID: <90874.1264248173@critter.freebsd.dk> In message <4B5AD8B0.6090103 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: >By the way: the balancers do a total of 2000 req/sec now, but when >stresstesting I can easily get 9000 cache/hits persec. So I don't think >it's hanging on the upper limits of its performance. At that level of load, make sure to kldload the http accept filter. Your varnish-stat looks pretty OK. Have you configured health-polling of all those backends ? -- 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 a.hongens at netmatch.nl Sat Jan 23 13:07:39 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sat, 23 Jan 2010 14:07:39 +0100 Subject: varnish crashes In-Reply-To: <90874.1264248173@critter.freebsd.dk> References: <90874.1264248173@critter.freebsd.dk> Message-ID: <4B5AF49B.6060901@netmatch.nl> On 23-1-2010 13:02, Poul-Henning Kamp wrote: > In message <4B5AD8B0.6090103 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr > ites: > >> By the way: the balancers do a total of 2000 req/sec now, but when >> stresstesting I can easily get 9000 cache/hits persec. So I don't think >> it's hanging on the upper limits of its performance. > > At that level of load, make sure to kldload the http accept filter. Thanks, after doing some reading, I loaded accf_data and accf_http.. > Your varnish-stat looks pretty OK. > > Have you configured health-polling of all those backends ? Not explicitly no.. I have haproxy running on these machines as well for over a year, with the 200-300 backends, each bound on a local port. These do health checking to backend nodes, and if they are down haproxy presents a pretty looking 503 page specific for that project. In Varnish I have only configured backends like this. backend backend8001 { .host = "localhost"; .port = "8001"; } backend backend8002 { .host = "localhost"; .port = "8002"; } .. else if (req.http.host == "blabla.sitea.com") { set req.backend = backend8001; } else if (req.http.host == "blabli.sitea.com") { set req.backend = backend8001; } else if (req.http.host == "blabla.siteb.com") { set req.backend = backend8002; } else if (req.http.host == "blabla.sitec.com") { set req.backend = backend8002; } I know I could do this all in my vcl, but then I would loose all the haproxy advantages like the stats page, and increase the size of my vcl to several megabytes. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From cosimo at streppone.it Sat Jan 23 14:40:24 2010 From: cosimo at streppone.it (Cosimo Streppone) Date: Sat, 23 Jan 2010 15:40:24 +0100 Subject: Caching dynamic pages and Accept-Language Message-ID: Hi everyone, we're trying to cache our first full HTML page with Varnish after some static content experience. One of the things we're confronting with is the "Accept-Language" header. This is for my.opera.com, where we have 18 different languages. Since Accept-Language is very variable, we thought of normalizing it. Asking in #varnish, Poul suggested using regsub. We're already doing that for User-Agent, but accept language parsing is messier, so I tried the embedded C code alternative. I think the result might be useful for others. Kristian also gave me some tips to make it saner, so it became a completely generic accept-language.vcl. Here's the code: http://github.com/cosimo/varnish-accept-language/ and here's a blog post about it, http://my.opera.com/cstrep/blog/2010/01/23/my-opera-front-page-caching-and-varnish-hacking I'd be glad to read your feedback on this. Thanks, -- Cosimo From ingvar at redpill-linpro.com Sat Jan 23 18:54:22 2010 From: ingvar at redpill-linpro.com (Ingvar Hagelund) Date: Sat, 23 Jan 2010 19:54:22 +0100 (CET) Subject: The usage of varnish, revisited Message-ID: <631328742.63117.1264272862299.JavaMail.root@claudius.linpro.no> Dump from my blog posting at http://ingvar.blog.linpro.no/ Ingvar The usage of varnish, revisited This is more or less a repost, with updated numbers. Some months have passed, and it is time to run my poking scripts again, looking for sites that run Varnish. There is no deep magic here. I just parse the available top lists that I know of, and peek at the HTML headers of the sites that are listed. If there are subsites linked from the front page of the site, I scan them too. This means that twitter.com shows up, though Twitter only runs Varnish on its search site. Subsites with a Varnish match are shown in parenthesis in the results. For the Nordic countries, I have found quite good lists, that is, upload result lists from the probably most visited media sites in the respective countries. Remember of course, that these are generally pay-to-be-included lists, and there may exist sites with far more hits than the ones listed. For a global overview, I have used Alexa. Now for the results. Varnish is sponsored by large Norwegian sites, so it is no big surprise that there are a lot of hits in Norway. Of the TNS Gallup top list, Varnish runs at 36 of the top 100 sites. That?s 3 up since my last probe. For Denmark, I use FDIM?s list. From May, we are up from 3 to 11 sites in the top 100. For Finland, I use TNS? numbers again. No changes there. For Sweden, I use the KIA Index list. I now probe the 200 top sites, so there are several more varnish sites on the list. In the top 100, we are up from 8 to 9. For the Alexa?s World top 500 list, I have tweaked my filters a bit, and the list is up from 7 to 17 sites since my last probe in May. World Domination, here we come! The whole World: Alexa's global top 500 list Place 12 Varnish running on twitter.com (http://integratedsearch.twitter.com/search.html) Place 47 Varnish running on photobucket.com (http://blog.photobucket.com/) Place 90 Varnish running on mixi.jp (http://img.mixi.jp/static/css/basic/logout_quirks) (and others) Place 101 Varnish running on weather.com (http://www.weather.com/) (weather.com) Place 107 Varnish running on globo.com (globo.com) (http://www.globo.com/) Place 111 Varnish running on ifeng.com (http://big5.ifeng.com/gate/big5/www) Place 138 Varnish running on answers.com (http://www.answers.com/) (answers.com) Place 170 Varnish running on orange.fr (http://r.orange.fr/r/Eorangepublicite) Place 179 Varnish running on hulu.com (hulu.com) Place 199 Varnish running on wikia.com (wikia.com) Place 213 Varnish running on xinhuanet.com (http://big5.xinhuanet.com/gate/big5/www) Place 290 Varnish running on people.com.cn (http://bbs1.people.com.cn/boardList) (and others) Place 344 Varnish running on tuenti.com (http://estaticos1.tuenti.com/layout/web2/images/favicon) Place 428 Varnish running on chinanews.com.cn (http://www.chinanews.com.cn/test/index_back_d.html) (and others) Place 433 Varnish running on mercadolivre.com.br (http://veiculos.mercadolivre.com.br/) (and others) Place 447 Varnish running on mercadolibre.com.mx (http://tendencias.mercadolibre.com.mx/) (and others) Place 456 Varnish running on break.com (break.com) In my last probe, I poked sites all over Europe. With a few exceptions, that was a bit less interesting. Global .com and .net sites tend to cover most of the top 100 entries, as I had only toolbar lists, and it?s not that spectacular that for example people in Serbia and Monte Negro are browsing Twitter, like the rest of the World does. So I have skipped other countries. If you know of any good top list for you country that is not toolbar based, please let me know. All the gory details are available here: http://users.linpro.no/ingvar/varnish/stats-2010-01-18.txt Other more or less worth mentioned sites that is reported to use Varnish but does not show up in my lists, may be Slashdot, WAT TV, The Pirate Bay, JDownloader, e.Republik, WOWwiki, Globo.com, PCWelt.de, BlackPlanet, funnyordie.com and n-tv.de, to name a few. From jeremy at hinegardner.org Sat Jan 23 19:47:32 2010 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sat, 23 Jan 2010 12:47:32 -0700 Subject: varnish crashes In-Reply-To: <4B5ACD81.3000903@netmatch.nl> References: <4B5ACD81.3000903@netmatch.nl> Message-ID: <20100123194732.GZ16697@hinegardner.org> On Sat, Jan 23, 2010 at 11:20:49AM +0100, Angelo H?ngens wrote: > Here's an example of a varnishd crashing, this is in /var/log/messages: > > Jan 23 09:49:39 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 10:49:43 nmt-nlb-06 kernel: pid 47479 (varnishd), uid 80: exited > on signal 3 > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: child (54810) Started > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Pushing vcls failed: CLI > communication error > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Closed > fds: 4 5 6 7 11 12 14 15 > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Child starts > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said managed > to mmap 2319266349056 bytes of 2319266349056 > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said Ready > > Does anyone know what could cause this? I have this exact same combination of issues with my varnish installation. I am running on CentOS 5 and in my case, the child never restarted after the Pushing vcls failed. > My config file is too long to post (760kB), because of 350 backends > declarations and 7600 host names pointing to those backends. But I can > make an extract if someone thinks it helps them to understand my issue.. My config file was not that large, but it was larger than the default cli_buffer setting. On a lark, I changed my varnish startup to have -p cli_buffer=16384 which is larger than the file size of my combined vcl's and I have not had the 'Pushing vcls failed' error since. Since this was the only configuration parameter I changed at that point, I'm fairly sure this fixed that one error. I still get the 'Child not responding to ping, killing it' all the time, and I currently have my cli_timeout set to 10. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From michael at dynamine.net Sat Jan 23 19:57:20 2010 From: michael at dynamine.net (Michael Fischer) Date: Sat, 23 Jan 2010 11:57:20 -0800 Subject: varnish crashes In-Reply-To: <4B5ACD81.3000903@netmatch.nl> References: <4B5ACD81.3000903@netmatch.nl> Message-ID: On Sat, Jan 23, 2010 at 2:20 AM, Angelo H?ngens wrote: > > (second try, I found out I was subscribed using a wrong email address) > > Hey, > > I am having some problems with Varnish. Unfortunately (depends on how > you look at it), I had to replace our Squid cluster with Varnish in a > day.. And now, we are finding out we're having some issues with it, > sometimes Varnish just stops working. > > We have 4 balancers, each running FreeBSD 7.2 with 'device carp' > compiled in. I haven't dared upgrade to 8.0 yet, because I had problems > on my testmachine earlier with ipv6 and carp interfaces on 8.0. > > [angelo at nmt-nlb-06 ~]$ uname -a > FreeBSD nmt-nlb-06.netmatchcolo1.local 7.2-RELEASE FreeBSD 7.2-RELEASE > #0: Mon Jun 15 19:25:03 CEST 2009 > root at nmt-nlb-06.netmatchcolo1.local:/usr/obj/usr/src/sys/NMT-NLB-06 amd64 > > Here's an example of a varnishd crashing, this is in /var/log/messages: > > Jan 23 09:49:39 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 10:49:43 nmt-nlb-06 kernel: pid 47479 (varnishd), uid 80: exited > on signal 3 > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: child (54810) Started > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Pushing vcls failed: CLI > communication error > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Closed > fds: 4 5 6 7 11 12 14 15 > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Child starts > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said managed > to mmap 2319266349056 bytes of 2319266349056 > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said Ready > > Does anyone know what could cause this? > What is thread_pool_max set to? Have you tried lowering it? We have found that on systems with very high cache-hit ratios, 16 threads per CPU is the sweet spot to avoid context-switch saturation. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo at mercadolibre.com Sat Jan 23 20:39:39 2010 From: rodrigo at mercadolibre.com (Rodrigo Benzaquen) Date: Sat, 23 Jan 2010 17:39:39 -0300 Subject: The usage of varnish, revisited In-Reply-To: <631328742.63117.1264272862299.JavaMail.root@claudius.linpro.no> References: <631328742.63117.1264272862299.JavaMail.root@claudius.linpro.no> Message-ID: Hi, We use Varnish for www.mercadolibre.com all other subdomians for latinamerica. On Sat, Jan 23, 2010 at 3:54 PM, Ingvar Hagelund wrote: > Dump from my blog posting at http://ingvar.blog.linpro.no/ > > Ingvar > > > > The usage of varnish, revisited > > This is more or less a repost, with updated numbers. > > Some months have passed, and it is time to run my poking scripts again, > looking for sites that run Varnish. There is no deep magic here. I just > parse the available top lists that I know of, and peek at the HTML headers > of the sites that are listed. If there are subsites linked from the front > page of the site, I scan them too. This means that twitter.com shows up, > though Twitter only runs Varnish on its search site. Subsites with a Varnish > match are shown in parenthesis in the results. > > For the Nordic countries, I have found quite good lists, that is, upload > result lists from the probably most visited media sites in the respective > countries. Remember of course, that these are generally pay-to-be-included > lists, and there may exist sites with far more hits than the ones listed. > > For a global overview, I have used Alexa. > > Now for the results. Varnish is sponsored by large Norwegian sites, so it > is no big surprise that there are a lot of hits in Norway. Of the TNS Gallup > top list, Varnish runs at 36 of the top 100 sites. That?s 3 up since my last > probe. > > For Denmark, I use FDIM?s list. From May, we are up from 3 to 11 sites in > the top 100. For Finland, I use TNS? numbers again. No changes there. For > Sweden, I use the KIA Index list. I now probe the 200 top sites, so there > are several more varnish sites on the list. In the top 100, we are up from 8 > to 9. > > For the Alexa?s World top 500 list, I have tweaked my filters a bit, and > the list is up from 7 to 17 sites since my last probe in May. World > Domination, here we come! > > The whole World: Alexa's global top 500 list > Place 12 Varnish running on twitter.com ( > http://integratedsearch.twitter.com/search.html) > Place 47 Varnish running on photobucket.com (http://blog.photobucket.com/ > ) > Place 90 Varnish running on mixi.jp ( > http://img.mixi.jp/static/css/basic/logout_quirks) (and others) > Place 101 Varnish running on weather.com (http://www.weather.com/) ( > weather.com) > Place 107 Varnish running on globo.com (globo.com) (http://www.globo.com/) > Place 111 Varnish running on ifeng.com ( > http://big5.ifeng.com/gate/big5/www) > Place 138 Varnish running on answers.com (http://www.answers.com/) ( > answers.com) > Place 170 Varnish running on orange.fr ( > http://r.orange.fr/r/Eorangepublicite) > Place 179 Varnish running on hulu.com (hulu.com) > Place 199 Varnish running on wikia.com (wikia.com) > Place 213 Varnish running on xinhuanet.com ( > http://big5.xinhuanet.com/gate/big5/www) > Place 290 Varnish running on people.com.cn ( > http://bbs1.people.com.cn/boardList) (and others) > Place 344 Varnish running on tuenti.com ( > http://estaticos1.tuenti.com/layout/web2/images/favicon) > Place 428 Varnish running on chinanews.com.cn ( > http://www.chinanews.com.cn/test/index_back_d.html) (and others) > Place 433 Varnish running on mercadolivre.com.br ( > http://veiculos.mercadolivre.com.br/) (and others) > Place 447 Varnish running on mercadolibre.com.mx ( > http://tendencias.mercadolibre.com.mx/) (and others) > Place 456 Varnish running on break.com (break.com) > > In my last probe, I poked sites all over Europe. With a few exceptions, > that was a bit less interesting. Global .com and .net sites tend to cover > most of the top 100 entries, as I had only toolbar lists, and it?s not that > spectacular that for example people in Serbia and Monte Negro are browsing > Twitter, like the rest of the World does. So I have skipped other countries. > If you know of any good top list for you country that is not toolbar based, > please let me know. > > All the gory details are available here: > http://users.linpro.no/ingvar/varnish/stats-2010-01-18.txt > > Other more or less worth mentioned sites that is reported to use Varnish > but does not show up in my lists, may be Slashdot, WAT TV, The Pirate Bay, > JDownloader, e.Republik, WOWwiki, Globo.com, PCWelt.de, BlackPlanet, > funnyordie.com and n-tv.de, to name a few. > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samcrawford at gmail.com Sat Jan 23 21:13:23 2010 From: samcrawford at gmail.com (Sam Crawford) Date: Sat, 23 Jan 2010 21:13:23 +0000 Subject: Varnish extensions for SSO support Message-ID: Evening all, I've been an avid Varnish user both personally and at work for a couple of years now. At work we use it to cache content across our global intranet, handling a few million requests per day. At present, we have the following logical setup... F5 GTM (GSLB device) > F5 load balancer > Varnish > In-house Java Reverse Proxy > Backend applications (hundreds) Varnish and the in-house reverse proxy reside on the same servers, with varnish having a single backend pointing at the in-house reverse proxy (the F5s handle failover between instances). The in-house Java reverse proxy performs a range of functions, including (but certainly not limited to): * Authenticating/authorising users via our Single Sign On service * Header injection to help backend applications identify users * Catching cookies from backend applications and delivering a single pointer cookie back to clients I've been wondering if we could write some C extensions to Varnish to remove the need for the Java reverse proxy. This would help flatten the infrastructure and save on latency (which is pretty important for us). The standard Varnish VCL capabilities would meet many of our requirements, but for some functions we'd certainly need to write extensions (such as making an out-of-band HTTP request to an SSO server in order to validate an SSO cookie (which we'd also need to cache!)). Whilst I know it's technically feasible for us to do this, I was wondering (a) if anyone is already doing something similar and (b) if the community thinks I'm completely mad for evening thinking about doing it :-) Thanks, Sam From a.hongens at netmatch.nl Sun Jan 24 15:23:17 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sun, 24 Jan 2010 16:23:17 +0100 Subject: varnish crashes In-Reply-To: References: <4B5ACD81.3000903@netmatch.nl> Message-ID: <4B5C65E5.70901@netmatch.nl> On 23-1-2010 20:57, Michael Fischer wrote: > On Sat, Jan 23, 2010 at 2:20 AM, Angelo H?ngens > wrote: > > > (second try, I found out I was subscribed using a wrong email address) > > Hey, > > I am having some problems with Varnish. Unfortunately (depends on how > you look at it), I had to replace our Squid cluster with Varnish in a > day.. And now, we are finding out we're having some issues with it, > sometimes Varnish just stops working. > > We have 4 balancers, each running FreeBSD 7.2 with 'device carp' > compiled in. I haven't dared upgrade to 8.0 yet, because I had problems > on my testmachine earlier with ipv6 and carp interfaces on 8.0. > > [angelo at nmt-nlb-06 ~]$ uname -a > FreeBSD nmt-nlb-06.netmatchcolo1.local 7.2-RELEASE FreeBSD 7.2-RELEASE > #0: Mon Jun 15 19:25:03 CEST 2009 > root at nmt-nlb-06.netmatchcolo1.local:/usr/obj/usr/src/sys/NMT-NLB-06 > amd64 > > Here's an example of a varnishd crashing, this is in /var/log/messages: > > Jan 23 09:49:39 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 10:49:43 nmt-nlb-06 kernel: pid 47479 (varnishd), uid 80: exited > on signal 3 > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding > to ping, killing it. > Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: child (54810) Started > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Pushing vcls failed: CLI > communication error > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Closed > fds: 4 5 6 7 11 12 14 15 > Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Child > starts > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said managed > to mmap 2319266349056 bytes of 2319266349056 > Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said Ready > > Does anyone know what could cause this? > > > What is thread_pool_max set to? Have you tried lowering it? We have > found that on systems with very high cache-hit ratios, 16 threads per > CPU is the sweet spot to avoid context-switch saturation. [angelo at nmt-nlb-03 ~]$ varnishadm -T localhost:81 param.show| grep thread_pool thread_pool_add_delay 20 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_fail_delay 200 [milliseconds] thread_pool_max 500 [threads] thread_pool_min 5 [threads] thread_pool_purge_delay 1000 [milliseconds] thread_pool_timeout 300 [seconds] thread_pools 2 [pools] Thread_pool_max is set to 500 threads.. But I just increased it to 4000 (as per http://varnish.projects.linpro.no/wiki/Performance), as 'top' shows me it's using around 480~490 threads now.. You suggest lowering it, what would be the effect of that? I would think it would run out of threads or something? Well, we'll see what happens with the increased threads.. I've also just increased thread_pools from 2 to 4.. (4 cores). -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From michael at dynamine.net Sun Jan 24 17:57:20 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Sun, 24 Jan 2010 09:57:20 -0800 Subject: varnish crashes In-Reply-To: <4B5C65E5.70901@netmatch.nl> References: <4B5ACD81.3000903@netmatch.nl> <4B5C65E5.70901@netmatch.nl> Message-ID: <0543C358-3EAA-4A50-BA5A-6E37B845B85C@dynamine.net> On Jan 24, 2010, at 7:23 AM, Angelo H?ngens wrote: >> What is thread_pool_max set to? Have you tried lowering it? We have >> found that on systems with very high cache-hit ratios, 16 threads per >> CPU is the sweet spot to avoid context-switch saturation. > > [angelo at nmt-nlb-03 ~]$ varnishadm -T localhost:81 param.show| grep > thread_pool > > thread_pool_add_delay 20 [milliseconds] > thread_pool_add_threshold 2 [requests] > thread_pool_fail_delay 200 [milliseconds] > thread_pool_max 500 [threads] > thread_pool_min 5 [threads] > thread_pool_purge_delay 1000 [milliseconds] > thread_pool_timeout 300 [seconds] > thread_pools 2 [pools] > > Thread_pool_max is set to 500 threads.. But I just increased it to 4000 > (as per http://varnish.projects.linpro.no/wiki/Performance), as 'top' > shows me it's using around 480~490 threads now.. > > You suggest lowering it, what would be the effect of that? I would think > it would run out of threads or something? Well, we'll see what happens > with the increased threads.. Increasing concurrency is unlikely to solve the problem, although setting the number of thread pools to the number of CPUs is probably a good idea. Assuming a high hit ratio and high CPU utilization (you haven't posted either), lowering concurrency (i.e. reducing thread_pool_max) can help reduce CPU contention incurred by context switching. If maximum concurrency is reached, incoming connections will be deferred to the TCP listen(2) backlog (the overflowed_requests counter in varnishstat increases when this happens). When the request reaches the head of the queue, it will then be picked up by a processing thread. The net effect is some additional latency, but probably not as much as you're experiencing if your CPU is swamped with context switches. There are a few cases where increasing thread_pool_max can help, in particular, where you have a high cache-miss ratio and you have slow origin servers. But if CPU is already high, it will only make the problem worse. BTW, on FreeBSD you can view the current length of the listen(2) backlog via "netstat -aL" By default, varnishd's listen(2) backlog is 512; as long as you don't see the length hit that value you should be ok. --Michael From a.hongens at netmatch.nl Sun Jan 24 18:40:23 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sun, 24 Jan 2010 19:40:23 +0100 Subject: varnish crashes In-Reply-To: <0543C358-3EAA-4A50-BA5A-6E37B845B85C@dynamine.net> References: <4B5ACD81.3000903@netmatch.nl> <4B5C65E5.70901@netmatch.nl> <0543C358-3EAA-4A50-BA5A-6E37B845B85C@dynamine.net> Message-ID: <4B5C9417.4000207@netmatch.nl> On 24-1-2010 18:57, Michael S. Fischer wrote: >> Thread_pool_max is set to 500 threads.. But I just increased it to >> 4000 (as per http://varnish.projects.linpro.no/wiki/Performance), >> as 'top' shows me it's using around 480~490 threads now.. >> >> You suggest lowering it, what would be the effect of that? I would >> think it would run out of threads or something? Well, we'll see >> what happens with the increased threads.. > > > Increasing concurrency is unlikely to solve the problem, although > setting the number of thread pools to the number of CPUs is probably > a good idea. > > Assuming a high hit ratio and high CPU utilization (you haven't > posted either), lowering concurrency (i.e. reducing thread_pool_max) > can help reduce CPU contention incurred by context switching. > > If maximum concurrency is reached, incoming connections will be > deferred to the TCP listen(2) backlog (the overflowed_requests > counter in varnishstat increases when this happens). When the > request reaches the head of the queue, it will then be picked up by a > processing thread. The net effect is some additional latency, but > probably not as much as you're experiencing if your CPU is swamped > with context switches. > > There are a few cases where increasing thread_pool_max can help, in > particular, where you have a high cache-miss ratio and you have slow > origin servers. But if CPU is already high, it will only make the > problem worse. > > BTW, on FreeBSD you can view the current length of the listen(2) > backlog via "netstat -aL" By default, varnishd's listen(2) backlog > is 512; as long as you don't see the length hit that value you should > be ok. According to top, the CPU usage for the varnishd process is 0.0% at 400 req/sec. The load over the past 15 minutes is 0.45, probably mostly because of haproxy running on the same machine. So I don't think load is a problem.. My problem is that varnish sometimes just crashes or stops responding. My hit cache ratio is not that high, around 80%, and the backend servers can be slow at times (quite complex .net web apps). But I've changed some settings, and I am waiting for the next time varnish starts to stop responding.. I'm beginning to think it's something that grows over time, after restarting the varnish process things tend to run smooth for a while. I'll just keep monitoring it. You did give a lot of extra insight, and some counters I can look into, thank you very much for that. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From michael at dynamine.net Sun Jan 24 19:31:58 2010 From: michael at dynamine.net (Michael S. Fischer) Date: Sun, 24 Jan 2010 11:31:58 -0800 Subject: varnish crashes In-Reply-To: <4B5C9417.4000207@netmatch.nl> References: <4B5ACD81.3000903@netmatch.nl> <4B5C65E5.70901@netmatch.nl> <0543C358-3EAA-4A50-BA5A-6E37B845B85C@dynamine.net> <4B5C9417.4000207@netmatch.nl> Message-ID: <9CDE9B3F-D0F7-4EA5-8AD7-0E6EEB1C00E8@dynamine.net> On Jan 24, 2010, at 10:40 AM, Angelo H?ngens wrote: > > According to top, the CPU usage for the varnishd process is 0.0% at 400 > req/sec. The load over the past 15 minutes is 0.45, probably mostly > because of haproxy running on the same machine. So I don't think load is > a problem.. My problem is that varnish sometimes just crashes or stops > responding. > > My hit cache ratio is not that high, around 80%, and the backend servers > can be slow at times (quite complex .net web apps). But I've changed > some settings, and I am waiting for the next time varnish starts to stop > responding.. I'm beginning to think it's something that grows over time, > after restarting the varnish process things tend to run smooth for a > while. I'll just keep monitoring it. The other most common reason why the varnish supervisor can start killing off children is when they are blocked waiting on a page-in, which is usually due to VM overcommit (i.e., storage file size significantly exceeds RAM and you have a very large hot working set). You can usually see that when "iostat -x" output shows the I/O busy % is close to 100, meaning the disk is saturated. You can also see that in vmstat (look at the pi/po columns if you're using a file, or si/so if you're using malloc). --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From plfgoa at gmail.com Mon Jan 25 02:20:19 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Mon, 25 Jan 2010 07:50:19 +0530 Subject: Varnish Prefetch In-Reply-To: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> References: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> Message-ID: <75cf5801001241820w3e4afd34v64ad2031b8b71b2@mail.gmail.com> Can anybody please respond to this query ? Thank you. On Fri, Jan 22, 2010 at 11:02 AM, Paras Fadte wrote: > Hi, > > Is prefetch by default enabled in varnish ? I have following in VCL . A > value of -30 seconds would mean that the object would be checked 30 seconds > before its expiry time is reached to see if its modified on backend ? > > > sub vcl_fetch { > set obj.grace = 30s; > if (!obj.cacheable) { > pass; > } > if (obj.http.Set-Cookie) { > pass; > } > set obj.prefetch = -30s; > deliver; > } > > > I see following from varnishlog . What doe that mean ? > > 26 VCL_info c XID 3904284923: obj.prefetch (-30) less than ttl > (-1.26414e+09), ignored. > > 0 VCL_call - prefetch > 0 ExpPick - 3903448954 prefetch > > > > Thank you. > > -Paras > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Jan 25 08:44:56 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 25 Jan 2010 08:44:56 +0000 Subject: Varnish Prefetch In-Reply-To: Your message of "Mon, 25 Jan 2010 07:50:19 +0530." <75cf5801001241820w3e4afd34v64ad2031b8b71b2@mail.gmail.com> Message-ID: <18799.1264409096@critter.freebsd.dk> In message <75cf5801001241820w3e4afd34v64ad2031b8b71b2 at mail.gmail.com>, Paras Fadte writes: >> Is prefetch by default enabled in varnish ? Prefetch never got implemented, we found other ideas to solve the problem, such as grace mode. -- 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 tfheen at redpill-linpro.com Mon Jan 25 09:22:10 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 25 Jan 2010 10:22:10 +0100 Subject: comparing 2 headers In-Reply-To: <4B57134E.8010300@netmatch.nl> ("Angelo =?utf-8?Q?H=C3=B6ngen?= =?utf-8?Q?s=22's?= message of "Wed, 20 Jan 2010 15:29:34 +0100") References: <4B57134E.8010300@netmatch.nl> Message-ID: <871vhewnct.fsf@qurzaw.linpro.no> ]] Angelo H?ngens | 1. What will happen when the dataset I want to pass through Varnish is | much larger than the Varnish machines could store? I would expect the | cache hit ratio to go down, and Varnish to start evicting objects from | the cache more frequently. Or will Varnish just crash and burn with a | 'cache is full' message? :) It uses an LRU list to evict the object that's the longest since it used. This can impact performance somewhat as it often evicts a bit too many objects at a time and like all kinds of garbage collections, happen at a bad time, but it won't crash and burn. | 2. I run the varnishncsa daemon to write to logfile. However, I would | really like to see some extra information like whether it was a cache | hit or miss, and the last time to byte to the client in the logfile, | like squid does in it's access.log. This is really really handy for | post-mortem analysis. (We read everything into a database sometimes and | let the dba's do their thing.) | | Is there any way to do this, or can you point me in the right direction? At the moment: just change varnishncsa and recompile. | 3. I want to compare some headers, but I'm getting a compile error: | | Message from VCC-compiler: | Expected CSTR got 'server.ip' | (program line 266), at | (input Line 1279 Pos 24) | if (req.http.host == server.ip) { error 200 ok; } | -----------------------#########-------------------- | Running VCC-compiler failed, exit 1 | VCL compilation failed | | I want to make sure that when I point my browser to http://w.x.y.z, I | get a message "200 ok". Am I doing something wrong? I'm using | Varnish-2.0.4 from ports by the way. Upgrade. This does work fine with at least 2.0.6 (just tested). | 4. Is there some documentation on what the ReqEnd and StatSess values | mean in the varnishlog output? The values seem interesting, but I have | no idea what they are. http://varnish.projects.linpro.no/wiki/Varnishlog has the tiny start of some docs. Help writing up the description of all the tags would be appreciated. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From a.hongens at netmatch.nl Sat Jan 23 10:12:32 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Sat, 23 Jan 2010 11:12:32 +0100 Subject: varnish crashing Message-ID: <4B5ACB90.6020604@netmatch.nl> Hey, I am having some problems with Varnish. Unfortunately (depends on how you look at it), I had to replace our Squid cluster with Varnish in a day.. And now, we are finding out we're having some issues with it, sometimes Varnish just stops working. We have 4 balancers, each running FreeBSD 7.2 with 'device carp' compiled in. I haven't dared upgrade to 8.0 yet, because I had problems on my testmachine earlier with ipv6 and carp interfaces on 8.0. [angelo at nmt-nlb-06 ~]$ uname -a FreeBSD nmt-nlb-06.netmatchcolo1.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon Jun 15 19:25:03 CEST 2009 root at nmt-nlb-06.netmatchcolo1.local:/usr/obj/usr/src/sys/NMT-NLB-06 amd64 Here's an example of a varnishd crashing, this is in /var/log/messages: Jan 23 09:49:39 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 10:49:43 nmt-nlb-06 kernel: pid 47479 (varnishd), uid 80: exited on signal 3 Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: Child (47479) not responding to ping, killing it. Jan 23 09:49:43 nmt-nlb-06 varnishd[47478]: child (54810) Started Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Pushing vcls failed: CLI communication error Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Closed fds: 4 5 6 7 11 12 14 15 Jan 23 09:49:48 nmt-nlb-06 varnishd[47478]: Child (54810) said Child starts Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said managed to mmap 2319266349056 bytes of 2319266349056 Jan 23 09:51:15 nmt-nlb-06 varnishd[47478]: Child (54810) said Ready Does anyone know what could cause this? Some more info below. Thanks in advance for your thoughts.. [angelo at nmt-nlb-06 ~]$ cat /etc/sysctl.conf net.carp.log=2 net.inet.icmp.icmplim=0 kern.ipc.nmbclusters=65536 kern.ipc.somaxconn=16384 kern.maxfiles=131072 kern.maxfilesperproc=104856 kern.threads.max_threads_per_proc=4096 net.inet.tcp.rfc1323=1 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=16384 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.inflight.enable=0 net.inet.tcp.hostcache.expire=1 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 net.inet.ip.portrange.hifirst=49152 net.inet.ip.portrange.hilast=65535 Here's an output from top: last pid: 56537; load averages: 0.06, 0.12, 0.13 up 24+21:37:27 11:09:41 270 processes: 2 running, 268 sleeping CPU: 2.7% user, 0.0% nice, 1.2% system, 1.5% interrupt, 94.6% idle Mem: 765M Active, 22M Inact, 293M Wired, 280K Cache, 399M Buf, 6830M Free Swap: 4096M Total, 78M Used, 4018M Free, 1% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56440 haproxy 1 4 0 27136K 20584K kqread 3 0:23 3.76% haproxy 31203 root 1 44 0 29616K 2328K select 3 11:15 0.00% snmpd 1912 root 1 44 0 10484K 808K select 0 1:36 0.00% ntpd 2036 root 1 44 0 83468K 13884K select 0 0:47 0.00% httpd 37934 root 1 4 0 64196K 5392K kqread 0 0:13 0.00% squid 1815 root 1 44 0 5692K 660K select 0 0:13 0.00% syslogd 2056 root 1 8 0 6748K 404K nanslp 0 0:05 0.00% cron 2023 root 1 4 0 5808K 460K kqread 3 0:05 0.00% master 2031 postfix 1 4 0 5808K 436K kqread 0 0:03 0.00% qmgr 56479 www 218 44 0/('.-..-,(K 726M ucond 3 0:00 0.00% varnishd 22829 www 1 20 0 82408K 428K lockf 2 0:00 0.00% httpd 38741 www 1 20 0 83468K 432K lockf 2 0:00 0.00% httpd My config file is too long to post (760kB), because of 350 backends declarations and 7600 host names pointing to those backends. But I can make an extract if someone thinks it helps them to understand my issue.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From bra at fsn.hu Fri Jan 22 17:31:37 2010 From: bra at fsn.hu (Attila Nagy) Date: Fri, 22 Jan 2010 18:31:37 +0100 Subject: Compiling VCL with pcc Message-ID: <4B59E0F9.9060107@fsn.hu> Hello, I have run into the same issue as others (like http://projects.linpro.no/pipermail/varnish-misc/2007-November/001123.html). I have netbooted machines with a trimmed down FreeBSD release, which of course doesn't have such large things like a C compiler (gcc). So I have three ways to get out of this problem: 1 install gcc (I can't and don't want currently) 2 use a small C compiler 3 use precompiled configuration As there is no trace for the third solution, I've tried to compile the configuration with pcc, because it's small enough for me to include that. I've got this: Message from C-compiler: major internal compiler error: ./vcl.1P9zoqAU.c, line 434 Running C-compiler failed, exit 1 VCL compilation failed So my questions are: - will 3 be possible in the near future? - can anything be made to make pcc usable with varnish? Thanks, From tfheen at redpill-linpro.com Mon Jan 25 09:26:18 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 25 Jan 2010 10:26:18 +0100 Subject: Release schedule for saint mode. In-Reply-To: <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> (pablort's message of "Thu, 21 Jan 2010 16:57:31 -0200") References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> Message-ID: <87wrz6v8lh.fsf@qurzaw.linpro.no> ]] pablort | And how about 2.1 ? Any release date on the horizon ? :D Persistent needs more testing before we can release it. If you're in a position where you can test it: please do so and report back, especially if you can make it crash with backtraces. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Mon Jan 25 09:27:18 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Mon, 25 Jan 2010 10:27:18 +0100 Subject: Varnish Prefetch In-Reply-To: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> (Paras Fadte's message of "Fri, 22 Jan 2010 11:02:07 +0530") References: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> Message-ID: <87sk9uv8jt.fsf@qurzaw.linpro.no> ]] Paras Fadte | Is prefetch by default enabled in varnish ? No, it is not implemented and any references to it should be ignored. It is also removed in trunk. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From a.hongens at netmatch.nl Mon Jan 25 10:06:51 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Mon, 25 Jan 2010 11:06:51 +0100 Subject: varnish crashes In-Reply-To: <9CDE9B3F-D0F7-4EA5-8AD7-0E6EEB1C00E8@dynamine.net> References: <4B5ACD81.3000903@netmatch.nl> <4B5C65E5.70901@netmatch.nl> <0543C358-3EAA-4A50-BA5A-6E37B845B85C@dynamine.net> <4B5C9417.4000207@netmatch.nl> <9CDE9B3F-D0F7-4EA5-8AD7-0E6EEB1C00E8@dynamine.net> Message-ID: <4B5D6D3B.1010004@netmatch.nl> On 24-1-2010 20:31, Michael S. Fischer wrote: > The other most common reason why the varnish supervisor can start > killing off children is when they are blocked waiting on a page-in, > which is usually due to VM overcommit (i.e., storage file size > significantly exceeds RAM and you have a very large hot working set). > You can usually see that when "iostat -x" output shows the I/O busy % is > close to 100, meaning the disk is saturated. You can also see that in > vmstat (look at the pi/po columns if you're using a file, or si/so if > you're using malloc). Well, my balancers have 8GB ram, and were using a 350GB backend file.. I saw disk io was really high, 174% busy is kinda busy :) extended device statistics device r/s w/s kr/s kw/s wait svc_t %b ad4 100.3 85.2 4101.1 1355.9 2 37.5 174 ad6 102.5 85.2 4092.7 1355.9 3 29.1 150 So thanks for that! I now set the backend to an 8GB file, and I hope that will be better.. Do you have any recommendations, except buying faster disks? With Squid I was used to filling up the 300GB disks (we also serve large images), but I guess Varnish does not work that way.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From phk at phk.freebsd.dk Mon Jan 25 10:10:32 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 25 Jan 2010 10:10:32 +0000 Subject: Compiling VCL with pcc In-Reply-To: Your message of "Fri, 22 Jan 2010 18:31:37 +0100." <4B59E0F9.9060107@fsn.hu> Message-ID: <19238.1264414232@critter.freebsd.dk> In message <4B59E0F9.9060107 at fsn.hu>, Attila Nagy writes: >So I have three ways to get out of this problem: >1 install gcc (I can't and don't want currently) >2 use a small C compiler >3 use precompiled configuration >So my questions are: >- will 3 be possible in the near future? I have no plans about implementing this, because the content of the compiled configuration is very tightly bound to the varnishd internals so I really don't want to add a lot of complexity to prevent version skew. >- can anything be made to make pcc usable with varnish? Report the trouble to the pcc people. Run varnishd with -C option to capture a copy of the C program which pcc is being asked to compile. Check the line number and see what it chokes on. -- 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 phk at phk.freebsd.dk Mon Jan 25 10:16:58 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 25 Jan 2010 10:16:58 +0000 Subject: varnish crashes In-Reply-To: Your message of "Mon, 25 Jan 2010 11:06:51 +0100." <4B5D6D3B.1010004@netmatch.nl> Message-ID: <19285.1264414618@critter.freebsd.dk> In message <4B5D6D3B.1010004 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= writes: >On 24-1-2010 20:31, Michael S. Fischer wrote: >With Squid I was used to filling up the 300GB disks (we also serve large >images), but I guess Varnish does not work that way.. Well, it does, but the interaction with the kernels VM system is probably not optimal yet :-) How are your disks configured ? -- 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 a.hongens at netmatch.nl Mon Jan 25 10:21:41 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Mon, 25 Jan 2010 11:21:41 +0100 Subject: varnish crashes In-Reply-To: <19285.1264414618@critter.freebsd.dk> References: <19285.1264414618@critter.freebsd.dk> Message-ID: <4B5D70B5.5080807@netmatch.nl> On 25-1-2010 11:16, Poul-Henning Kamp wrote: > In message <4B5D6D3B.1010004 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= writes: >> On 24-1-2010 20:31, Michael S. Fischer wrote: > >> With Squid I was used to filling up the 300GB disks (we also serve large >> images), but I guess Varnish does not work that way.. > > Well, it does, but the interaction with the kernels VM system is probably > not optimal yet :-) > > How are your disks configured ? 2 cheap SATA disks in a gmirror (it's a simple Dell R300). $ gmirror list Geom name: gm0 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 2 ID: 639702359 Providers: 1. Name: mirror/gm0 Mediasize: 500107861504 (466G) Sectorsize: 512 Mode: r6w6e7 Consumers: 1. Name: ad4 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 3989333240 2. Name: ad6 Mediasize: 500107862016 (466G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 2 ID: 4010793071 -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From phk at phk.freebsd.dk Mon Jan 25 10:24:24 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 25 Jan 2010 10:24:24 +0000 Subject: varnish crashes In-Reply-To: Your message of "Mon, 25 Jan 2010 11:21:41 +0100." <4B5D70B5.5080807@netmatch.nl> Message-ID: <19332.1264415064@critter.freebsd.dk> In message <4B5D70B5.5080807 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: >> How are your disks configured ? > >2 cheap SATA disks in a gmirror (it's a simple Dell R300). Hmm, that's going to hurt obviously... You would probably have been better off, not mirroring and giving Varnish a -sfile for each disk. -- 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 a.hongens at netmatch.nl Mon Jan 25 11:21:58 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Mon, 25 Jan 2010 12:21:58 +0100 Subject: varnish crashes In-Reply-To: <19332.1264415064@critter.freebsd.dk> References: <19332.1264415064@critter.freebsd.dk> Message-ID: <4B5D7ED6.1090703@netmatch.nl> On 25-1-2010 11:24, Poul-Henning Kamp wrote: > In message <4B5D70B5.5080807 at netmatch.nl>, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr > ites: > >>> How are your disks configured ? >> >> 2 cheap SATA disks in a gmirror (it's a simple Dell R300). > > Hmm, that's going to hurt obviously... > > You would probably have been better off, not mirroring and giving > Varnish a -sfile for each disk. I'll take it into consideration, but first I'm going to run with the current configuration for a while to make sure varnish keeps responding. The disks are now 1-3% busy, and everything seems to run nice.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From a.hongens at netmatch.nl Mon Jan 25 11:56:57 2010 From: a.hongens at netmatch.nl (=?UTF-8?B?QW5nZWxvIEjDtm5nZW5z?=) Date: Mon, 25 Jan 2010 12:56:57 +0100 Subject: comparing 2 headers In-Reply-To: <871vhewnct.fsf@qurzaw.linpro.no> References: <4B57134E.8010300@netmatch.nl> <871vhewnct.fsf@qurzaw.linpro.no> Message-ID: <4B5D8709.2030405@netmatch.nl> On 25-1-2010 10:22, Tollef Fog Heen wrote: > | 3. I want to compare some headers, but I'm getting a compile error: > | > | Message from VCC-compiler: > | Expected CSTR got 'server.ip' > | (program line 266), at > | (input Line 1279 Pos 24) > | if (req.http.host == server.ip) { error 200 ok; } > | -----------------------#########-------------------- > | Running VCC-compiler failed, exit 1 > | VCL compilation failed > | > | I want to make sure that when I point my browser to http://w.x.y.z, I > | get a message "200 ok". Am I doing something wrong? I'm using > | Varnish-2.0.4 from ports by the way. > > Upgrade. This does work fine with at least 2.0.6 (just tested). Good to know, I'll wait for it to be in the freebsd ports, and try then. (I really like to stick to the ports for management and reporting purposes) > | 4. Is there some documentation on what the ReqEnd and StatSess values > | mean in the varnishlog output? The values seem interesting, but I have > | no idea what they are. > > http://varnish.projects.linpro.no/wiki/Varnishlog has the tiny start of > some docs. Help writing up the description of all the tags would be > appreciated. Thanks.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From kristian at redpill-linpro.com Mon Jan 25 13:15:46 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Mon, 25 Jan 2010 14:15:46 +0100 Subject: Cache utilization? In-Reply-To: <7014.1258549352@critter.freebsd.dk> References: <7014.1258549352@critter.freebsd.dk> Message-ID: <20100125131546.GA7792@kjeks.varnish-software.com> On Wed, Nov 18, 2009 at 01:02:32PM +0000, Poul-Henning Kamp wrote: > In message , =?iso-8859-1?Q? > Lars_J=F8rgensen?= writes: > >Hi, > > > >Obvious question but I can't find the answer anywhere: How do I > >know how much of my cache is utilized, i.e. is my cache file big > >enough? > > You can see if it is too small, because you will get LRU kill > activity in varnishstat. > > There is not really a good way to see if your cache is to big, and > apart from diskspace, there is no disadvantage to that. Well, I usually look at resident memory usage. That, and/or the "allocated/free" memory in varnishstat: If it never gets closed to filling, reducing the size could make sense. Or to turn it around: Buying more memory isn't likely to help you. (Though LRU would've told you that too.) -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From kristian at redpill-linpro.com Mon Jan 25 13:26:26 2010 From: kristian at redpill-linpro.com (Kristian Lyngstol) Date: Mon, 25 Jan 2010 14:26:26 +0100 Subject: varnishlog not behaving as expected (by me) In-Reply-To: <4B4DAD57.2050609@bmjgroup.com> References: <4B4DAD57.2050609@bmjgroup.com> Message-ID: <20100125132624.GB7792@kjeks.varnish-software.com> On Wed, Jan 13, 2010 at 11:24:07AM +0000, Alex Hooper wrote: > I'm having a bit of trouble using varnishlog. I am using: > > /usr/local/bin/varnishlog -o RxURL "^wp-admin$" All your urls start with /, so that will never match. Try "^/wp-admin" and you should have better luck. (...) > '/usr/local/bin/varnishlog' -i RxURL shows me the requests coming in. > '/usr/local/bin/varnishlog -i RxURL|grep wp-admin' shows that there are > generally no requests for wp-admin. Use the above approach instead. And how much traffic do you have? When you pipe it (for instance to grep), varnishlog will be buffered. -- Kristian Lyngst?l Redpill Linpro AS Mob: +47 99014497 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From kb+varnish at slide.com Mon Jan 25 19:15:38 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 25 Jan 2010 11:15:38 -0800 Subject: Release schedule for saint mode. In-Reply-To: <87wrz6v8lh.fsf@qurzaw.linpro.no> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> Message-ID: <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> I'd love to test persistent under production load, but right now it's not persistent. :-( (Storage doesn't persist through a parent restart) -- Ken On Jan 25, 2010, at 1:26 AM, Tollef Fog Heen wrote: > ]] pablort > > | And how about 2.1 ? Any release date on the horizon ? :D > > Persistent needs more testing before we can release it. If you're in a > position where you can test it: please do so and report back, especially > if you can make it crash with backtraces. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From john at 7fff.com Mon Jan 25 21:03:25 2010 From: john at 7fff.com (John Norman) Date: Mon, 25 Jan 2010 16:03:25 -0500 Subject: Restoring cookies on a miss Message-ID: Folks, I've been trying to implement a technique posted here to restore cookies on a cache miss. The original question is here: http://projects.linpro.no/pipermail/varnish-misc/2010-January/003505.html and an interesting answer is here: http://projects.linpro.no/pipermail/varnish-misc/2010-January/003506.html Below is my .vcl file. And again, here's the use case: We have certain pages that should never be cached. The user comes in with cookies set: "session=foo" or some such. We strip the cookie and do a lookup. If there's a hit, return what is in the cache. If there's a miss, we'd like to fetch with the cookie. Then, in fetch, pass for pages set for no-cache, and deliver for those that are public. It can be assumed that these pages are never hit first by non-cookied users. But -- I am seeing a lot of requests that have no cookies on the backend. John Here's the VCL: backend reviews0 { .host = "127.0.0.1"; .port = "7000"; } backend reviews1 { .host = "127.0.0.1"; .port = "7001"; } director reviews round-robin { { .backend = reviews0; } { .backend = reviews1; } } sub vcl_recv { unset req.http.user-agent; set req.backend = reviews; if (req.request != "GET" && req.request != "HEAD") { pass; } set req.http.OLD-Cookie = req.http.Cookie; unset req.http.cookie; lookup; } sub vcl_miss { if (req.http.OLD-Cookie) { set bereq.http.Cookie = req.http.OLD-Cookie; unset req.http.OLD-Cookie; } fetch; } sub vcl_fetch { unset obj.http.user-agent; if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~ "no-cache" || obj.http.Cache-Control ~ "private") { pass; } if (obj.http.Cache-Control ~ "public") { unset obj.http.Set-Cookie; deliver; } pass; } From kb+varnish at slide.com Mon Jan 25 22:42:14 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Mon, 25 Jan 2010 14:42:14 -0800 Subject: Restoring cookies on a miss In-Reply-To: References: Message-ID: If you sometimes see the proper cookies being passed to the back-end, I would think this would be a client problem? The VCL logic in question should either always work or never work. I just did a test of this, and I see the proper header hitting the back-end. Maybe you're seeing unexpectedly cookie-less requests? -- Ken On Jan 25, 2010, at 1:03 PM, John Norman wrote: > Folks, > > I've been trying to implement a technique posted here to restore > cookies on a cache miss. > > The original question is here: > > http://projects.linpro.no/pipermail/varnish-misc/2010-January/003505.html > > and an interesting answer is here: > > http://projects.linpro.no/pipermail/varnish-misc/2010-January/003506.html > > Below is my .vcl file. > > And again, here's the use case: > > We have certain pages that should never be cached. The user comes in > with cookies set: "session=foo" or some such. > > We strip the cookie and do a lookup. > > If there's a hit, return what is in the cache. > > If there's a miss, we'd like to fetch with the cookie. > > Then, in fetch, pass for pages set for no-cache, and deliver for those > that are public. > > It can be assumed that these pages are never hit first by non-cookied users. > > But -- I am seeing a lot of requests that have no cookies on the backend. > > John > > Here's the VCL: > > backend reviews0 { > .host = "127.0.0.1"; > .port = "7000"; > } > > backend reviews1 { > .host = "127.0.0.1"; > .port = "7001"; > } > > director reviews round-robin { > { .backend = reviews0; } > { .backend = reviews1; } > } > > sub vcl_recv { > > unset req.http.user-agent; > > set req.backend = reviews; > > if (req.request != "GET" && req.request != "HEAD") { > pass; > } > > set req.http.OLD-Cookie = req.http.Cookie; > unset req.http.cookie; > > lookup; > } > > sub vcl_miss { > if (req.http.OLD-Cookie) { > set bereq.http.Cookie = req.http.OLD-Cookie; > unset req.http.OLD-Cookie; > } > fetch; > } > > sub vcl_fetch { > > unset obj.http.user-agent; > > if (obj.http.Pragma ~ "no-cache" || > obj.http.Cache-Control ~ "no-cache" || > obj.http.Cache-Control ~ "private") { > pass; > } > > if (obj.http.Cache-Control ~ "public") { > unset obj.http.Set-Cookie; > deliver; > } > pass; > } > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From samcrawford at gmail.com Tue Jan 26 09:33:46 2010 From: samcrawford at gmail.com (Sam Crawford) Date: Tue, 26 Jan 2010 09:33:46 +0000 Subject: Varnish extensions for SSO support In-Reply-To: References: Message-ID: Any thoughts anyone? Good idea / bad idea? Thanks, Sam 2010/1/23 Sam Crawford : > Evening all, > > I've been an avid Varnish user both personally and at work for a > couple of years now. At work we use it to cache content across our > global intranet, handling a few million requests per day. At present, > we have the following logical setup... > > F5 GTM (GSLB device) > F5 load balancer > Varnish > In-house Java > Reverse Proxy > Backend applications (hundreds) > > Varnish and the in-house reverse proxy reside on the same servers, > with varnish having a single backend pointing at the in-house reverse > proxy (the F5s handle failover between instances). > > The in-house Java reverse proxy performs a range of functions, > including (but certainly not limited to): > > * Authenticating/authorising users via our Single Sign On service > * Header injection to help backend applications identify users > * Catching cookies from backend applications and delivering a single > pointer cookie back to clients > > I've been wondering if we could write some C extensions to Varnish to > remove the need for the Java reverse proxy. This would help flatten > the infrastructure and save on latency (which is pretty important for > us). The standard Varnish VCL capabilities would meet many of our > requirements, but for some functions we'd certainly need to write > extensions (such as making an out-of-band HTTP request to an SSO > server in order to validate an SSO cookie (which we'd also need to > cache!)). > > Whilst I know it's technically feasible for us to do this, I was > wondering (a) if anyone is already doing something similar and (b) if > the community thinks I'm completely mad for evening thinking about > doing it :-) > > Thanks, > > Sam > From a.hongens at netmatch.nl Tue Jan 26 10:29:01 2010 From: a.hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=) Date: Tue, 26 Jan 2010 11:29:01 +0100 Subject: 504 gateway time-out Message-ID: <4B5EC3ED.8030402@netmatch.nl> Can anyone tell me when a "504 Gateway Time-out" occurs exactly? I have varnish in front of haproxy, and whatever I do to, I can only get a "503 Service Unavailable" error, while my clients sometimes tell me they get the 504.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From l at lrowe.co.uk Tue Jan 26 14:48:41 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Tue, 26 Jan 2010 14:48:41 +0000 Subject: Varnish extensions for SSO support In-Reply-To: References: Message-ID: I keep meaning to look into mod_auth_tkt (http://www.openfusion.com.au/labs/mod_auth_tkt/) support for varnish. It should be fairly easy to implement with inline C and doing so would allow us to cache pages that require authorisation (by matching tokens in the signed cookie to tokens in an obj header.) So in principle I think it's a good idea. Laurence 2010/1/26 Sam Crawford : > Any thoughts anyone? Good idea / bad idea? > > Thanks, > > Sam > > > 2010/1/23 Sam Crawford : >> Evening all, >> >> I've been an avid Varnish user both personally and at work for a >> couple of years now. At work we use it to cache content across our >> global intranet, handling a few million requests per day. At present, >> we have the following logical setup... >> >> F5 GTM (GSLB device) > F5 load balancer > Varnish > In-house Java >> Reverse Proxy > Backend applications (hundreds) >> >> Varnish and the in-house reverse proxy reside on the same servers, >> with varnish having a single backend pointing at the in-house reverse >> proxy (the F5s handle failover between instances). >> >> The in-house Java reverse proxy performs a range of functions, >> including (but certainly not limited to): >> >> * Authenticating/authorising users via our Single Sign On service >> * Header injection to help backend applications identify users >> * Catching cookies from backend applications and delivering a single >> pointer cookie back to clients >> >> I've been wondering if we could write some C extensions to Varnish to >> remove the need for the Java reverse proxy. This would help flatten >> the infrastructure and save on latency (which is pretty important for >> us). The standard Varnish VCL capabilities would meet many of our >> requirements, but for some functions we'd certainly need to write >> extensions (such as making an out-of-band HTTP request to an SSO >> server in order to validate an SSO cookie (which we'd also need to >> cache!)). >> >> Whilst I know it's technically feasible for us to do this, I was >> wondering (a) if anyone is already doing something similar and (b) if >> the community thinks I'm completely mad for evening thinking about >> doing it :-) >> >> Thanks, >> >> Sam >> > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From samcrawford at gmail.com Tue Jan 26 22:27:15 2010 From: samcrawford at gmail.com (Sam Crawford) Date: Tue, 26 Jan 2010 22:27:15 +0000 Subject: Varnish extensions for SSO support In-Reply-To: References: Message-ID: Hi Laurence, Caching personalised content that uses cookies for identification is already possible with a bit of VCL magic. But, this is cached based upon a hash of their cookies, so if they open lots of browser sessions (with different cookies), then you get multiple copies of the content per user, which is a bad thing! So yes, if we could effectively put an SSO agent (that could validate tokens/tickets and extract the authenticated username) then you could cache on a per user basis (which would also be a use case I'd be interested in). Or, perhaps even more preferably, cached based upon a group or role basis (providing that data was made available). Anyway, I think I'm going to give this a shot. I'll probably start by trying to write a simple agent that makes calls against Sun's OpenSSO REST services (as that's where I have the most experience). Thanks, Sam 2010/1/26 Laurence Rowe : > I keep meaning to look into mod_auth_tkt > (http://www.openfusion.com.au/labs/mod_auth_tkt/) support for varnish. > It should be fairly easy to implement with inline C and doing so would > allow us to cache pages that require authorisation (by matching tokens > in the signed cookie to tokens in an obj header.) ?So in principle I > think it's a good idea. > > Laurence > > 2010/1/26 Sam Crawford : >> Any thoughts anyone? Good idea / bad idea? >> >> Thanks, >> >> Sam >> >> >> 2010/1/23 Sam Crawford : >>> Evening all, >>> >>> I've been an avid Varnish user both personally and at work for a >>> couple of years now. At work we use it to cache content across our >>> global intranet, handling a few million requests per day. At present, >>> we have the following logical setup... >>> >>> F5 GTM (GSLB device) > F5 load balancer > Varnish > In-house Java >>> Reverse Proxy > Backend applications (hundreds) >>> >>> Varnish and the in-house reverse proxy reside on the same servers, >>> with varnish having a single backend pointing at the in-house reverse >>> proxy (the F5s handle failover between instances). >>> >>> The in-house Java reverse proxy performs a range of functions, >>> including (but certainly not limited to): >>> >>> * Authenticating/authorising users via our Single Sign On service >>> * Header injection to help backend applications identify users >>> * Catching cookies from backend applications and delivering a single >>> pointer cookie back to clients >>> >>> I've been wondering if we could write some C extensions to Varnish to >>> remove the need for the Java reverse proxy. This would help flatten >>> the infrastructure and save on latency (which is pretty important for >>> us). The standard Varnish VCL capabilities would meet many of our >>> requirements, but for some functions we'd certainly need to write >>> extensions (such as making an out-of-band HTTP request to an SSO >>> server in order to validate an SSO cookie (which we'd also need to >>> cache!)). >>> >>> Whilst I know it's technically feasible for us to do this, I was >>> wondering (a) if anyone is already doing something similar and (b) if >>> the community thinks I'm completely mad for evening thinking about >>> doing it :-) >>> >>> Thanks, >>> >>> Sam >>> >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc >> > From l at lrowe.co.uk Wed Jan 27 01:37:40 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed, 27 Jan 2010 01:37:40 +0000 Subject: Varnish extensions for SSO support In-Reply-To: References: Message-ID: 2010/1/26 Sam Crawford : > Hi Laurence, > > Caching personalised content that uses cookies for identification is > already possible with a bit of VCL magic. But, this is cached based > upon a hash of their cookies, so if they open lots of browser sessions > (with different cookies), then you get multiple copies of the content > per user, which is a bad thing! > > So yes, if we could effectively put an SSO agent (that could validate > tokens/tickets and extract the authenticated username) then you could > cache on a per user basis (which would also be a use case I'd be > interested in). Or, perhaps even more preferably, cached based upon a > group or role basis (providing that data was made available). Moving content authorization to the network edge is the interesting one for me. A mod_auth_tkt cookie is essentially: !! The digest is created by hashing the ticket contents together with an optional ip address and a shared secret. It is validated on every access by the webserver by validating the digest with the shared secret. One obvious option for the token_list is to store a user's groups or roles. In vcl_recv, after validating the ticket, you would unpack the data and set X-Remote-User, X-Auth-Tokens, X-User-Data. A user might then have: X-Remote-User: jbloggs X-Auth-Tokens: user:jbloggs,role:Editor,group:LondonOffice X-User-Data: Joe Bloggs A page of content could be served by your appserver with a header: X-Allowed-Tokens: role:Manager,group:LondonOffice,group:BerlinOffice. In vcl_deliver you just need a routine that checks that req.http.X-Tokens intersects with resp.http.X-Allowed-Tokens. If not, it just return an unauthorized page. Laurence From me at mgoldman.com Wed Jan 27 03:23:57 2010 From: me at mgoldman.com (Martin Goldman) Date: Tue, 26 Jan 2010 22:23:57 -0500 Subject: Memory usage In-Reply-To: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> Message-ID: <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> Hello all, I'm running Varnish on a box with 4GB RAM. There are hundreds of thousands of objects being served, and I'm certain that they don't all fit in that relatively meager amount of RAM. I understand that Varnish's model dictates that the kernel will be trusted to use virtual memory as necessary if the cached objects don't fit in RAM. I have a few questions about this: 1. How can you tell whether your Varnish objects fit in RAM? 2. If I have objects residing in virtual memory, to what extent will my performance be adversely affected? If I want my site to be fast, do I basically need to go out and buy as much RAM as it will take so that virtual memory isn't needed? 3. I noticed tonight that my machine was using a few hundred megs of swap space, which I've never seen happen before. Varnish is the only non-system service running on this box. My understanding was that Varnish would get only as much RAM as was available and then send the overflow into the file-backed virtual memory. If that's the case, though, then why is swap space being used? Is this just a side effect of how the kernel allocates memory, or is something else going on here? Many thanks, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From darryl.dixon at winterhouseconsulting.com Wed Jan 27 03:34:01 2010 From: darryl.dixon at winterhouseconsulting.com (Darryl Dixon - Winterhouse Consulting) Date: Wed, 27 Jan 2010 16:34:01 +1300 (NZDT) Subject: Memory usage In-Reply-To: <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> Message-ID: <60655.58.28.124.90.1264563241.squirrel@services.directender.co.nz> Hi Martin, > I'm running Varnish on a box with 4GB RAM. There are hundreds of thousands > of objects being served, and I'm certain that they don't all fit in that > relatively meager amount of RAM. I understand that Varnish's model > dictates > that the kernel will be trusted to use virtual memory as necessary if the > cached objects don't fit in RAM. I have a few questions about this: > > 1. How can you tell whether your Varnish objects fit in RAM? In short, `top` - the VIRT column tells you total virtual process size, the RES column then tells you which portion of that is currently resident in physical memory > 2. If I have objects residing in virtual memory, to what extent will my > performance be adversely affected? If I want my site to be fast, do I > basically need to go out and buy as much RAM as it will take so that > virtual memory isn't needed? Pretty much. > 3. I noticed tonight that my machine was using a few hundred megs of swap > space, which I've never seen happen before. Varnish is the only non-system > service running on this box. My understanding was that Varnish would get > only as much RAM as was available and then send the overflow into the > file-backed virtual memory. If that's the case, though, then why is swap > space being used? Is this just a side effect of how the kernel allocates > memory, or is something else going on here? Two things; 1) The varnish process itself requires memory (eg, to hold the ban list etc), which is not part of the file-backed object cache. 2) Even if the above usage were minimal, it is still entirely possibly that your VMM (the OS) has decided that the memory being used to cache objects is more important that some other system processes that have now been shunted out to swap. Once again, `top` VIRT versus RES will give you a good clue regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com From me at mgoldman.com Wed Jan 27 03:51:52 2010 From: me at mgoldman.com (Martin Goldman) Date: Tue, 26 Jan 2010 22:51:52 -0500 Subject: Memory usage In-Reply-To: <60655.58.28.124.90.1264563241.squirrel@services.directender.co.nz> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> <60655.58.28.124.90.1264563241.squirrel@services.directender.co.nz> Message-ID: <24a219a51001261951j54bcd05enf5142500d6ee95da@mail.gmail.com> Thanks Darryl! One follow-up about the VIRT size (mine is 55.2GB). I thought the VIRT size includes the entire amount of VARNISH_STORAGE_SIZE (50GB in my case), regardless of how much of the virtual memory is actually being used to store cached objects. This seems to be the case based on a few minutes of experimenting with that setting. So I'm not sure I understand how to determine the amount of virtual memory I'm actually using -- in other words, the amount of RAM I need to add for optimal performance -- from the VIRT and RES numbers alone. Any chance I could ask you to please fill in what I'm missing? Thanks again, Martin On Tue, Jan 26, 2010 at 10:34 PM, Darryl Dixon - Winterhouse Consulting < darryl.dixon at winterhouseconsulting.com> wrote: > Hi Martin, > > > I'm running Varnish on a box with 4GB RAM. There are hundreds of > thousands > > of objects being served, and I'm certain that they don't all fit in that > > relatively meager amount of RAM. I understand that Varnish's model > > dictates > > that the kernel will be trusted to use virtual memory as necessary if the > > cached objects don't fit in RAM. I have a few questions about this: > > > > 1. How can you tell whether your Varnish objects fit in RAM? > > In short, `top` - the VIRT column tells you total virtual process size, > the RES column then tells you which portion of that is currently resident > in physical memory > > > 2. If I have objects residing in virtual memory, to what extent will my > > performance be adversely affected? If I want my site to be fast, do I > > basically need to go out and buy as much RAM as it will take so that > > virtual memory isn't needed? > > Pretty much. > > > 3. I noticed tonight that my machine was using a few hundred megs of swap > > space, which I've never seen happen before. Varnish is the only > non-system > > service running on this box. My understanding was that Varnish would get > > only as much RAM as was available and then send the overflow into the > > file-backed virtual memory. If that's the case, though, then why is swap > > space being used? Is this just a side effect of how the kernel allocates > > memory, or is something else going on here? > > Two things; > 1) The varnish process itself requires memory (eg, to hold the ban list > etc), which is not part of the file-backed object cache. > 2) Even if the above usage were minimal, it is still entirely possibly > that your VMM (the OS) has decided that the memory being used to cache > objects is more important that some other system processes that have now > been shunted out to swap. Once again, `top` VIRT versus RES will give you > a good clue > > regards, > Darryl Dixon > Winterhouse Consulting Ltd > http://www.winterhouseconsulting.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darryl.dixon at winterhouseconsulting.com Wed Jan 27 04:07:11 2010 From: darryl.dixon at winterhouseconsulting.com (Darryl Dixon - Winterhouse Consulting) Date: Wed, 27 Jan 2010 17:07:11 +1300 (NZDT) Subject: Memory usage In-Reply-To: <24a219a51001261951j54bcd05enf5142500d6ee95da@mail.gmail.com> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> <60655.58.28.124.90.1264563241.squirrel@services.directender.co.nz> <24a219a51001261951j54bcd05enf5142500d6ee95da@mail.gmail.com> Message-ID: <55611.58.28.124.90.1264565231.squirrel@services.directender.co.nz> > Thanks Darryl! > > One follow-up about the VIRT size (mine is 55.2GB). I thought the VIRT > size > includes the entire amount of VARNISH_STORAGE_SIZE (50GB in my case), > regardless of how much of the virtual memory is actually being used to > store cached objects. This seems to be the case based on a few minutes of > experimenting with that setting. That is correct. I was assuming from your initial post (probably wrongly) that your cache was 'full' ie, that there were in your case 50GB of objects cached already. You can see how much of the allocated cache is used with varnishstat; the "bytes allocated" and "bytes free" row will tell you this. Unfortunately, what you want is the intersection of "bytes allocated" and "bytes not currently in physical memory" and if the entire cache is not full, then it gets pretty tough to know, because Varnish *by design* neither knows nor cares about the OSes swapping arrangements. > o I'm not sure I understand how to > determine the amount of virtual memory I'm actually using -- in other > words, the amount of RAM I need to add for optimal performance -- from > the VIRT and RES numbers alone. Any chance I could ask you to please fill > in what I'm missing? Probably the two entries from the varnishstat output I mentioned above will give you a better idea. Obviously, if you really have 50GB of items to cache, then you will need a lot of RAM. Perhaps if you monitor the "bytes allocated" row over time you will see it stabilise - this is the amount of RAM that you would need to keep all your cacheable items in physical memory. Of course, just because something ends up in the cache once, doesn't mean there is necessarily any value in keeping it in physical memory; if no-one ever requests it again, then it makes sense for it to end up in swap... regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com From fulanpeng at gmail.com Wed Jan 27 04:07:56 2010 From: fulanpeng at gmail.com (fulan Peng) Date: Wed, 27 Jan 2010 12:07:56 +0800 Subject: Some web site make Varnish return a blank page Message-ID: Hi Varnish gurus: I am new to varnish. I got Varnish working with default config with one web site. when I change to another web site, varnish response with a blank page. wget can normally fetch the index.html page. When I start varnishlog and cat varnish.log file, there are a lot of PING and PONG. No clue what is wrong. No other error message. Please help me out! Thank you! Fulan Peng From michael at dynamine.net Wed Jan 27 05:23:34 2010 From: michael at dynamine.net (Michael Fischer) Date: Tue, 26 Jan 2010 21:23:34 -0800 Subject: Memory usage In-Reply-To: <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> Message-ID: On Tue, Jan 26, 2010 at 7:23 PM, Martin Goldman wrote: I'm running Varnish on a box with 4GB RAM. There are hundreds of thousands > of objects being served, and I'm certain that they don't all fit in that > relatively meager amount of RAM. I understand that Varnish's model dictates > that the kernel will be trusted to use virtual memory as necessary if the > cached objects don't fit in RAM. I have a few questions about this: > > 1. How can you tell whether your Varnish objects fit in RAM? > You can't guarantee that they will unless you set your cache size at or below the amount of RAM you have installed. > 2. If I have objects residing in virtual memory, to what extent will my > performance be adversely affected? If I want my site to be fast, do I > basically need to go out and buy as much RAM as it will take so that virtual > memory isn't needed? > Technically, it's "go out and buy as much RAM as it will take to avoid being swamped by paging". But yes. > 3. I noticed tonight that my machine was using a few hundred megs of swap > space, which I've never seen happen before. Varnish is the only non-system > service running on this box. My understanding was that Varnish would get > only as much RAM as was available and then send the overflow into the > file-backed virtual memory. If that's the case, though, then why is swap > space being used? Is this just a side effect of how the kernel allocates > memory, or is something else going on here? > Is your backing store file-based, or malloc-based? If the latter, that would explain the swap space being consumed. Or, as Darryl said, the housekeeping overhead of a VERY large file-backed cache could make the Varnish process very large. --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at redpill-linpro.com Wed Jan 27 07:54:00 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 27 Jan 2010 08:54:00 +0100 Subject: Varnish extensions for SSO support In-Reply-To: (Sam Crawford's message of "Sat, 23 Jan 2010 21:13:23 +0000") References: Message-ID: <87bpggnftz.fsf@qurzaw.linpro.no> ]] Sam Crawford | Whilst I know it's technically feasible for us to do this, I was | wondering (a) if anyone is already doing something similar and (b) if | the community thinks I'm completely mad for evening thinking about | doing it :-) a) Not to my knowledge, but I've had people ask similar questions in the past, but then more of a ?is it easy to do authentication in Varnish? question. b) Done carefully, it sounds reasonable enough to have. Depending on how much traffic you have, you want to cache and keep as much of this information in varnish itself so you don't have to open connections and ask network services for each cache hit. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 27 07:57:21 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 27 Jan 2010 08:57:21 +0100 Subject: Restoring cookies on a miss In-Reply-To: (John Norman's message of "Mon, 25 Jan 2010 16:03:25 -0500") References: Message-ID: <877hr4nfoe.fsf@qurzaw.linpro.no> ]] John Norman Hi, | And again, here's the use case: | | We have certain pages that should never be cached. The user comes in | with cookies set: "session=foo" or some such. | | We strip the cookie and do a lookup. | | If there's a hit, return what is in the cache. | | If there's a miss, we'd like to fetch with the cookie. | | Then, in fetch, pass for pages set for no-cache, and deliver for those | that are public. Sounds reasonable enough. | It can be assumed that these pages are never hit first by non-cookied users. | | But -- I am seeing a lot of requests that have no cookies on the backend. Can you capture a varnishlog from when this happens? It'd be interesting to see if the incoming request has a cookie set. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Wed Jan 27 07:58:49 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 27 Jan 2010 08:58:49 +0100 Subject: 504 gateway time-out In-Reply-To: <4B5EC3ED.8030402@netmatch.nl> ("Angelo =?utf-8?Q?H=C3=B6ngen?= =?utf-8?Q?s=22's?= message of "Tue, 26 Jan 2010 11:29:01 +0100") References: <4B5EC3ED.8030402@netmatch.nl> Message-ID: <873a1snfly.fsf@qurzaw.linpro.no> ]] Angelo H?ngens | Can anyone tell me when a "504 Gateway Time-out" occurs exactly? | | I have varnish in front of haproxy, and whatever I do to, I can only get | a "503 Service Unavailable" error, while my clients sometimes tell me | they get the 504.. I don't believe we ever send out 504s. Maybe it's from haproxy when the backend it's talking to takes too long to respond? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From a.hongens at netmatch.nl Wed Jan 27 08:10:42 2010 From: a.hongens at netmatch.nl (=?UTF-8?B?QW5nZWxvIEjDtm5nZW5z?=) Date: Wed, 27 Jan 2010 09:10:42 +0100 Subject: 504 gateway time-out In-Reply-To: <873a1snfly.fsf@qurzaw.linpro.no> References: <4B5EC3ED.8030402@netmatch.nl> <873a1snfly.fsf@qurzaw.linpro.no> Message-ID: <4B5FF502.3090208@netmatch.nl> On 27-1-2010 8:58, Tollef Fog Heen wrote: > ]] Angelo H?ngens > > | Can anyone tell me when a "504 Gateway Time-out" occurs exactly? > | > | I have varnish in front of haproxy, and whatever I do to, I can only get > | a "503 Service Unavailable" error, while my clients sometimes tell me > | they get the 504.. > > I don't believe we ever send out 504s. Maybe it's from haproxy when the > backend it's talking to takes too long to respond? That must be it, thanks.. -- With kind regards, Angelo H?ngens systems administrator MCSE on Windows 2003 MCSE on Windows 2000 MS Small Business Specialist ------------------------------------------ NetMatch tourism internet software solutions Ringbaan Oost 2b 5013 CA Tilburg +31 (0)13 5811088 +31 (0)13 5821239 A.Hongens at netmatch.nl www.netmatch.nl ------------------------------------------ From plfgoa at gmail.com Wed Jan 27 08:25:39 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Wed, 27 Jan 2010 13:55:39 +0530 Subject: Varnish Prefetch In-Reply-To: <18799.1264409096@critter.freebsd.dk> References: <75cf5801001241820w3e4afd34v64ad2031b8b71b2@mail.gmail.com> <18799.1264409096@critter.freebsd.dk> Message-ID: <75cf5801001270025s722f114ax9335dba334a84007@mail.gmail.com> Hi Poul, Thanks for the response . So with grace mode is it possible to fetch an object from backend about "x" seconds before its "expires" time is reached ? Thank you. -Paras On Mon, Jan 25, 2010 at 2:14 PM, Poul-Henning Kamp wrote: > In message <75cf5801001241820w3e4afd34v64ad2031b8b71b2 at mail.gmail.com>, > Paras Fadte writes: > > >> Is prefetch by default enabled in varnish ? > > Prefetch never got implemented, we found other ideas to solve the problem, > such as grace mode. > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From plfgoa at gmail.com Wed Jan 27 08:26:06 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Wed, 27 Jan 2010 13:56:06 +0530 Subject: Varnish Prefetch In-Reply-To: <87sk9uv8jt.fsf@qurzaw.linpro.no> References: <75cf5801001212132o636f52day5e3c303af118380e@mail.gmail.com> <87sk9uv8jt.fsf@qurzaw.linpro.no> Message-ID: <75cf5801001270026q349384edpf36e7cbadcee7715@mail.gmail.com> Hi Tollef, Thanks for the response. -Paras On Mon, Jan 25, 2010 at 2:57 PM, Tollef Fog Heen wrote: > ]] Paras Fadte > > | Is prefetch by default enabled in varnish ? > > No, it is not implemented and any references to it should be ignored. > It is also removed in trunk. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfheen at redpill-linpro.com Wed Jan 27 09:26:12 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Wed, 27 Jan 2010 10:26:12 +0100 Subject: Release schedule for saint mode. In-Reply-To: <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> (Ken Brownfield's message of "Mon, 25 Jan 2010 11:15:38 -0800") References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> Message-ID: <87aavznbkb.fsf@qurzaw.linpro.no> ]] Ken Brownfield | I'd love to test persistent under production load, but right now it's | not persistent. :-( (Storage doesn't persist through a parent restart) That sounds like a real bug. Just to be sure, you're testing with -spersistent, not -smalloc or -sfile? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From vlists at veus.hr Wed Jan 27 15:50:27 2010 From: vlists at veus.hr (Vladimir Vuksan) Date: Wed, 27 Jan 2010 10:50:27 -0500 (EST) Subject: 504 gateway time-out In-Reply-To: <4B5FF502.3090208@netmatch.nl> References: <4B5EC3ED.8030402@netmatch.nl> <873a1snfly.fsf@qurzaw.linpro.no> <4B5FF502.3090208@netmatch.nl> Message-ID: Yes 504 is certainly given out by haproxy. It is known to do that :-/. On Wed, 27 Jan 2010, Angelo H?ngens wrote: > On 27-1-2010 8:58, Tollef Fog Heen wrote: >> ]] Angelo H?ngens >> >> | Can anyone tell me when a "504 Gateway Time-out" occurs exactly? >> | >> | I have varnish in front of haproxy, and whatever I do to, I can only get >> | a "503 Service Unavailable" error, while my clients sometimes tell me >> | they get the 504.. >> >> I don't believe we ever send out 504s. Maybe it's from haproxy when the >> backend it's talking to takes too long to respond? > > That must be it, thanks.. > > > -- > > > With kind regards, > > > Angelo H?ngens > systems administrator > > MCSE on Windows 2003 > MCSE on Windows 2000 > MS Small Business Specialist > ------------------------------------------ > NetMatch > tourism internet software solutions > > Ringbaan Oost 2b > 5013 CA Tilburg > +31 (0)13 5811088 > +31 (0)13 5821239 > > A.Hongens at netmatch.nl > www.netmatch.nl > ------------------------------------------ > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From john at 7fff.com Wed Jan 27 17:47:14 2010 From: john at 7fff.com (John Norman) Date: Wed, 27 Jan 2010 12:47:14 -0500 Subject: Bug fix 601 - Will be in the next release? Message-ID: Folks, Will the fix for http://varnish-cache.org/ticket/601 (cf. http://varnish-cache.org/ticket/540) be in the next release? My Varnish gets a x-forwarded-for from another server: What will the VCL be to use that instead of whatever Varnish tries to append? John From kb+varnish at slide.com Wed Jan 27 20:08:06 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Wed, 27 Jan 2010 12:08:06 -0800 Subject: Release schedule for saint mode. In-Reply-To: <87aavznbkb.fsf@qurzaw.linpro.no> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> <87aavznbkb.fsf@qurzaw.linpro.no> Message-ID: Right, -spersistent. Child restarts are persistent, parent process stop/start isn't. Maybe there's a graceful, undocumented method of stopping the parent that I'm not aware of? -- kb On Jan 27, 2010, at 1:26 AM, Tollef Fog Heen wrote: > ]] Ken Brownfield > > | I'd love to test persistent under production load, but right now it's > | not persistent. :-( (Storage doesn't persist through a parent restart) > > That sounds like a real bug. Just to be sure, you're testing with > -spersistent, not -smalloc or -sfile? > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc From pablort+varnish at gmail.com Wed Jan 27 21:24:05 2010 From: pablort+varnish at gmail.com (pablort) Date: Wed, 27 Jan 2010 19:24:05 -0200 Subject: Release schedule for saint mode. In-Reply-To: <87wrz6v8lh.fsf@qurzaw.linpro.no> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> Message-ID: <7ae911871001271324l57c5db4bv1a217f2737bc0dfd@mail.gmail.com> I'll try to setup a lab environment and replay my acesslogs there until it crashes. Need to finish graphics thou. :) On Mon, Jan 25, 2010 at 7:26 AM, Tollef Fog Heen wrote: > ]] pablort > > | And how about 2.1 ? Any release date on the horizon ? :D > > Persistent needs more testing before we can release it. If you're in a > position where you can test it: please do so and report back, especially > if you can make it crash with backtraces. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablort+varnish at gmail.com Wed Jan 27 22:37:47 2010 From: pablort+varnish at gmail.com (pablort) Date: Wed, 27 Jan 2010 20:37:47 -0200 Subject: Varnish graphs Message-ID: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> Hello there, I've sucessfully created graphics based on varnishstat -1 output using cacti and snmp and I'd really like to do the same thing using varnishtop to graph TxStatus responses, but it didn't work as I expected. $ varnishtop -1 -i TxStatus 29481.00 TxStatus 3280.00 TxStatus 1196.00 TxStatus 376.00 TxStatus 23.00 TxStatus 3.00 TxStatus 3.00 TxStatus The numbers do reflect the TxStatus'es that I see in interactive varnishtop, but when I try to run it with -1, it doesn't show which entry corresponds to which status. LOL. So, is this supposed to be like this or should I file a bug for that ? Also, what do you guys use for performance analysis ? []'s -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablort+varnish at gmail.com Wed Jan 27 22:42:26 2010 From: pablort+varnish at gmail.com (pablort) Date: Wed, 27 Jan 2010 20:42:26 -0200 Subject: Bug fix 601 - Will be in the next release? In-Reply-To: References: Message-ID: <7ae911871001271442h2120493amb76977679d9e9d82@mail.gmail.com> Have you tried google "varnish x-forwarded-for" ? There an FAQ entry addressing that (somewhat). []'s On Wed, Jan 27, 2010 at 3:47 PM, John Norman wrote: > Folks, > > Will the fix for http://varnish-cache.org/ticket/601 (cf. > http://varnish-cache.org/ticket/540) be in the next release? > > My Varnish gets a x-forwarded-for from another server: What will the > VCL be to use that instead of whatever Varnish tries to append? > > John > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablort+varnish at gmail.com Wed Jan 27 23:00:03 2010 From: pablort+varnish at gmail.com (pablort) Date: Wed, 27 Jan 2010 21:00:03 -0200 Subject: [varnish] Re: [varnish] Re: Handling of cache-control In-Reply-To: <30b80c9f1001200119p1e69b0b3jb20f5714fc574e0e@mail.gmail.com> References: <84910.1263861424@critter.freebsd.dk> <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> <670ABC7B-093A-4687-90D2-C1B50038F082@digitalmarbles.com> <30b80c9f1001200119p1e69b0b3jb20f5714fc574e0e@mail.gmail.com> Message-ID: <7ae911871001271500r1dcd9826pecddad23790b4ecd@mail.gmail.com> Isn't this the equivalent of and max-age=5 and s-maxage=0 ? On Wed, Jan 20, 2010 at 7:19 AM, Bedis 9 wrote: > Hi, > > Netcache devices had the X-Accel-Cache-Control headers in order to > allow an origin server to setup different Cache-Control parameters for > the cache and the end-user. > The netcache will follow the X-Accel-Cache-Control while the end user > will follow the Cache-Control. > > I've a few customer using this, mainly for sports events where "live" > is the key. > They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is > set to no-cache. > That way, all the load generated by thousends of request per second > for "live" stuff is offloaded to the cache layer. > Only a few request goes back to the origin. > > > I was able to reproduce such behavior with the following inline C: > sub vcl_fetch { > [...] > # Check if X-Accel-Cache-Control exists and follow it > if (obj.http.X-Accel-Cache-Control) { > C{ > char *cache; > int max_age = 0; > cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:"); > if(cache) { > char *s = NULL; > /* Looking for max-age */ > if (s = strstr(cache, "max-age=")) { > s+=8; > max_age = strtoul(s, 0, 0); > if (max_age) { > VRT_l_obj_ttl(sp, max_age); > } > } > } > }C > unset obj.http.X-Accel-Cache-Control; > } > > # Cache-Control and Pragma headers preventing caching > if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~ > "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)")) > { > pass; > } > > } > > [...] > > } > > > Maybe it can be useful to somebody else :) > > cheers > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moseleymark at gmail.com Thu Jan 28 03:07:35 2010 From: moseleymark at gmail.com (Mark Moseley) Date: Wed, 27 Jan 2010 19:07:35 -0800 Subject: Varnish graphs In-Reply-To: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> References: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> Message-ID: <294d5daa1001271907r5ea5b28bx1baf82e26be647d6@mail.gmail.com> On Wed, Jan 27, 2010 at 2:37 PM, pablort wrote: > Hello there, > > I've sucessfully created graphics based on varnishstat -1 output using cacti > and snmp and I'd really like to do the same thing using varnishtop to graph > TxStatus responses, but it didn't work as I expected. > > $ varnishtop -1 -i TxStatus > ?29481.00 TxStatus > ? 3280.00 TxStatus > ? 1196.00 TxStatus > ?? 376.00 TxStatus > ??? 23.00 TxStatus > ???? 3.00 TxStatus > ???? 3.00 TxStatus > > The numbers do reflect the TxStatus'es that I see in interactive varnishtop, > but when I try to run it with -1, it doesn't show which entry corresponds to > which status. LOL. > > So, is this supposed to be like this or should I file a bug for that ? > > Also, what do you guys use for performance analysis ? I use varnishstat + collectd with a little python module (which means collectd 4.9.0 or higher, with the python module included -- I can post the Perl version that the python module replaced, which will work in pre-4.9.x). I'm only grabbing a few things and aggregating some (like all LRU events), but it'd be easy to modify to grab other things. If you'd like to take a look, I'll paste the module here (but be forewarned I'm not python wiz, so this "good enough" for me). In collectd.conf, along with the regular config, you'll need: Globals true ModulePath "/path/to/your/collectd/python/modules" Import "varnish.stats" # Optional if different from path in module # # varnishstat_binary "/some/other/path/to/varnishstat" # Here's varnish/stats.py import collectd, sys, time, subprocess, os.path from pprint import pformat varnishstat_binary = "/usr/bin/varnishstat" # Map fields field_map = { "client_req": "count_reqs", "cache_hit": "count_hits", "n_wrk_failed": "count_workerr", "n_wrk_max": "count_workerr", "n_wrk_queue": "count_workerr", "n_wrk_overflow": "count_workerr", "n_wrk_drop": "count_workerr", "n_lru_nuked": "count_lru", "n_lru_saved": "count_lru", "n_lru_moved": "count_lru", } fields_to_query = ",".join( field_map.keys() ) def varnish_stats_config ( Cfg ): global varnishstat_binary for child in Cfg.children: if child.key == "varnishstat_binary": collectd.debug( "[varnish_stats_config] config arg set key %s: %s" % ( child.key, child.values[0] ) ) varnishstat_binary = child.values[0] def varnish_stats_init ( ): if not os.path.exists( varnishstat_binary ): collectd.error( "Can't find varnishstat binary at %s, disabling plugin" % ( varnishstat_binary ) ) collectd.unregister_read( varnish_stats_read ) def varnish_stats_read ( Data=None ): count_lru, count_hits, count_reqs, count_workerr = 0, 0, 0, 0 stats = {} fh = subprocess.Popen( [ varnishstat_binary, "-1", "-f", fields_to_query ], stdout=subprocess.PIPE ) lines = fh.stdout.readlines() fh.stdout.close() for line in lines: field, val, dummy = line.strip().split( None, 2 ) if field_map.has_key( field ): if stats.has_key( field_map[ field ] ): stats[ field_map[ field ] ] += int( val ) else: stats[ field_map[ field ] ] = int( val ) for field in ( stats.keys() ): if stats.has_key( field ): collectd.debug( "[varnish_stats_read] Dispatch %s: %d" % ( field, stats[ field ] ) ) stats_data = collectd.Values( type="operations" ) stats_data.plugin = "varnish-stats" stats_data.dispatch( values=[ stats[ field ] ], type_instance=field ) else: continue collectd.error( "[varnish_stats_read] Unable to dispatch key: %s" % ( field ) ) collectd.register_config( varnish_stats_config ) collectd.register_read( varnish_stats_read ) collectd.register_init( varnish_stats_init ) From john at 7fff.com Thu Jan 28 03:54:06 2010 From: john at 7fff.com (John Norman) Date: Wed, 27 Jan 2010 22:54:06 -0500 Subject: Bug fix 601 - Will be in the next release? In-Reply-To: <7ae911871001271442h2120493amb76977679d9e9d82@mail.gmail.com> References: <7ae911871001271442h2120493amb76977679d9e9d82@mail.gmail.com> Message-ID: Yes, but the workarounds seem to replace x-forwarded-for with another header, e.g., X-Real-Forwarded-For (https://wiki.fourkitchens.com/display/PF/Workaround+for+Varnish+X-Forwarded-For+bug). And the FAQ entry (http://varnish-cache.org/wiki/FAQ#HowcanIlogtheclientIPaddressonthebackend) seems to assume that there is nothing fronting Varnish that has already added an x-forwarded-for header (which is what the bug is about). In any case, I assume that the fix for bug 601 will go into the next release . . . On Wed, Jan 27, 2010 at 5:42 PM, pablort wrote: > Have you tried google "varnish x-forwarded-for" ? > > There an FAQ entry addressing that (somewhat). > > []'s > > On Wed, Jan 27, 2010 at 3:47 PM, John Norman wrote: >> >> Folks, >> >> Will the fix for http://varnish-cache.org/ticket/601 (cf. >> http://varnish-cache.org/ticket/540) be in the next release? >> >> My Varnish gets a x-forwarded-for from another server: What will the >> VCL be to use that instead of whatever Varnish tries to append? >> >> John >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > From martin.boer at netclever.nl Thu Jan 28 08:25:33 2010 From: martin.boer at netclever.nl (Martin Boer) Date: Thu, 28 Jan 2010 09:25:33 +0100 Subject: Some web site make Varnish return a blank page In-Reply-To: References: Message-ID: <4B6149FD.20304@netclever.nl> I'm not a guru so I could really use more information to figure out exactly what is happening. Are you implying that when you have varnish in front of your 2 websites it is working correctly when accessing the sites through wget but not hen using internet explorer and/or firefox ? If so, could you paste some varnishlog of wget -> varnish -> site1 -> site2 firefox -> varnish -> site1 -> site2 explorer -> varnish -> site1 -> site2 and describe for each if it is working or not. Martin fulan Peng wrote: > Hi Varnish gurus: > > I am new to varnish. I got Varnish working with default config with > one web site. > when I change to another web site, varnish response with a blank page. > > wget can normally fetch the index.html page. > > When I start varnishlog and cat varnish.log file, there are a lot of > PING and PONG. No clue what is wrong. > > No other error message. > > Please help me out! Thank you! > > Fulan Peng > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > > From abhishek.rhce at gmail.com Thu Jan 28 09:09:28 2010 From: abhishek.rhce at gmail.com (Abhishek Singh) Date: Thu, 28 Jan 2010 14:39:28 +0530 Subject: Not Able to Purge in Varnish Message-ID: <25daf17a1001280109r582200d7s5a498749b18f4969@mail.gmail.com> Hi All, I am using varnish for static files caching and multiple domains are getting served from varnish cluster and i want to purge static files for specific domain so how can i do that. I tired following but it is not working. 1) purge req.http.host ~ xyz.com 101 44 Unknown request. Type 'help' for more info 2) url.purge req.http.host ~ xyz.com 105 20 Too many parameters Please let me know how can purge domain specific files. -- Abhishek Kumar Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bedis9 at gmail.com Thu Jan 28 09:59:55 2010 From: bedis9 at gmail.com (Bedis 9) Date: Thu, 28 Jan 2010 10:59:55 +0100 Subject: [varnish] Re: [varnish] Re: Handling of cache-control In-Reply-To: <7ae911871001271500r1dcd9826pecddad23790b4ecd@mail.gmail.com> References: <84910.1263861424@critter.freebsd.dk> <964B3ECA-10B3-432A-A8A1-9A5535A22C69@digitalmarbles.com> <670ABC7B-093A-4687-90D2-C1B50038F082@digitalmarbles.com> <30b80c9f1001200119p1e69b0b3jb20f5714fc574e0e@mail.gmail.com> <7ae911871001271500r1dcd9826pecddad23790b4ecd@mail.gmail.com> Message-ID: <30b80c9f1001280159j2b524292rcbfa15a47419144f@mail.gmail.com> hey, That way, any shared proxy cache on the path between our caches and the client would cache the object. Our customer didn't want this. The purpose was to have the freshest information as close as the origin as possible. cheers On Thu, Jan 28, 2010 at 12:00 AM, pablort wrote: > Isn't this the equivalent of and max-age=5 and s-maxage=0 ? > > On Wed, Jan 20, 2010 at 7:19 AM, Bedis 9 wrote: >> >> Hi, >> >> Netcache devices had the X-Accel-Cache-Control headers in order to >> allow an origin server to setup different Cache-Control parameters for >> the cache and the end-user. >> The netcache will follow the X-Accel-Cache-Control while the end user >> will follow the Cache-Control. >> >> I've a few customer using this, mainly for sports events where "live" >> is the key. >> They setup X-Accel-Cache-Control to max-age=5 while Cache-Control is >> set to no-cache. >> That way, all the load generated by thousends of request per second >> for "live" stuff is offloaded to the cache layer. >> Only a few request goes back to the origin. >> >> >> I was able to reproduce such behavior with the following inline C: >> sub vcl_fetch { >> [...] >> # Check if X-Accel-Cache-Control exists and follow it >> ? ? ? ?if (obj.http.X-Accel-Cache-Control) { >> C{ >> ? ? ? ?char *cache; >> ? ? ? ?int max_age = 0; >> ? ? ? ?cache = VRT_GetHdr(sp, HDR_OBJ, "\026X-Accel-Cache-Control:"); >> ? ? ? ?if(cache) { >> ? ? ? ? ? ? ? ?char *s = NULL; >> ? ? ? ? ? ? ? ?/* Looking for max-age */ >> ? ? ? ? ? ? ? ?if (s = strstr(cache, "max-age=")) { >> ? ? ? ? ? ? ? ? ? ? ? ?s+=8; >> ? ? ? ? ? ? ? ? ? ? ? ?max_age = strtoul(s, 0, 0); >> ? ? ? ? ? ? ? ? ? ? ? ?if (max_age) { >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VRT_l_obj_ttl(sp, max_age); >> ? ? ? ? ? ? ? ? ? ? ? ?} >> ? ? ? ? ? ? ? ?} >> ? ? ? ?} >> }C >> ? ? ? unset obj.http.X-Accel-Cache-Control; >> ? ? ? ?} >> >> # Cache-Control and Pragma headers preventing caching >> ? ? ? ?if ((!obj.http.X-Accel-Cache-Control) && (obj.http.Pragma ~ >> "no-cache" || obj.http.Cache-Control ~ "(no-cache|no-store|private)")) >> { >> ? ? ? ? ? ? ? ?pass; >> ? ? ? ?} >> >> } >> >> [...] >> >> } >> >> >> Maybe it can be useful to somebody else :) >> >> cheers >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > From bert-jan at bugbyte.nl Thu Jan 28 11:02:25 2010 From: bert-jan at bugbyte.nl (Bert-Jan de Lange) Date: Thu, 28 Jan 2010 12:02:25 +0100 Subject: Assert error in VRT_ESI Message-ID: <4B616EC1.604@bugbyte.nl> Hi everybody, I'm trying to experiment with ESI but even the simplest setup crashes. My setup is FreeBSD 7.2, apache 2.2.14, varnish 2.0.6 from ports. I have a simple page: index.html include.html

Test

When I open it through Varnish the connection is reset. Requesting include.html directly is no problem. My default.vcl: backend dev { .host = "192.168.2.10"; .port = "80"; } sub vcl_recv { if (req.url ~ "\.(js|css|gif|jpg|png|ico|txt|swf|mp3)(\?.*)?$") { unset req.http.cookie; } if (req.http.Accept-Encoding) { if (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; } } if (req.url == "/index.html") { <------>esi; } } What happens: # varnishd -d -d -f /usr/local/etc/varnish/default.vcl -a 192.168.2.15:80 storage_file: filename: ./varnish.2adBfM (unlinked) size 1346836 MB. Using old SHMFILE Debugging mode, enter "start" to start child start child (57004) Started 200 0 Child (57004) said Closed fds: 4 8 9 11 12 Child (57004) said Child starts Child (57004) said managed to mmap 1412260429824 bytes of 1412260429824 Child (57004) said Ready Child (57004) died signal=6 Child (57004) Panic message: Assert error in VRT_ESI(), cache_vrt_esi.c line 658: Condition((sp->obj) != NULL) not true. thread = (cache-worker) sp = 0x806572008 { fd = 9, id = 9, xid = 678967366, client = 192.168.2.24:57004, step = STP_RECV, handling = error, restarts = 0, esis = 0 ws = 0x806572080 { id = "sess", {s,f,r,e} = {0x806572810,+523,0x0,+16384}, }, http[req] = { ws = 0x806572080[sess] "GET", "/index.html", "HTTP/1.1", "Host: dutchcowboys.bert-jan.bug", "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7", "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "Accept-Language: en-us,en;q=0.5", "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7", "Keep-Alive: 300", "Connection: keep-alive", "Cookie: __unam=c4094e2-124e7db5c01-3e94d73-153; PHPSESSID=36e043ec7c9710545523e4e04c538734", "Accept-Encoding: gzip", }, worker = 0x7ffffdff0a70 vcl = { srcname = { "input", "Default", }, }, }, Child cleanup complete child (57005) Started Child (57005) said Closed fds: 4 8 9 11 12 Child (57005) said Child starts Child (57005) said managed to mmap 1412260429824 bytes of 1412260429824 Child (57005) said Ready Any suggestions would be very welcome. Bert-Jan de Lange From me at mgoldman.com Thu Jan 28 12:09:08 2010 From: me at mgoldman.com (Martin Goldman) Date: Thu, 28 Jan 2010 07:09:08 -0500 Subject: Memory usage In-Reply-To: <24a219a51001280401i1467fb22qef3cbdb013c6b209@mail.gmail.com> References: <24a219a51001261919h452f0f0btf7b5d4e73b465826@mail.gmail.com> <24a219a51001261923n40146083yb221aac2cadbcff8@mail.gmail.com> <24a219a51001280401i1467fb22qef3cbdb013c6b209@mail.gmail.com> Message-ID: <24a219a51001280409l13f3dfb4n38382d3772b71db5@mail.gmail.com> My backing store is file-based. In any case, thanks to you both -- I have ordered some more RAM and will see what happens. Martin > > > On Wed, Jan 27, 2010 at 12:23 AM, Michael Fischer wrote: > >> On Tue, Jan 26, 2010 at 7:23 PM, Martin Goldman wrote: >> >> I'm running Varnish on a box with 4GB RAM. There are hundreds of thousands >>> of objects being served, and I'm certain that they don't all fit in that >>> relatively meager amount of RAM. I understand that Varnish's model dictates >>> that the kernel will be trusted to use virtual memory as necessary if the >>> cached objects don't fit in RAM. I have a few questions about this: >>> >>> 1. How can you tell whether your Varnish objects fit in RAM? >>> >> >> You can't guarantee that they will unless you set your cache size at or >> below the amount of RAM you have installed. >> >> >>> 2. If I have objects residing in virtual memory, to what extent will my >>> performance be adversely affected? If I want my site to be fast, do I >>> basically need to go out and buy as much RAM as it will take so that virtual >>> memory isn't needed? >>> >> >> Technically, it's "go out and buy as much RAM as it will take to avoid >> being swamped by paging". But yes. >> >> >>> 3. I noticed tonight that my machine was using a few hundred megs of >>> swap space, which I've never seen happen before. Varnish is the only >>> non-system service running on this box. My understanding was that Varnish >>> would get only as much RAM as was available and then send the overflow into >>> the file-backed virtual memory. If that's the case, though, then why is swap >>> space being used? Is this just a side effect of how the kernel allocates >>> memory, or is something else going on here? >>> >> >> Is your backing store file-based, or malloc-based? If the latter, that >> would explain the swap space being consumed. Or, as Darryl said, the >> housekeeping overhead of a VERY large file-backed cache could make the >> Varnish process very large. >> >> --Michael >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Jan 28 22:19:06 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 28 Jan 2010 22:19:06 +0000 Subject: Varnish Prefetch In-Reply-To: Your message of "Wed, 27 Jan 2010 13:55:39 +0530." <75cf5801001270025s722f114ax9335dba334a84007@mail.gmail.com> Message-ID: <4956.1264717146@critter.freebsd.dk> In message <75cf5801001270025s722f114ax9335dba334a84007 at mail.gmail.com>, Paras Fadte writes: >Thanks for the response . So with grace mode is it possible to fetch an >object from backend about "x" seconds before its "expires" time is reached ? No, sorry. -- 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 fulanpeng at gmail.com Thu Jan 28 22:46:54 2010 From: fulanpeng at gmail.com (fulan Peng) Date: Fri, 29 Jan 2010 06:46:54 +0800 Subject: Some web site make Varnish return a blank page In-Reply-To: <4B6149FD.20304@netclever.nl> References: <4B6149FD.20304@netclever.nl> Message-ID: Sorry I did not explain well. It is like this: Browser --> Varnish --> Site1 OK. Works. Default configure. Browser --> Varnish --> Site2 Blank pages wget --> Site2 OK. Works. index.html Browser --> Squid --> Site2 Works only with index.html. When I click a link, it goes to http://Site2, bypass Squid. I am trying to replace Squid with Varnish to fix this problem. Thanks a lot! Fulan Peng On Thu, Jan 28, 2010 at 4:25 PM, Martin Boer wrote: > I'm not a guru so I could really use more information to figure out exactly > what is happening. > > Are you implying that when you have varnish in front of your 2 websites it > is working correctly when accessing the sites through wget but not hen using > internet explorer and/or firefox ? > If so, could you paste some varnishlog of > > wget -> varnish -> site1 > -> site2 > > firefox -> varnish -> site1 > -> site2 > > explorer -> varnish -> site1 > -> site2 > > and describe for each if it is working or not. > > Martin > > > fulan Peng wrote: >> >> Hi Varnish gurus: >> >> I am new to varnish. I got Varnish working with default config with >> one web site. >> when I change to another web site, varnish response with a blank page. >> >> ?wget can normally fetch the index.html page. >> >> When I start varnishlog and cat varnish.log file, there are a lot of >> PING and PONG. No clue what is wrong. >> >> No other error message. >> >> Please help me out! Thank you! >> >> Fulan Peng >> _______________________________________________ >> varnish-misc mailing list >> varnish-misc at projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc >> >> >> > > From plfgoa at gmail.com Fri Jan 29 04:37:17 2010 From: plfgoa at gmail.com (Paras Fadte) Date: Fri, 29 Jan 2010 10:07:17 +0530 Subject: Varnish Prefetch In-Reply-To: <4956.1264717146@critter.freebsd.dk> References: <75cf5801001270025s722f114ax9335dba334a84007@mail.gmail.com> <4956.1264717146@critter.freebsd.dk> Message-ID: <75cf5801001282037j49becab4qabc8cf3ab3cdcdaf@mail.gmail.com> Thanks for the response Poul. On Fri, Jan 29, 2010 at 3:49 AM, Poul-Henning Kamp wrote: > In message <75cf5801001270025s722f114ax9335dba334a84007 at mail.gmail.com>, > Paras > Fadte writes: > > >Thanks for the response . So with grace mode is it possible to fetch an > >object from backend about "x" seconds before its "expires" time is reached > ? > > > No, sorry. > > -- > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From torrance123 at gmail.com Fri Jan 29 06:11:12 2010 From: torrance123 at gmail.com (Torrance) Date: Fri, 29 Jan 2010 19:11:12 +1300 Subject: 503 Errors on POST Message-ID: <4B627C00.2040001@gmail.com> Hi all, (I realise this has been a topic brought up before, but the previous posts haven't seemed to help my problem.) I am running a drupal site behind Varnish and when posts or comments are submitted there's about a 50/50 chance the user will get one of Varnish's 503 error pages. These errors aren't after waiting a little while or even a few seconds - they are returned with no delay whatsoever. I can only presume that this is somehow linked to the fact that these are POST requests, as the errors do not come up at any other time. I have tried the usual suspects by increasing timeout settings. My default backend settings are: backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 8s; .first_byte_timeout = 60s; .between_bytes_timeout = 60s; } I'm using Varnish 2.0.4.5~bp from debian backports on an otherwise Lenny system. The backend is apache-mpm-prefork 2.2.9-10 and the client is drupal 6.14 running on mysql (though I don't expect this matters). Is there some little trick I'm missing? Cheers, Torrance -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: OpenPGP digital signature URL: From tfheen at redpill-linpro.com Fri Jan 29 10:16:02 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Fri, 29 Jan 2010 11:16:02 +0100 Subject: Varnish graphs In-Reply-To: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> (pablort's message of "Wed, 27 Jan 2010 20:37:47 -0200") References: <7ae911871001271437k73cf69d4q3c143b8146da7052@mail.gmail.com> Message-ID: <87ockd43od.fsf@qurzaw.linpro.no> ]] pablort | The numbers do reflect the TxStatus'es that I see in interactive varnishtop, | but when I try to run it with -1, it doesn't show which entry corresponds to | which status. LOL. You're running an old version, this was fixed in 2.0.5 so upgrading should fix that. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Fri Jan 29 10:21:11 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Fri, 29 Jan 2010 11:21:11 +0100 Subject: Not Able to Purge in Varnish In-Reply-To: <25daf17a1001280109r582200d7s5a498749b18f4969@mail.gmail.com> (Abhishek Singh's message of "Thu, 28 Jan 2010 14:39:28 +0530") References: <25daf17a1001280109r582200d7s5a498749b18f4969@mail.gmail.com> Message-ID: <87k4v143fs.fsf@qurzaw.linpro.no> ]] Abhishek Singh | I am using varnish for static files caching and multiple domains are getting | served from varnish cluster and i want to purge static files for specific | domain so how can i do that. | | I tired following but it is not working. | | 1) | purge req.http.host ~ xyz.com | 101 44 | Unknown request. | Type 'help' for more info Which version are you using? I suspect you're using an old version. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From w at 1wt.eu Thu Jan 28 13:37:57 2010 From: w at 1wt.eu (Willy Tarreau) Date: Thu, 28 Jan 2010 14:37:57 +0100 Subject: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure? Message-ID: <20100128133757.GA11121@1wt.eu> Poul-Henning Kamp wrote : > >Let's get back to consistent hashing and it's use... > > > >Correct me if I am wrong, but doesn't this mean that adding a new > >varnish instance implies a full rehash ? > > Yes, that is pretty much guaranteed to be the cost with any > stateless hashing. No, not with the consistent hashing algorithm. This is a very interesting technique. The hash is not as well distributed as common hash algorithms, but each new server only takes one small part of other server's job. If a server goes down, its job is redistributed on other ones without the other ones' jobs being redistributed. Please read here for more info : http://www.spiteful.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/ This has been implemented in haproxy precisely for caches. You can enable it in any backend by simply specifying "hash-type consistent". Moreover, you get the benefit of the slowstart feature, which means that a server may be progressively reintroduced into the farm during a warm up period instead of taking a big hit at once when it's seen up. Someone asked about the advantages of hashing URLs for caches. It's simple, it's just to optimise requests placement : send a request to the cache that is the most likely to already have fetched the same object and have it in cache. Do that while monitoring your network bandwidth. I think you'll observe a reduction when switching from anything to url_hash. Hoping this helps, Willy From tfheen at redpill-linpro.com Fri Jan 29 10:26:37 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Fri, 29 Jan 2010 11:26:37 +0100 Subject: 503 Errors on POST In-Reply-To: <4B627C00.2040001@gmail.com> (Torrance's message of "Fri, 29 Jan 2010 19:11:12 +1300") References: <4B627C00.2040001@gmail.com> Message-ID: <87fx5p436q.fsf@qurzaw.linpro.no> ]] Torrance | I am running a drupal site behind Varnish and when posts or comments are | submitted there's about a 50/50 chance the user will get one of | Varnish's 503 error pages. These errors aren't after waiting a little | while or even a few seconds - they are returned with no delay | whatsoever. I can only presume that this is somehow linked to the fact | that these are POST requests, as the errors do not come up at any other | time. If you can capture a varnishlog from a good and a failing request, that might shed some light on what's going on. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From tfheen at redpill-linpro.com Fri Jan 29 11:54:47 2010 From: tfheen at redpill-linpro.com (Tollef Fog Heen) Date: Fri, 29 Jan 2010 12:54:47 +0100 Subject: Release schedule for saint mode. In-Reply-To: (Ken Brownfield's message of "Wed, 27 Jan 2010 12:08:06 -0800") References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> <87aavznbkb.fsf@qurzaw.linpro.no> Message-ID: <87636l3z3s.fsf@qurzaw.linpro.no> ]] Ken Brownfield | Right, -spersistent. Child restarts are persistent, parent process stop/start isn't. It should be. You'll lose the last storage silo (since that's not closed yet), but older objects should be available. Can you see if you can reproduce and post a varnishlog -1 when the child has restarted as well as after having restarted the parent? | Maybe there's a graceful, undocumented method of stopping the parent that I'm not aware of? Shouldn't matter. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 From per.buer at redpill-linpro.com Fri Jan 29 14:48:27 2010 From: per.buer at redpill-linpro.com (Per Andreas Buer) Date: Fri, 29 Jan 2010 15:48:27 +0100 (CET) Subject: Survey; how do you use Varnish? In-Reply-To: <1972754207.83637.1264776184796.JavaMail.root@claudius.linpro.no> Message-ID: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no> Hi list. I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks. 1) How many servers do you have running Varnish? 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics. 3) What sort of site is it? *) Online media *) Cooperate website (ibm.com or similar) *) Retail *) Educational *) Social website 4) Do you use ESI? 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. -- Per Andreas Buer Redpill Linpro Group - Changing the Game Mobile +47 958 39 117 / Phone: +47 21 54 41 21 From bedis9 at gmail.com Fri Jan 29 16:14:12 2010 From: bedis9 at gmail.com (Bedis 9) Date: Fri, 29 Jan 2010 17:14:12 +0100 Subject: Survey; how do you use Varnish? In-Reply-To: <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no> References: <1972754207.83637.1264776184796.JavaMail.root@claudius.linpro.no> <630234885.83667.1264776507774.JavaMail.root@claudius.linpro.no> Message-ID: <30b80c9f1001290814x6353b58erf3b90b0191f161cd@mail.gmail.com> Hi, I precise: I don't work for Linpro. ;) For some big project, I'm planing to deploy Varnish. So I would be interested if you could precise the Operating system you're using to run Varnish and the hardware type (CPU, memory, HD, NICs). Does some of you run it in a virtualized environment? (Xen, kvm, vmware). thanks a lot On Fri, Jan 29, 2010 at 3:48 PM, Per Andreas Buer wrote: > Hi list. > > I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks. > > 1) How many servers do you have running Varnish? > > 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics. > > 3) What sort of site is it? > ?*) Online media > ?*) Cooperate website (ibm.com or similar) > ?*) Retail > ?*) Educational > ?*) Social website > > 4) Do you use ESI? > > 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. > > > > -- > Per Andreas Buer > Redpill Linpro Group - Changing the Game > > Mobile +47 958 39 117 / Phone: +47 21 54 41 21 > _______________________________________________ > varnish-misc mailing list > varnish-misc at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > From henry at funix.nl Fri Jan 29 18:38:30 2010 From: henry at funix.nl (Henry Paulissen) Date: Fri, 29 Jan 2010 19:38:30 +0100 Subject: Survey; how do you use Varnish? Message-ID: <001901caa112$419138c0$c4b3aa40$@nl> 1) 8 (All servers are serving from mem, big machines. 6 as frontend in cluster and load balanced, 1 as between frontend varnish and backend application server and 1 as backup) 2) ~250MB/s (through varnish). 2.5m visitors a day, 27m pageviews a day (for the whole website, some content doesn't go through varnish). 3) Online Adult Entertainment (<-- porn). 4) nope 5.1) WCCP support!!!! 5.2) My feature request: http://projects.linpro.no/pipermail/varnish-misc/2010-January/003636.html 5.3) Gzip support 5.4) VCL cookie handing 5.5) Synthetic content (I use error now, it doesn't bother me). Henry -----Original Message----- From: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] On Behalf Of Per Andreas Buer Sent: vrijdag 29 januari 2010 15:48 To: varnish-misc at projects.linpro.no Subject: Survey; how do you use Varnish? Hi list. I'm working for Redpill Linpro, you might have heard of us - we're the main sponsor of Varnish development. We're a bit curious about how Varnish is used, what features are used and what is missing. What does a typical installation look like? The information you would choose to reveal to me would be aggregated and deleted and I promise you I won't use it for any sales activities or harass you in any way. We will pubish the result on this list if the feedback is significant. If you have the time and would like to help us please take some time and answer the questions in a direct mail to me. Thanks. 1) How many servers do you have running Varnish? 2) What sort of total load are you having? Mbit/s or hits per second are preferred metrics. 3) What sort of site is it? *) Online media *) Cooperate website (ibm.com or similar) *) Retail *) Educational *) Social website 4) Do you use ESI? 5) What features are you missing from Varnish. Max three features, prioritized. Please refer to http://varnish-cache.org/wiki/PostTwoShoppingList for features. -- Per Andreas Buer Redpill Linpro Group - Changing the Game Mobile +47 958 39 117 / Phone: +47 21 54 41 21 _______________________________________________ varnish-misc mailing list varnish-misc at projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc From kb+varnish at slide.com Fri Jan 29 19:16:04 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Fri, 29 Jan 2010 11:16:04 -0800 Subject: Release schedule for saint mode. In-Reply-To: <87636l3z3s.fsf@qurzaw.linpro.no> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> <87aavznbkb.fsf@qurzaw.linpro.no> <87636l3z3s.fsf@qurzaw.linpro.no> Message-ID: <00A0CB58-CB18-4EE9-BBDB-022448D07F52@slide.com> On Jan 29, 2010, at 3:54 AM, Tollef Fog Heen wrote: > It should be. You'll lose the last storage silo (since that's not > closed yet), but older objects should be available. This might be the source of the confusion. How often are silos closed? My testing was simply "hit the cache for a single object a few times to increase obj.hits, bounce varnish, next request was a miss". If I can get a handle on how often silos are closed, I can more accurately check the behavior under production load. > Can you see if you can reproduce and post a varnishlog -1 when the child > has restarted as well as after having restarted the parent? Will do, thanks. -- Ken > | Maybe there's a graceful, undocumented method of stopping the parent that I'm not aware of? > > Shouldn't matter. > > -- > Tollef Fog Heen > Redpill Linpro -- Changing the game! > t: +47 21 54 41 73 From torrance123 at gmail.com Fri Jan 29 23:32:33 2010 From: torrance123 at gmail.com (Torrance) Date: Sat, 30 Jan 2010 12:32:33 +1300 Subject: 503 Errors on POST In-Reply-To: <87fx5p436q.fsf@qurzaw.linpro.no> References: <4B627C00.2040001@gmail.com> <87fx5p436q.fsf@qurzaw.linpro.no> Message-ID: <4B637011.3010008@gmail.com> Hi Tollef, I've pasted the logs of two failed requests below. As you can see, they're both in response to POST requests, though I was overstating the frequency at which these errors are occurring: they're occurring about 10% of the time. To be honest, I don't entirely understand the logs or their format, but I hope I've captured the important details. (Session IDs have been deleted, btw). Many thanks, Torrance 15 ReqStart c 125.236.128.219 51361 561006524 15 RxRequest c POST 15 RxURL c /node/78063/edit 15 RxProtocol c HTTP/1.1 15 RxHeader c Host: indymedia.org.nz 15 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 15 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 15 RxHeader c Accept-Language: en-gb,en;q=0.5 15 RxHeader c Accept-Encoding: gzip,deflate 15 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 15 RxHeader c Keep-Alive: 115 15 RxHeader c Connection: keep-alive 15 RxHeader c Referer: http://indymedia.org.nz/node/78063/edit 15 RxHeader c Cookie: comment_info_name=Tester; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1 15 RxHeader c Content-Type: multipart/form-data; boundary=---------------------------1850078892860212931738819713 15 RxHeader c Content-Length: 16978 15 VCL_call c recv 15 VCL_return c pass 15 VCL_call c pass 15 VCL_return c pass 15 Backend c 10 default default 10 TxRequest b POST 10 TxURL b /node/78063/edit 10 TxProtocol b HTTP/1.1 10 TxHeader b Host: indymedia.org.nz 10 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 10 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 10 TxHeader b Accept-Language: en-gb,en;q=0.5 10 TxHeader b Accept-Encoding: gzip,deflate 10 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 10 TxHeader b Referer: http://indymedia.org.nz/node/78063/edit 10 TxHeader b Cookie: comment_info_name=Tester; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1 10 TxHeader b Content-Type: multipart/form-data; boundary=---------------------------1850078892860212931738819713 10 TxHeader b Content-Length: 16978 10 TxHeader b X-Forwarded-For: 125.236.128.219 10 TxHeader b X-Varnish: 561006524 10 TxHeader b X-Forwarded-For: 125.236.128.219 10 BackendClose b default 15 VCL_call c error 15 VCL_return c deliver 15 Length c 465 15 VCL_call c deliver 15 VCL_return c deliver 15 TxProtocol c HTTP/1.1 15 TxStatus c 503 15 TxResponse c Service Unavailable 15 TxHeader c Server: Varnish 15 TxHeader c Retry-After: 0 15 TxHeader c Content-Type: text/html; charset=utf-8 15 TxHeader c Content-Length: 465 15 TxHeader c Date: Fri, 29 Jan 2010 23:00:42 GMT 15 TxHeader c X-Varnish: 561006524 15 TxHeader c Age: 1 15 TxHeader c Via: 1.1 varnish 15 TxHeader c Connection: close 15 ReqEnd c 561006524 1264806040.957435846 1264806042.241542339 4.125935793 1.284075260 0.000031233 15 SessionClose c error 15 StatSess c 125.236.128.219 51361 14 1 3 0 3 2 1410 49426 0 StatAddr - 125.236.128.219 0 1102 34 74 0 32 42 38287 1054700 21 ReqStart c 125.236.128.219 53669 561007510 21 RxRequest c POST 21 RxURL c /node/78063/edit 21 RxProtocol c HTTP/1.1 21 RxHeader c Host: indymedia.org.nz 21 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 21 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 21 RxHeader c Accept-Language: en-gb,en;q=0.5 21 RxHeader c Accept-Encoding: gzip,deflate 21 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 21 RxHeader c Keep-Alive: 115 21 RxHeader c Connection: keep-alive 21 RxHeader c Referer: http://indymedia.org.nz/node/78063/edit 21 RxHeader c Cookie: comment_info_name=Tester; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1 21 RxHeader c Content-Type: multipart/form-data; boundary=---------------------------84863282515329900481602423677 21 RxHeader c Content-Length: 17019 21 VCL_call c recv 21 VCL_return c pass 21 VCL_call c pass 21 VCL_return c pass 21 Backend c 15 default default 15 TxRequest b POST 15 TxURL b /node/78063/edit 15 TxProtocol b HTTP/1.1 15 TxHeader b Host: indymedia.org.nz 15 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 15 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 15 TxHeader b Accept-Language: en-gb,en;q=0.5 15 TxHeader b Accept-Encoding: gzip,deflate 15 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 15 TxHeader b Referer: http://indymedia.org.nz/node/78063/edit 15 TxHeader b Cookie: comment_info_name=Tester; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; SESSxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx; has_js=1 15 TxHeader b Content-Type: multipart/form-data; boundary=---------------------------84863282515329900481602423677 15 TxHeader b Content-Length: 17019 15 TxHeader b X-Forwarded-For: 125.236.128.219 15 TxHeader b X-Varnish: 561007510 15 TxHeader b X-Forwarded-For: 125.236.128.219 15 BackendClose b default 21 VCL_call c error 21 VCL_return c deliver 21 Length c 465 21 VCL_call c deliver 21 VCL_return c deliver 21 TxProtocol c HTTP/1.1 21 TxStatus c 503 21 TxResponse c Service Unavailable 21 TxHeader c Server: Varnish 21 TxHeader c Retry-After: 0 21 TxHeader c Content-Type: text/html; charset=utf-8 21 TxHeader c Content-Length: 465 21 TxHeader c Date: Fri, 29 Jan 2010 23:22:15 GMT 21 TxHeader c X-Varnish: 561007510 21 TxHeader c Age: 2 21 TxHeader c Via: 1.1 varnish 21 TxHeader c Connection: close 21 ReqEnd c 561007510 1264807333.799563885 1264807335.335580826 3.151196718 1.535988092 0.000028849 21 SessionClose c error 21 StatSess c 125.236.128.219 53669 35 1 9 0 5 4 4595 137808 0 StatAddr - 125.236.128.219 0 2395 45 114 0 53 61 58675 1768498 On 29/01/10 11:26 PM, Tollef Fog Heen wrote: > ]] Torrance > > | I am running a drupal site behind Varnish and when posts or comments are > | submitted there's about a 50/50 chance the user will get one of > | Varnish's 503 error pages. These errors aren't after waiting a little > | while or even a few seconds - they are returned with no delay > | whatsoever. I can only presume that this is somehow linked to the fact > | that these are POST requests, as the errors do not come up at any other > | time. > > If you can capture a varnishlog from a good and a failing request, that > might shed some light on what's going on. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnish.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: OpenPGP digital signature URL: From kb+varnish at slide.com Sat Jan 30 21:22:32 2010 From: kb+varnish at slide.com (Ken Brownfield) Date: Sat, 30 Jan 2010 13:22:32 -0800 Subject: Release schedule for saint mode. In-Reply-To: <00A0CB58-CB18-4EE9-BBDB-022448D07F52@slide.com> References: <7ae911871001181247l6626f29dl1c32d4509d5d3b50@mail.gmail.com> <878wbtqipn.fsf@qurzaw.linpro.no> <7ae911871001211057u56e71dbye60ede47c5beb0c1@mail.gmail.com> <87wrz6v8lh.fsf@qurzaw.linpro.no> <877C0798-DB47-4D8B-9E2F-76BF2F14E69E@slide.com> <87aavznbkb.fsf@qurzaw.linpro.no> <87636l3z3s.fsf@qurzaw.linpro.no> <00A0CB58-CB18-4EE9-BBDB-022448D07F52@slide.com> Message-ID: <97662438-084A-4DF3-948B-3D3FD8F31076@slide.com> I started a test yesterday with trunk at 4478, and after running for about 12 hours under pretty good load, the machine started swapping heavily and we had to restart Varnish. After coming back up, it didn't have the 2.8M objects it did when it was shut down: uptime 464 . Child uptime client_conn 1951 4.20 Client connections accepted client_drop 0 0.00 Connection dropped, no sess client_req 79366 171.05 Client requests received cache_hit 19669 42.39 Cache hits cache_hitpass 0 0.00 Cache hits for pass cache_miss 59265 127.73 Cache misses backend_conn 288 0.62 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 0 0.00 Backend conn. too many backend_fail 0 0.00 Backend conn. failures backend_reuse 59118 127.41 Backend conn. reuses backend_toolate 0 0.00 Backend conn. was closed backend_recycle 59128 127.43 Backend conn. recycles backend_unused 76 0.16 Backend conn. unused fetch_head 0 0.00 Fetch head fetch_length 59076 127.32 Fetch with Length fetch_chunked 0 0.00 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 0 0.00 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 0 0.00 Fetch failed n_sess_mem 249 . N struct sess_mem n_sess 186 . N struct sess n_object 58989 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 59018 . N struct objectcore n_objecthead 59018 . N struct objecthead n_smf 0 . N struct smf n_smf_frag 0 . N small free smf n_smf_large 0 . N large free smf n_vbe_conn 119 . N struct vbe_conn n_wrk 256 . N worker threads n_wrk_create 256 0.55 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_queue 0 0.00 N queued work requests n_wrk_overflow 0 0.00 N overflowed work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 1 . N backends n_expired 0 . N expired objects n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 0 . N LRU moved objects n_deathrow 0 . N objects on deathrow losthdr 0 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 78656 169.52 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 1945 4.19 Total Sessions s_req 79366 171.05 Total Requests s_pipe 0 0.00 Total pipe s_pass 56 0.12 Total pass s_fetch 59074 127.31 Total fetch s_hdrbytes 31974718 68911.03 Total header bytes s_bodybytes 2381590875 5132738.95 Total body bytes sess_closed 965 2.08 Session Closed sess_pipeline 0 0.00 Session Pipeline sess_readahead 0 0.00 Session Read Ahead sess_linger 78420 169.01 Session Linger sess_herd 55547 119.71 Session herd shm_records 5479085 11808.37 SHM records shm_writes 201347 433.94 SHM writes shm_flushes 0 0.00 SHM flushes due to overflow shm_cont 453 0.98 SHM MTX contention shm_cycles 2 0.00 SHM cycles through buffer sm_nreq 0 0.00 allocator requests sm_nobj 0 . outstanding allocations sm_balloc 0 . bytes allocated sm_bfree 0 . bytes free sma_nreq 0 0.00 SMA allocator requests sma_nobj 0 . SMA outstanding allocations sma_nbytes 0 . SMA outstanding bytes sma_balloc 0 . SMA bytes allocated sma_bfree 0 . SMA bytes free sms_nreq 622 1.34 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 327230 . SMS bytes allocated sms_bfree 327230 . SMS bytes freed backend_req 59406 128.03 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_purge 1 . N total active purges n_purge_add 1 0.00 N new purges added n_purge_retire 0 0.00 N old purges deleted n_purge_obj_test 0 0.00 N objects tested n_purge_re_test 0 0.00 N regexps tested against n_purge_dups 0 0.00 N duplicate purges removed hcb_nolock 0 0.00 HCB Lookups without lock hcb_lock 0 0.00 HCB Lookups with lock hcb_insert 0 0.00 HCB Inserts esi_parse 0 0.00 Objects ESI parsed (unlock) esi_errors 0 0.00 ESI parse errors (unlock) Nothing abnormal in the logs, just normal stopping/starting messages. Jan 30 05:30:48 v0 varnishd[16001]: Manager got SIGINT Jan 30 05:30:48 v0 varnishd[16001]: Stopping Child Jan 30 12:52:28 v0 varnishd[27107]: child (27108) Started Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Closed fds: 15 16 17 20 21 23 24 Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Child starts Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Silo completely loaded Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Probe("GET /r/1/0/dl/gAO0cAU8rz-UR3ZNecmCwC1R0_hIR_QR HTTP/1.1 Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Host: deco.slide.com Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Connection: close Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said Jan 30 12:52:30 v0 varnishd[27107]: Child (27108) said ", 0.8, 3) Cmdline: varnishd \ -a 0.0.0.0:3228 \ -f config.vcl \ -g nogroup \ -h classic,524287 \ -P varnish.pid \ -p ban_lurker_sleep=60s \ -p between_bytes_timeout=15s \ -p cache_vbe_conns=on \ -p cli_buffer=32768 \ -p client_http11=on \ -p default_grace=0s \ -p default_ttl=0s \ -p err_ttl=0s \ -p first_byte_timeout=15s \ -p listen_depth=8192 \ -p lru_interval=3600 \ -p max_restarts=2 \ -p obj_workspace=2048 \ -p pipe_timeout=15s \ -p purge_dups=on \ -p rush_exponent=32 \ -p sess_timeout=15s \ -p thread_pools=8 \ -p thread_pool_min=32 \ -p thread_pool_max=8192 \ -p thread_pool_stack=262144 \ -s persistent,/cache/sdm/varnish,120G \ -s persistent,/cache/sdn/varnish,120G \ -s persistent,/cache/sdo/varnish,120G \ -s persistent,/cache/sdp/varnish,120G \ -s persistent,/cache/sdq/varnish,120G \ -s persistent,/cache/sdr/varnish,120G \ -s persistent,/cache/sds/varnish,120G \ -s persistent,/cache/sdt/varnish,120G \ -s persistent,/cache/sdu/varnish,120G \ -s persistent,/cache/sdv/varnish,120G \ -s persistent,/cache/sdw/varnish,120G \ -s persistent,/cache/sdx/varnish,120G \ -T 0.0.0.0:6666 \ -u nobody OT: why does Varnish swap when the working set no longer fits in RAM -- and when dirty pages are in the 10-100MB range (64GB box). I have a feeling that turning off swap would cause the kernel to eventually lock up, so I'll have to see if there's a way to tune this (swappiness already at 1). Thanks, -- Ken On Jan 29, 2010, at 11:16 AM, Ken Brownfield wrote: > On Jan 29, 2010, at 3:54 AM, Tollef Fog Heen wrote: >> It should be. You'll lose the last storage silo (since that's not >> closed yet), but older objects should be available. > > This might be the source of the confusion. How often are silos closed? My testing was simply "hit the cache for a single object a few times to increase obj.hits, bounce varnish, next request was a miss". If I can get a handle on how often silos are closed, I can more accurately check the behavior under production load. > >> Can you see if you can reproduce and post a varnishlog -1 when the child >> has restarted as well as after having restarted the parent? > > Will do, thanks. > -- > Ken > > >> | Maybe there's a graceful, undocumented method of stopping the parent that I'm not aware of? >> >> Shouldn't matter. >> >> -- >> Tollef Fog Heen >> Redpill Linpro -- Changing the game! >> t: +47 21 54 41 73 >