From andersb at vgnett.no Tue Aug 1 11:12:49 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 1 Aug 2006 13:12:49 +0200 (CEST) Subject: Quick run Message-ID: <1349.193.213.34.102.1154430769.squirrel@denise.vg.no> Hi, Poul-Henning, at leasure could you run varnish for an hour or two? That is after you have done the changes you have planned in the SHMLOG. I would need the new logformat to toy with. The loadbalancer is still weight 1. Also, a quick question of the changes you have done: (int)obj->entered you have added in the TTL logheader would be the right place to get the utime for the request? Anders Berg From phk at phk.freebsd.dk Tue Aug 1 11:15:55 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 01 Aug 2006 11:15:55 +0000 Subject: Quick run In-Reply-To: Your message of "Tue, 01 Aug 2006 13:12:49 +0200." <1349.193.213.34.102.1154430769.squirrel@denise.vg.no> Message-ID: <5000.1154430955@critter.freebsd.dk> In message <1349.193.213.34.102.1154430769.squirrel at denise.vg.no>, "Anders Berg " writes: >Hi, > >Poul-Henning, at leasure could you run varnish for an hour or two? >That is after you have done the changes you have planned in the SHMLOG. >I would need the new logformat to toy with. > >The loadbalancer is still weight 1. I just did. try the _vlog60 and _vlog61 logfiles. >Also, a quick question of the changes you have done: > >(int)obj->entered you have added in the TTL logheader would be the right >place to get the utime for the request? No, you should take the first part of the ReqServTime message. -- 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 andersb at vgnett.no Tue Aug 1 17:11:06 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 1 Aug 2006 19:11:06 +0200 (CEST) Subject: Prefetching Message-ID: <3033.193.69.165.4.1154452266.squirrel@denise.vg.no> Hi, since I am still at home with a bad back (I can only sit for small amounts of time in a chair), I have been reading some papers on prefetching and cache algorithm's. I have concluded this: 1. Prefetching is only needed if one wants to minimalize latency for doc's, or to prime a cache. Obvious maybe, but I can't think of any other use. Bandwith is hardly a problem to backend, and size is not to big a deal for most cases. 2. If we wanna use a algorithm, we would use a old one. Reason is that the "new" ones are so clientside-cache oriented that to perform better than the old'ies they become so specific whith regards to different paramaters for optimalization, that they don't fit good for serverside-caching (They take into account bandwith, size etc...). I have not read at all about the newest ones, but it is clear already in year 2000 that they fit clientside better than serverside. And since we would possibly use prefetching for latency I would opt for one called Hybrid, http://dret.net/biblio/reference/woo97 (I can't seem to find it online, but it is explained in: http://www.usenix.org/publications/library/proceedings/usits97/full_papers/cao/cao.pdf). Hybrid takes into account alot of parameters but primary focus is latency. It does not require extra HTTP headers, and is pretty simple. The only drawback is scaleability, O(log k) where k is number of docs. LRU is O(1), but LRU is basically useless, since it won't help latency and prefetching much. I can't remember where we are with regards to prefetch, but I thought I might wanna write this down anyway. Anders Berg From phk at phk.freebsd.dk Tue Aug 1 17:49:28 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 01 Aug 2006 17:49:28 +0000 Subject: Prefetching In-Reply-To: Your message of "Tue, 01 Aug 2006 19:11:06 +0200." <3033.193.69.165.4.1154452266.squirrel@denise.vg.no> Message-ID: <19442.1154454568@critter.freebsd.dk> In message <3033.193.69.165.4.1154452266.squirrel at denise.vg.no>, "Anders Berg" writes: >Hi, > >since I am still at home with a bad back (I can only sit for small amounts >of time in a chair), I have been reading some papers on prefetching and >cache algorithm's. I have concluded this: > >1. Prefetching is only needed if one wants to minimalize latency for >doc's, or to prime a cache. Obvious maybe, but I can't think of any other >use. Bandwith is hardly a problem to backend, and size is not to big a >deal for most cases. With the architecture I/we have chosen, prefetching will help us avoid the momentary pile-up that would happen when a much used document expires. As far as I can tell, this is not very important to VG, but doing proper prefetching will improve responsetime a bit when those events happen. >2. If we wanna use a algorithm, we would use a old one. I fully agree. My plan was to use one that said "if the document has been used more than 2 times in the previous incarnation, then prefetch, otherwise discard." for some suitable value of 2. Maybe a frequency is better: If document has been used more than once per minute in previous incarnation, then prefetch, otherwise discard". Either way, the policy will be in VCL... Anyway, for now prefetching is not on the list of 1.0 things so it's not very important. -- 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 andersb at vgnett.no Tue Aug 1 18:47:08 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 1 Aug 2006 20:47:08 +0200 Subject: Prefetching In-Reply-To: <19442.1154454568@critter.freebsd.dk> References: <19442.1154454568@critter.freebsd.dk> Message-ID: <173641DC-A96D-48D2-B100-254EE901058C@vgnett.no> On Aug 1, 2006, at 19:49, Poul-Henning Kamp wrote: > In message <3033.193.69.165.4.1154452266.squirrel at denise.vg.no>, > "Anders Berg" > writes: >> Hi, > > With the architecture I/we have chosen, prefetching will help us avoid > the momentary pile-up that would happen when a much used document > expires. > As far as I can tell, this is not very important to VG, but doing > proper prefetching will improve responsetime a bit when those > events happen. Yes, it is not really that important for VG per se., since we can live without it today. We would turn it on if it was available though :) >> 2. If we wanna use a algorithm, we would use a old one. > > I fully agree. > > My plan was to use one that said "if the document has been used > more than 2 times in the previous incarnation, then prefetch, > otherwise discard." for some suitable value of 2. > > Maybe a frequency is better: If document has been used more > than once per minute in previous incarnation, then prefetch, > otherwise discard". Documents that take long to "make" would benefit from having the time it takes to make it in the algorithm. A static doc like jpeg's, costs so little deliver that the pile-up would hardly be noticed, but you know that. Hybrid take's that into account, but has the horrible O(log(k))... But as you mention underneath, it's configurable :) > Either way, the policy will be in VCL... Ahh, that's right. > Anyway, for now prefetching is not on the list of 1.0 things > so it's not very important. Okay, was unsure where we placed prefetch. Anders Berg > -- > 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 Wed Aug 2 09:50:17 2006 From: anders at fupp.net (Anders Nordby) Date: Wed, 2 Aug 2006 11:50:17 +0200 Subject: NUUG meeting In-Reply-To: <17266.1152618074@critter.freebsd.dk> References: <1835.193.213.34.102.1152617867.squirrel@denise.vg.no> <17266.1152618074@critter.freebsd.dk> Message-ID: <20060802095017.GA75053@totem.fix.no> Hi, On Tue, Jul 11, 2006 at 11:41:14AM +0000, Poul-Henning Kamp wrote: >>> I suggest we nail down the dates for the live test 2 (and NUUG talk) >>> and set the delivery/goal when we have more firm estimates. > So is August 7-11 firm for the live-test 2 ? > > Do we need a full week ? > > I guess if we get too much time, DES and I can work on docs etc. NUUG wants to set up their august meeting now, and are thinking about setting up a different meeting if we can not decide. Is it still too early to plan a NUUG meeting about Varnish in august? Is september more realistic? Bye, -- Anders. From phk at phk.freebsd.dk Wed Aug 2 09:50:19 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 02 Aug 2006 09:50:19 +0000 Subject: libevent... Message-ID: <45188.1154512219@critter.freebsd.dk> I'm pretty tired of libevent right now, and I may opt for simply ripping it out entirely to end the debugging pain. I keep seeing stack corruption when I run live on c21 and I keep seeing libevent implicated in it. No I have taken libevent out everywhere but the CLI handling, and we'll see if I can find the bug. Killing libevent in varnish is now a matter of writing an acceptor that uses poll(2) (for linux etc) and picking it out of the CLI handling (where it's API is particularly bad to begin with). -- 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 Wed Aug 2 09:51:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 02 Aug 2006 09:51:52 +0000 Subject: NUUG meeting In-Reply-To: Your message of "Wed, 02 Aug 2006 11:50:17 +0200." <20060802095017.GA75053@totem.fix.no> Message-ID: <45207.1154512312@critter.freebsd.dk> In message <20060802095017.GA75053 at totem.fix.no>, Anders Nordby writes: >Hi, > >On Tue, Jul 11, 2006 at 11:41:14AM +0000, Poul-Henning Kamp wrote: >>>> I suggest we nail down the dates for the live test 2 (and NUUG talk) >>>> and set the delivery/goal when we have more firm estimates. >> So is August 7-11 firm for the live-test 2 ? >> >> Do we need a full week ? >> >> I guess if we get too much time, DES and I can work on docs etc. > >NUUG wants to set up their august meeting now, and are thinking about >setting up a different meeting if we can not decide. > >Is it still too early to plan a NUUG meeting about Varnish in august? Is >september more realistic? Not that I don't like Oslo or anything, but I don't see much reason for me to fly up there until the release-party, so I think we should aim for me speaking at NUUG at that 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 anders at fupp.net Wed Aug 2 11:01:39 2006 From: anders at fupp.net (Anders Nordby) Date: Wed, 2 Aug 2006 13:01:39 +0200 Subject: NUUG meeting In-Reply-To: <45207.1154512312@critter.freebsd.dk> References: <20060802095017.GA75053@totem.fix.no> <45207.1154512312@critter.freebsd.dk> Message-ID: <20060802110139.GA75431@totem.fix.no> Hi, On Wed, Aug 02, 2006 at 09:51:52AM +0000, Poul-Henning Kamp wrote: > >>>> I suggest we nail down the dates for the live test 2 (and NUUG talk) > >>>> and set the delivery/goal when we have more firm estimates. > >> So is August 7-11 firm for the live-test 2 ? > >> > >> Do we need a full week ? > >> > >> I guess if we get too much time, DES and I can work on docs etc. > > > >NUUG wants to set up their august meeting now, and are thinking about > >setting up a different meeting if we can not decide. > > > >Is it still too early to plan a NUUG meeting about Varnish in august? Is > >september more realistic? > Not that I don't like Oslo or anything, but I don't see much reason > for me to fly up there until the release-party, so I think > we should aim for me speaking at NUUG at that time. At that time, which is what time? August or september? Just trying to find a date we could agree with them on, so that they can book a room and announce the meeting in time. If it's still to early to set a date, I can report that. But that might mean something else will be on the agenda. Cheers, -- Anders. From andersb at vgnett.no Wed Aug 2 11:02:47 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 2 Aug 2006 13:02:47 +0200 (CEST) Subject: libevent... In-Reply-To: <45188.1154512219@critter.freebsd.dk> References: <45188.1154512219@critter.freebsd.dk> Message-ID: <1221.193.213.34.102.1154516567.squirrel@denise.vg.no> > > I'm pretty tired of libevent right now, and I may opt for simply > ripping it out entirely to end the debugging pain. > > I keep seeing stack corruption when I run live on c21 and I keep > seeing libevent implicated in it. Okay. > Killing libevent in varnish is now a matter of writing an acceptor > that uses poll(2) (for linux etc) and picking it out of the CLI > handling (where it's API is particularly bad to begin with). poll or epoll? poll will not cut the cheese I belive. As far as I can remember libevent is in Varnish to ease the portability since libevent supports kqueue and epoll through a API. If it does not work as it is supposed, go ahead and rip it out. You can, and I am not gonna insist on you doing it, ask the mailinglist of libevent if there are others that have the same problem (apart from the bad API) before you do it. It's your call. Anders Berg From andersb at vgnett.no Wed Aug 2 11:05:53 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 2 Aug 2006 13:05:53 +0200 (CEST) Subject: NUUG meeting In-Reply-To: <20060802110139.GA75431@totem.fix.no> References: <20060802095017.GA75053@totem.fix.no> <45207.1154512312@critter.freebsd.dk> <20060802110139.GA75431@totem.fix.no> Message-ID: <1225.193.213.34.102.1154516753.squirrel@denise.vg.no> > Hi, > > On Wed, Aug 02, 2006 at 09:51:52AM +0000, Poul-Henning Kamp wrote: >> >>>> I suggest we nail down the dates for the live test 2 (and NUUG >> talk) >> >>>> and set the delivery/goal when we have more firm estimates. >> >> So is August 7-11 firm for the live-test 2 ? >> >> >> >> Do we need a full week ? >> >> >> >> I guess if we get too much time, DES and I can work on docs etc. >> > >> >NUUG wants to set up their august meeting now, and are thinking about >> >setting up a different meeting if we can not decide. >> > >> >Is it still too early to plan a NUUG meeting about Varnish in august? >> Is >> >september more realistic? >> Not that I don't like Oslo or anything, but I don't see much reason >> for me to fly up there until the release-party, so I think >> we should aim for me speaking at NUUG at that time. > > At that time, which is what time? August or september? Just trying to > find a date we could agree with them on, so that they can book a room > and announce the meeting in time. > > If it's still to early to set a date, I can report that. But that might > mean something else will be on the agenda. Either 20. or 21. sept. is the time we plan to announce it. If we choose the 20. NUUG will get it one day before everybody else :) How are those dates? Anders Berg > Cheers, > > -- > Anders. > > From phk at phk.freebsd.dk Wed Aug 2 11:44:41 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 02 Aug 2006 11:44:41 +0000 Subject: NUUG meeting In-Reply-To: Your message of "Wed, 02 Aug 2006 13:01:39 +0200." <20060802110139.GA75431@totem.fix.no> Message-ID: <80104.1154519081@critter.freebsd.dk> In message <20060802110139.GA75431 at totem.fix.no>, Anders Nordby writes: >> >Is it still too early to plan a NUUG meeting about Varnish in august? Is >> >september more realistic? >> Not that I don't like Oslo or anything, but I don't see much reason >> for me to fly up there until the release-party, so I think >> we should aim for me speaking at NUUG at that time. > >At that time, which is what time? August or september? Just trying to >find a date we could agree with them on, so that they can book a room >and announce the meeting in time. > >If it's still to early to set a date, I can report that. But that might >mean something else will be on the agenda. I'm not 100% sure if the official release party date has been nailed down, Anders Berg og Dag-Erling would know that (I hope :-) -- 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 Wed Aug 2 19:18:12 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 02 Aug 2006 19:18:12 +0000 Subject: libevent is SOOO going to die... Message-ID: <20747.1154546292@critter.freebsd.dk> After eliminating libevent from the traffic part of varnish number of syscalls per request has dropped 20-30% and our service time for cache hits as well. I'll eliminate it from the CLI and then we can zap it from svn. -- 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 andersb at vgnett.no Thu Aug 3 00:56:05 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 3 Aug 2006 02:56:05 +0200 (CEST) Subject: libevent is SOOO going to die... In-Reply-To: <20747.1154546292@critter.freebsd.dk> References: <20747.1154546292@critter.freebsd.dk> Message-ID: <1621.193.69.165.4.1154566565.squirrel@denise.vg.no> > > After eliminating libevent from the traffic part of varnish > number of syscalls per request has dropped 20-30% and our > service time for cache hits as well. > > I'll eliminate it from the CLI and then we can zap it from svn. Wow, thats some speedup we are talking about! Drop it like a bad habit. Should we maybe notify the libevent devlist about this? Seems like the right thing to do if the numbers are right. Anders Berg From phk at phk.freebsd.dk Thu Aug 3 05:05:15 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 03 Aug 2006 05:05:15 +0000 Subject: libevent is SOOO going to die... In-Reply-To: Your message of "Thu, 03 Aug 2006 02:56:05 +0200." <1621.193.69.165.4.1154566565.squirrel@denise.vg.no> Message-ID: <38834.1154581515@critter.freebsd.dk> In message <1621.193.69.165.4.1154566565.squirrel at denise.vg.no>, "Anders Berg" writes: >Should we maybe notify the libevent devlist about this? Seems like the >right thing to do if the numbers are right. As soon as they reply to the first two emails I sent them I might consider 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 andersb at vgnett.no Thu Aug 3 10:09:37 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 3 Aug 2006 12:09:37 +0200 (CEST) Subject: [Fwd: Re: libevent is SOOO going to die...] Message-ID: <1512.193.213.34.102.1154599777.squirrel@denise.vg.no> > > After eliminating libevent from the traffic part of varnish > number of syscalls per request has dropped 20-30% and our > service time for cache hits as well. I also saw the service-time stats you posted in varnish-commit. It is safe to say that Varnish is FAST now :) Anders Berg From phk at phk.freebsd.dk Fri Aug 4 07:32:30 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 04 Aug 2006 07:32:30 +0000 Subject: live-testing Message-ID: <63497.1154676750@critter.freebsd.dk> I think the live-testing has now moved from the "basic stability" to "data tolerance" phase. Yesterdays run of more than 13 hours terminated because of a bug in the parsing of chunked encoding triggered by one particular URL on the backend. The run I started yesterday evening just crossed the 12h threshold. So rather than spend long runs at low load, waiting for these kinds of bugs, it would make more sense to test under higher load so they appear faster. Would it be OK with you Anders to raise the Alteon setting to the same as the squid boxes ? -- 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 andersb at vgnett.no Fri Aug 4 10:26:15 2006 From: andersb at vgnett.no (Anders Berg) Date: Fri, 4 Aug 2006 12:26:15 +0200 (CEST) Subject: live-testing In-Reply-To: <63497.1154676750@critter.freebsd.dk> References: <63497.1154676750@critter.freebsd.dk> Message-ID: <1564.193.69.165.4.1154687175.squirrel@denise.vg.no> > > I think the live-testing has now moved from the "basic stability" > to "data tolerance" phase. > > Yesterdays run of more than 13 hours terminated because of a bug > in the parsing of chunked encoding triggered by one particular > URL on the backend. > > The run I started yesterday evening just crossed the 12h threshold. > > So rather than spend long runs at low load, waiting for these kinds > of bugs, it would make more sense to test under higher load so they > appear faster. > > Would it be OK with you Anders to raise the Alteon setting to > the same as the squid boxes ? Done. Anders Berg > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Sat Aug 5 19:55:20 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 05 Aug 2006 19:55:20 +0000 Subject: ALPHA readme Message-ID: <5446.1154807720@critter.freebsd.dk> I am ready for alpha testers now. I have started a "ALPHA readme" on the wiki: http://varnish.projects.linpro.no/wiki/AlphaReadme Please help making it a readable document. -- 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 andersb at vgnett.no Sat Aug 5 20:09:47 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 5 Aug 2006 22:09:47 +0200 (CEST) Subject: ALPHA readme In-Reply-To: <5446.1154807720@critter.freebsd.dk> References: <5446.1154807720@critter.freebsd.dk> Message-ID: <1679.193.69.165.4.1154808587.squirrel@denise.vg.no> > > I am ready for alpha testers now. Grats on the alpha :) I'll wrap some things up in my logger and it should be able to give some results for ppl in a way that they normally are used to see traffic also. Ab From phk at phk.freebsd.dk Sat Aug 5 20:55:49 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 05 Aug 2006 20:55:49 +0000 Subject: Slow clients... Message-ID: <6101.1154811349@critter.freebsd.dk> W nbr 34 sess 0x16c1008 fd 158 xid 2017851670 step 7 handling 128 age 8555 W nbr 34 sess 0x1b3f008 fd 173 xid 2018914270 step 9 handling 64 age 5960 W nbr 29 sess 0x1902008 fd 80 xid 2019001809 step 7 handling 128 age 5729 W nbr 41 sess 0x1ef7008 fd 319 xid 2019426763 step 7 handling 128 age 4648 W nbr 35 sess 0x1c7f008 fd 45 xid 2019626419 step 7 handling 128 age 4174 W nbr 39 sess 0x1feb008 fd 264 xid 2019738777 step 1 handling 4 age 3893 This bugs me a bit, clients which for some reason or other does not pick up their document, but which leaves the TCP connection stalled. sendfile() has no way to specify a timeout. I may have to find a way to kill these worker threads with violent means. -- 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 andersb at vgnett.no Sat Aug 5 21:07:28 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 5 Aug 2006 23:07:28 +0200 (CEST) Subject: Slow clients... In-Reply-To: <6101.1154811349@critter.freebsd.dk> References: <6101.1154811349@critter.freebsd.dk> Message-ID: <1847.193.69.165.4.1154812048.squirrel@denise.vg.no> > > W nbr 34 sess 0x16c1008 fd 158 xid 2017851670 step 7 handling 128 age 8555 > W nbr 34 sess 0x1b3f008 fd 173 xid 2018914270 step 9 handling 64 age 5960 > W nbr 29 sess 0x1902008 fd 80 xid 2019001809 step 7 handling 128 age 5729 > W nbr 41 sess 0x1ef7008 fd 319 xid 2019426763 step 7 handling 128 age 4648 > W nbr 35 sess 0x1c7f008 fd 45 xid 2019626419 step 7 handling 128 age 4174 > W nbr 39 sess 0x1feb008 fd 264 xid 2019738777 step 1 handling 4 age 3893 > > This bugs me a bit, clients which for some reason or other does not > pick up their document, but which leaves the TCP connection stalled. Ouch. Can you see if Opera is overrepresente in those? I see some funny behavior from Opera in my work, but it may be just a different implementation of HTTP/1.1 than Firefox and IE, and still a be after RFC 2616. > sendfile() has no way to specify a timeout. I may have to find a way > to kill these worker threads with violent means. I guess there is no way round it. Would it make any difference if it was kernelspace and not userland? Anders Berg From phk at phk.freebsd.dk Sat Aug 5 21:21:02 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 05 Aug 2006 21:21:02 +0000 Subject: Slow clients... In-Reply-To: Your message of "Sat, 05 Aug 2006 23:07:28 +0200." <1847.193.69.165.4.1154812048.squirrel@denise.vg.no> Message-ID: <6313.1154812862@critter.freebsd.dk> In message <1847.193.69.165.4.1154812048.squirrel at denise.vg.no>, "Anders Berg" writes: >> >> W nbr 34 sess 0x16c1008 fd 158 xid 2017851670 step 7 handling 128 age 8555 >> W nbr 34 sess 0x1b3f008 fd 173 xid 2018914270 step 9 handling 64 age 5960 >> W nbr 29 sess 0x1902008 fd 80 xid 2019001809 step 7 handling 128 age 5729 >> W nbr 41 sess 0x1ef7008 fd 319 xid 2019426763 step 7 handling 128 age 4648 >> W nbr 35 sess 0x1c7f008 fd 45 xid 2019626419 step 7 handling 128 age 4174 >> W nbr 39 sess 0x1feb008 fd 264 xid 2019738777 step 1 handling 4 age 3893 >> >> This bugs me a bit, clients which for some reason or other does not >> pick up their document, but which leaves the TCP connection stalled. > >Ouch. Can you see if Opera is overrepresente in those? I see some funny >behavior from Opera in my work, but it may be just a different >implementation of HTTP/1.1 than Firefox and IE, and still a be after RFC >2616. Opera is quite agressive HTTP wise, that's for sure. I havn't really examined it in details yet. >> sendfile() has no way to specify a timeout. I may have to find a way >> to kill these worker threads with violent means. > >I guess there is no way round it. Would it make any difference if it was >kernelspace and not userland? I think there are two ways: Use the relatively simple way we do it now and have a watcher thread kill them if it takes too long. This is a fair bit more violent than I like, and quite prone to errors in threading implementations. The other way is to make the sockets nonblocking and let sendfile(2) return partial writes and then enter a poll/sendfile look with a timeout. A variation of the second scheme is that after N seconds, the session is handed over to a central "slow session pusher" thread and the worker thread grabs interesting new work instead. I'll have to think about that one some more... -- 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 des at linpro.no Sun Aug 6 12:10:38 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sun, 06 Aug 2006 14:10:38 +0200 Subject: ALPHA readme References: <5446.1154807720@critter.freebsd.dk> Message-ID: Poul-Henning Kamp writes: > I am ready for alpha testers now. > > I have started a "ALPHA readme" on the wiki: > > http://varnish.projects.linpro.no/wiki/AlphaReadme > > Please help making it a readable document. Working on it. The autotools stuff is not a problem, we'll ship a tarball with a working configure file etc. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Sun Aug 6 16:51:56 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sun, 06 Aug 2006 18:51:56 +0200 Subject: tot dumps core References: <76711.1153237239@critter.freebsd.dk> Message-ID: des at linpro.no (Dag-Erling Sm?rgrav) writes: > I thought the problem might be 64-bit-specific, so I tested on a VIA > Epia system, and I'm getting something completely different: [...] The problems on the Epia box turned out to be a borked libc - probably cvsupped at a bad time. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Sun Aug 6 17:24:37 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sun, 06 Aug 2006 19:24:37 +0200 Subject: cli.c Message-ID: Is it really appropriate to have cli.c in libvarnish when it depends on functions which are defined only in varnishd? Perhaps it should be included in varnishd, or perhaps all the cli code (from libvarnish and varnishd) should be moved into a separate libvarnishcli? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Sun Aug 6 17:29:41 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 06 Aug 2006 17:29:41 +0000 Subject: cli.c In-Reply-To: Your message of "Sun, 06 Aug 2006 19:24:37 +0200." Message-ID: <21336.1154885381@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Is it really appropriate to have cli.c in libvarnish when it depends >on functions which are defined only in varnishd? Perhaps it should be >included in varnishd, or perhaps all the cli code (from libvarnish and >varnishd) should be moved into a separate libvarnishcli? cli.c is meant as the "CLI engine". It relies on the caller to provide a command list and two functions: the "output" and the "result" function. The original intention was to reuse this also in the cluster controller and any other place where we deal with the CLI. If anything it might be more appropriate to move stuff from varnishd to libvarnish, things like the functions in common_cli.[ch] are primary candidates. -- 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 des at linpro.no Mon Aug 7 05:44:36 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 07:44:36 +0200 Subject: cli.c References: <21336.1154885381@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > If anything it might be more appropriate to move stuff from varnishd > to libvarnish, things like the functions in common_cli.[ch] are > primary candidates. OK. Perhaps there should be a mechanism to register callbacks for these functions? In any case, I'll move cli_common into libvarnish since it's blocking other work. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Mon Aug 7 06:28:16 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 08:28:16 +0200 Subject: libsbuf Message-ID: I'm thinking of folding libsbuf into libvarnish, with s/sbuf/VSB/. The reason for this is that a) our libsbuf is no longer a direct import of FreeBSD's libsbuf, and b) installing a libsbuf.so in /usr/local/bin or wherever is a bad idea... Any objections? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Aug 7 07:52:08 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 07:52:08 +0000 Subject: cli.c In-Reply-To: Your message of "Mon, 07 Aug 2006 07:44:36 +0200." Message-ID: <24435.1154937128@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> If anything it might be more appropriate to move stuff from varnishd >> to libvarnish, things like the functions in common_cli.[ch] are >> primary candidates. > >OK. Perhaps there should be a mechanism to register callbacks for >these functions? In any case, I'll move cli_common into libvarnish >since it's blocking other work. I'm confused, how 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 phk at phk.freebsd.dk Mon Aug 7 07:53:09 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 07:53:09 +0000 Subject: libsbuf In-Reply-To: Your message of "Mon, 07 Aug 2006 08:28:16 +0200." Message-ID: <24472.1154937189@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >I'm thinking of folding libsbuf into libvarnish, with s/sbuf/VSB/. >The reason for this is that a) our libsbuf is no longer a direct >import of FreeBSD's libsbuf, and b) installing a libsbuf.so in >/usr/local/bin or wherever is a bad idea... Any objections? Works for me. -- 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 des at linpro.no Mon Aug 7 08:53:40 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 10:53:40 +0200 Subject: cli.c In-Reply-To: <24435.1154937128@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 07 Aug 2006 07:52:08 +0000") References: <24435.1154937128@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > "Dag-Erling Sm?rgrav" writes: > > OK. Perhaps there should be a mechanism to register callbacks for > > these functions? In any case, I'll move cli_common into > > libvarnish since it's blocking other work. > I'm confused, how so ? It prevents using libvarnish in other programs than varnishd. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Aug 7 09:45:22 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 09:45:22 +0000 Subject: cli.c In-Reply-To: Your message of "Mon, 07 Aug 2006 10:53:40 +0200." Message-ID: <41740.1154943922@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> "Dag-Erling Sm=F8rgrav" writes: >> > OK. Perhaps there should be a mechanism to register callbacks for >> > these functions? In any case, I'll move cli_common into >> > libvarnish since it's blocking other work. >> I'm confused, how so ? > >It prevents using libvarnish in other programs than varnishd. Ohh, because the lack of cli_out() and cli_response() ? -- 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 Aug 7 09:48:47 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 09:48:47 +0000 Subject: sendfile surprise Message-ID: <41767.1154944127@critter.freebsd.dk> I had tacitly assumed that sendfile(2) would be faster than a write, but it may no be while data is still in RAM. While working on the slow client timeout, I have taken sendfile out for now and as a result I see the Alteon loading us with up to 1500 req/s, which I take to mean that our responsetime is better now. The stats don't quite confirm that this is the case, but we don't actually record "time to first packet goes out" so the alteon may see things differently than us. -- 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 des at linpro.no Mon Aug 7 09:57:00 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 11:57:00 +0200 Subject: cli.c References: <41740.1154943922@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > "Dag-Erling Sm=F8rgrav" writes: > > "Poul-Henning Kamp" writes: > > > "Dag-Erling Sm=F8rgrav" writes: > > > > OK. Perhaps there should be a mechanism to register callbacks for > > > > these functions? In any case, I'll move cli_common into > > > > libvarnish since it's blocking other work. > > > I'm confused, how so ? > > It prevents using libvarnish in other programs than varnishd. > Ohh, because the lack of cli_out() and cli_response() ? Yes... DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Aug 7 10:24:18 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 10:24:18 +0000 Subject: sendfile surprise In-Reply-To: Your message of "Mon, 07 Aug 2006 09:48:47 GMT." <41767.1154944127@critter.freebsd.dk> Message-ID: <41917.1154946258@critter.freebsd.dk> In message <41767.1154944127 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: > >I had tacitly assumed that sendfile(2) would be faster than >a write, but it may no be while data is still in RAM. > >While working on the slow client timeout, I have taken sendfile >out for now and as a result I see the Alteon loading us with >up to 1500 req/s, which I take to mean that our responsetime is >better now. > >The stats don't quite confirm that this is the case, but we don't >actually record "time to first packet goes out" so the alteon >may see things differently than us. Actually, come to think of it, it's monday morning, the day after vacation, I guess the traffic might just be more intense now ? -- 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 des at linpro.no Mon Aug 7 11:02:05 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 13:02:05 +0200 Subject: sendfile surprise References: <41917.1154946258@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > "Poul-Henning Kamp" writes: > > While working on the slow client timeout, I have taken sendfile > > out for now and as a result I see the Alteon loading us with up to > > 1500 req/s, which I take to mean that our responsetime is better > > now. > Actually, come to think of it, it's monday morning, the day after > vacation, I guess the traffic might just be more intense now ? I don't know. It makes sense that sendfile(2) should have a higher start-up cost (hence also a higher response time) than plain write(2); it's probably not worth it for small documents. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Mon Aug 7 13:46:19 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 7 Aug 2006 15:46:19 +0200 Subject: sendfile surprise In-Reply-To: <41917.1154946258@critter.freebsd.dk> References: <41917.1154946258@critter.freebsd.dk> Message-ID: <20C0B913-28DC-4469-BDF3-7D0D17446EA4@vgnett.no> On Aug 7, 2006, at 12:24, Poul-Henning Kamp wrote: > In message <41767.1154944127 at critter.freebsd.dk>, "Poul-Henning > Kamp" writes: >> >> I had tacitly assumed that sendfile(2) would be faster than >> a write, but it may no be while data is still in RAM. >> >> While working on the slow client timeout, I have taken sendfile >> out for now and as a result I see the Alteon loading us with >> up to 1500 req/s, which I take to mean that our responsetime is >> better now. >> >> The stats don't quite confirm that this is the case, but we don't >> actually record "time to first packet goes out" so the alteon >> may see things differently than us. > > > Actually, come to think of it, it's monday morning, the day > after vacation, I guess the traffic might just be more intense > now ? The traffic is somewhat higher than normal, but not very much. Daytime is alot more intensive then after 1600, anyway. Anders Berg > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > From des at linpro.no Mon Aug 7 16:38:04 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Mon, 07 Aug 2006 18:38:04 +0200 Subject: Release Message-ID: The tree is now in such a state that it is possible to roll a release, in the sense that 'make dist' will produce a tarball which will build cleanly. There are still outstanding issues, though: - Portability: mostly the following issues: - printf() extensions - srandomdev() - - strptime() - vis() / strvis() - Documentation: for the Alpha release, all we need are installation instructions and a quick "getting started" guide. Both are at least partly written already. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Mon Aug 7 17:22:18 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 17:22:18 +0000 Subject: Release In-Reply-To: Your message of "Mon, 07 Aug 2006 18:38:04 +0200." Message-ID: <54187.1154971338@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: > - Portability: mostly the following issues: > > - printf() extensions These are now only used in the vcl compiler which defines the %T extension. This should hopefully work fine with GNU libc as well. > - srandomdev() Any good seed is acceptable. It's just to avoid the XID starting from zero every time (for any value of zero). > - I've been thinking of using a more lightweight hash anyway. > - strptime() This can be unrolled at some expense in source code. > - vis() / strvis() This is used in varnishlog to make sure that Debug records don't trash the screen with binary stuff which might leak through. Again, that can be unrolled. > - Documentation: for the Alpha release, all we need are installation > instructions and a quick "getting started" guide. Both are at > least partly written already. -- 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 Aug 7 17:31:48 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 17:31:48 +0000 Subject: Release In-Reply-To: Your message of "Mon, 07 Aug 2006 18:38:04 +0200." Message-ID: <69847.1154971908@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >The tree is now in such a state that it is possible to roll a release, >in the sense that 'make dist' will produce a tarball which will build >cleanly. There are still outstanding issues, though: > > - Portability: mostly the following issues: > > - printf() extensions > - srandomdev() > - > - strptime() > - vis() / strvis() I had sort of expected you would make a test for KQUEUE precence and fiddle the cache_acceptor accordingly ? -- 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 Aug 7 21:18:21 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 07 Aug 2006 21:18:21 +0000 Subject: latest response-time data Message-ID: <30123.1154985501@critter.freebsd.dk> All numbers in milliseconds. FRACTILE MIN MAX AVG MEDIAN 0-90% 0.028 0.052 0.039 0.038 90-99% 0.052 0.895 0.121 0.121 99-100% 100 535 320 329 The 0-90% fractile is very stable, the other two depend a lot on the backend. It looks like avoiding the extensible printf shaved a microsecond off those numbers. -- 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 andersb at vgnett.no Mon Aug 7 21:52:08 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 7 Aug 2006 23:52:08 +0200 (CEST) Subject: latest response-time data In-Reply-To: <30123.1154985501@critter.freebsd.dk> References: <30123.1154985501@critter.freebsd.dk> Message-ID: <1720.193.69.165.4.1154987528.squirrel@denise.vg.no> > > All numbers in milliseconds. > > FRACTILE MIN MAX AVG MEDIAN > > 0-90% 0.028 0.052 0.039 0.038 > 90-99% 0.052 0.895 0.121 0.121 > 99-100% 100 535 320 329 > > The 0-90% fractile is very stable, the other two depend a lot on > the backend. > > It looks like avoiding the extensible printf shaved a microsecond > off those numbers. With numbers like these it's probably safe to say that varnish will probably never be the bottleneck :) Great numbers! Anders Berg From andersb at vgnett.no Mon Aug 7 22:13:27 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 00:13:27 +0200 (CEST) Subject: GbE equipment Message-ID: <1860.193.69.165.4.1154988807.squirrel@denise.vg.no> Hi, I am receiving the GbE equipment on friday most probably. It should be a quick job to install it when it's here. So I look forward to test Varnish with full traffic next week :) For maximum traffic, we need to serve www.vg.no and flash.vg.no (flash files mostly) at the same time. If we do that, traffic in the 400-500Mbit range should be normal on daytime. Anders Berg From des at linpro.no Tue Aug 8 05:48:21 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 08 Aug 2006 07:48:21 +0200 Subject: Release In-Reply-To: <54187.1154971338@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 07 Aug 2006 17:22:18 +0000") References: <54187.1154971338@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Dag-Erling Sm?rgrav writes: > > - printf() extensions > These are now only used in the vcl compiler which defines the %T > extension. This should hopefully work fine with GNU libc as well. The extensions themselves are not a problem on Linux; register_printf_render_std() is, but it is no longer used. > > - srandomdev() > Any good seed is acceptable. It's just to avoid the XID starting > from zero every time (for any value of zero). I'll simply add srandomdev() to libcompat. > > - strptime() > This can be unrolled at some expense in source code. Far easier to just stick FreeBSD's strptime() in libcompat. > > - vis() / strvis() > This is used in varnishlog to make sure that Debug records don't > trash the screen with binary stuff which might leak through. Again, > that can be unrolled. Again, we can add them to libcompat. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Tue Aug 8 05:49:04 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 08 Aug 2006 07:49:04 +0200 Subject: Release In-Reply-To: <69847.1154971908@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 07 Aug 2006 17:31:48 +0000") References: <69847.1154971908@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I had sort of expected you would make a test for KQUEUE precence > and fiddle the cache_acceptor accordingly ? I'm not quite there yet... DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 8 05:54:14 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 08 Aug 2006 05:54:14 +0000 Subject: Release In-Reply-To: Your message of "Tue, 08 Aug 2006 07:48:21 +0200." Message-ID: <31980.1155016454@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Dag-Erling Sm=F8rgrav writes: >> > - printf() extensions >> These are now only used in the vcl compiler which defines the %T >> extension. This should hopefully work fine with GNU libc as well. > >The extensions themselves are not a problem on Linux; >register_printf_render_std() is, but it is no longer used. I ripped them out entirely, it transpired that there is a syslog bug in FreeBSD so it would be impossible for the manager to use syslog as long as they were in. We also gained a tad of performance which sort of surprised me. -- 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 Aug 8 06:04:41 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 08 Aug 2006 06:04:41 +0000 Subject: GbE equipment In-Reply-To: Your message of "Tue, 08 Aug 2006 00:13:27 +0200." <1860.193.69.165.4.1154988807.squirrel@denise.vg.no> Message-ID: <32059.1155017081@critter.freebsd.dk> In message <1860.193.69.165.4.1154988807.squirrel at denise.vg.no>, "Anders Berg" writes: >Hi, > >I am receiving the GbE equipment on friday most probably. >It should be a quick job to install it when it's here. So I look forward >to test Varnish with full traffic next week :) > >For maximum traffic, we need to serve www.vg.no and flash.vg.no (flash >files mostly) at the same time. If we do that, traffic in the 400-500Mbit >range should be normal on daytime. No wonder you dared take the bet when you knew we couldn't validate that I've won :-) looking forward 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 phk at phk.freebsd.dk Tue Aug 8 06:14:19 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 08 Aug 2006 06:14:19 +0000 Subject: latest response-time data In-Reply-To: Your message of "Mon, 07 Aug 2006 23:52:08 +0200." <1720.193.69.165.4.1154987528.squirrel@denise.vg.no> Message-ID: <32122.1155017659@critter.freebsd.dk> In message <1720.193.69.165.4.1154987528.squirrel at denise.vg.no>, "Anders Berg" writes: >> >> All numbers in milliseconds. >> >> FRACTILE MIN MAX AVG MEDIAN >> >> 0-90% 0.028 0.052 0.039 0.038 >> 90-99% 0.052 0.895 0.121 0.121 >> 99-100% 100 535 320 329 >> >> The 0-90% fractile is very stable, the other two depend a lot on >> the backend. >> >> It looks like avoiding the extensible printf shaved a microsecond >> off those numbers. > >With numbers like these it's probably safe to say that varnish will >probably never be the bottleneck :) Well, _never_ is such a big word, but compared to the competition: no, it will not. This morning after having gobbeled up 23000 objects, varnish is a bit slower, 45 microseconds for a hit. That is in all likelyhood the hash-chains that has gotten longer, with my usual faith in MD5's spectrum, they would all be around 23000/256 = 89 entries long, which is too long IMO. The default value of 256 hash buckets may be too conservative. Increasing the number of hash-buckets can be done, but it's a mess: you basically have a list of hash arrays and always insert in the top most one, but you search them all to have a miss. Then once objects have expired from the lower levels, you can remove those levels. It's clearly a "would be nice to have, but not really critical" 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 andersb at vgnett.no Tue Aug 8 07:58:12 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 09:58:12 +0200 Subject: latest response-time data In-Reply-To: <32122.1155017659@critter.freebsd.dk> References: <32122.1155017659@critter.freebsd.dk> Message-ID: <8D2A4BA5-A50F-442D-A67D-86E1B20A0466@vgnett.no> On Aug 8, 2006, at 8:14, Poul-Henning Kamp wrote: > In message <1720.193.69.165.4.1154987528.squirrel at denise.vg.no>, > "Anders Berg" > writes: >>> >>> All numbers in milliseconds. >>> >>> FRACTILE MIN MAX AVG MEDIAN >>> >>> 0-90% 0.028 0.052 0.039 0.038 >>> 90-99% 0.052 0.895 0.121 0.121 >>> 99-100% 100 535 320 329 >>> >>> The 0-90% fractile is very stable, the other two depend a lot on >>> the backend. >>> >>> It looks like avoiding the extensible printf shaved a microsecond >>> off those numbers. > > It's clearly a "would be nice to have, but not really critical" > thing. Do we have a place/list where we can note stuff that falls into this category? Like a Can-Do list? Anders Berg From andersb at vgnett.no Tue Aug 8 08:05:04 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 10:05:04 +0200 Subject: latest response-time data In-Reply-To: <8D2A4BA5-A50F-442D-A67D-86E1B20A0466@vgnett.no> References: <32122.1155017659@critter.freebsd.dk> <8D2A4BA5-A50F-442D-A67D-86E1B20A0466@vgnett.no> Message-ID: On Aug 8, 2006, at 9:58, Anders Berg wrote: > > On Aug 8, 2006, at 8:14, Poul-Henning Kamp wrote: > >> In message <1720.193.69.165.4.1154987528.squirrel at denise.vg.no>, >> "Anders Berg" >> writes: >>>> >>>> All numbers in milliseconds. >>>> >>>> FRACTILE MIN MAX AVG MEDIAN >>>> >>>> 0-90% 0.028 0.052 0.039 0.038 >>>> 90-99% 0.052 0.895 0.121 0.121 >>>> 99-100% 100 535 320 329 >>>> >>>> The 0-90% fractile is very stable, the other two depend a lot on >>>> the backend. >>>> >>>> It looks like avoiding the extensible printf shaved a microsecond >>>> off those numbers. >> >> It's clearly a "would be nice to have, but not really critical" >> thing. > > Do we have a place/list where we can note stuff that falls into > this category? > Like a Can-Do list? I saw that the MD5 got replaced btw. Still we should maintain a list like this. Anders Berg From andersb at vgnett.no Tue Aug 8 08:09:21 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 10:09:21 +0200 Subject: GbE equipment In-Reply-To: <32059.1155017081@critter.freebsd.dk> References: <32059.1155017081@critter.freebsd.dk> Message-ID: <6508FE5A-1CB7-4BAE-8160-DB8AAB95AE48@vgnett.no> On Aug 8, 2006, at 8:04, Poul-Henning Kamp wrote: > In message <1860.193.69.165.4.1154988807.squirrel at denise.vg.no>, > "Anders Berg" > writes: >> Hi, >> >> I am receiving the GbE equipment on friday most probably. >> It should be a quick job to install it when it's here. So I look >> forward >> to test Varnish with full traffic next week :) >> >> For maximum traffic, we need to serve www.vg.no and flash.vg.no >> (flash >> files mostly) at the same time. If we do that, traffic in the >> 400-500Mbit >> range should be normal on daytime. > > No wonder you dared take the bet when you knew we couldn't validate > that I've won :-) Hehe, I should be working in the marketing department :) > looking forward to it. Me too. It will be fun to see how the OS reacts to the increased load. Anders Berg From des at linpro.no Tue Aug 8 08:46:22 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 08 Aug 2006 10:46:22 +0200 Subject: latest response-time data References: <32122.1155017659@critter.freebsd.dk> <8D2A4BA5-A50F-442D-A67D-86E1B20A0466@vgnett.no> Message-ID: Anders Berg writes: > Anders Berg writes: > > Do we have a place/list where we can note stuff that falls into > > this category? Like a Can-Do list? > I saw that the MD5 got replaced btw. Still we should maintain a list > like this. MD5 was replaced with CRC32, but the code that manages the list is unchanged. And issues like this can simply be entered as tickets with the type field set to "enhancement". DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Tue Aug 8 15:25:08 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 08 Aug 2006 17:25:08 +0200 Subject: Varnish on Linux Message-ID: Varnish now runs on Linux, with one known issue. When Varnish starts, open_tcp() tries to bind and listen to four addresses: - [::1]:80 - 127.0.0.1:80 - [::]:80 - 0.0.0.0:80 The first two are redundant on any system; FreeBSD doesn't mind, but Linux balks. I don't see the point, and suggest killing off heritage.sock_local. Linux also balks at the last one, because apparently an IPv6 socket gets both IPv4 and IPv6 connections in Linux, so you can't listen on an IPv4 socket if someone is already listening on the same port on an IPv6 socket. The best way to do this is what I did in varnish-proto six months ago: create only an IPv6 socket, and zero the IPV6_V6ONLY sockopt on it, and it will get both IPv4 and IPv6 connections (as is the default on Linux, but AFAIK not on FreeBSD). See here for a working example: http://varnish.projects.linpro.no/browser/trunk/varnish-proto/listener.c DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 8 16:01:45 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 08 Aug 2006 16:01:45 +0000 Subject: Varnish on Linux In-Reply-To: Your message of "Tue, 08 Aug 2006 17:25:08 +0200." Message-ID: <8283.1155052905@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Varnish now runs on Linux, with one known issue. When Varnish starts, >open_tcp() tries to bind and listen to four addresses: > > - [::1]:80 > - 127.0.0.1:80 > - [::]:80 > - 0.0.0.0:80 The reason for all this is that we talked about being able to prime the varnish from a local perl-script and therefore we wanted to listen to localhost before we listen from the net as such. A much easier way to do that would be to listen to port 81 first and then port 80 when we go public. The other half of this is that we both overlooked that there is no "unlisten" call and no way, short of closing the socket to get that effect. So with this bit if wisdom in our hats, how do we want varnish to behave ? Should we just listen to *:80 and be done with 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 andersb at vgnett.no Tue Aug 8 16:24:34 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 18:24:34 +0200 (CEST) Subject: Varnish on Linux In-Reply-To: <8283.1155052905@critter.freebsd.dk> References: Your message of "Tue, 08 Aug 2006 17:25:08 +0200." <8283.1155052905@critter.freebsd.dk> Message-ID: <2509.193.213.34.102.1155054274.squirrel@denise.vg.no> > In message , Dag-Erling > =?iso-8859-1?Q?Sm=F8rgra > v?= writes: > >>Varnish now runs on Linux, with one known issue. When Varnish starts, >>open_tcp() tries to bind and listen to four addresses: >> >> - [::1]:80 >> - 127.0.0.1:80 >> - [::]:80 >> - 0.0.0.0:80 > > The reason for all this is that we talked about being able > to prime the varnish from a local perl-script and therefore > we wanted to listen to localhost before we listen from > the net as such. > > A much easier way to do that would be to listen to port 81 > first and then port 80 when we go public. > > The other half of this is that we both overlooked that there > is no "unlisten" call and no way, short of closing the socket > to get that effect. > > So with this bit if wisdom in our hats, how do we want > varnish to behave ? > > Should we just listen to *:80 and be done with it ? For now that is okay with me. We are not gonna add priming in v 1.0 anyway are we? So I suggest we rewrite that part later, when/if we add priming. Anders Berg From andersb at vgnett.no Tue Aug 8 16:25:28 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 18:25:28 +0200 (CEST) Subject: Varnish on Linux In-Reply-To: References: Message-ID: <2513.193.213.34.102.1155054328.squirrel@denise.vg.no> DES Wrote: > Varnish now runs on Linux, with one known issue. Great! Thats good work, and FAST as well. :) Anders Berg From andersb at vgnett.no Tue Aug 8 19:50:18 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 8 Aug 2006 21:50:18 +0200 (CEST) Subject: Varnish on Linux In-Reply-To: <2509.193.213.34.102.1155054274.squirrel@denise.vg.no> References: Your message of "Tue, 08 Aug 2006 17:25:08+0200."<8283.1155052905@critter.freebsd.dk> <2509.193.213.34.102.1155054274.squirrel@denise.vg.no> Message-ID: <1953.193.69.165.4.1155066618.squirrel@denise.vg.no> >> In message , Dag-Erling >> =?iso-8859-1?Q?Sm=F8rgra >> v?= writes: >> >> Should we just listen to *:80 and be done with it ? > > For now that is okay with me. We are not gonna add priming in v 1.0 anyway > are we? So I suggest we rewrite that part later, when/if we add priming. Btw, here is some info about prefetching: http://www.usenix.org/events/usits03/tech/full_papers/kokku/kokku_html/index.html Anders Berg From des at linpro.no Wed Aug 9 06:31:45 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 09 Aug 2006 08:31:45 +0200 Subject: Varnish on Linux References: <8283.1155052905@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Should we just listen to *:80 and be done with it ? That's good enough for me... DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From anders at fupp.net Wed Aug 9 09:53:30 2006 From: anders at fupp.net (Anders Nordby) Date: Wed, 9 Aug 2006 11:53:30 +0200 Subject: Varnish on Linux In-Reply-To: References: <8283.1155052905@critter.freebsd.dk> Message-ID: <20060809095330.GA81150@totem.fix.no> Hi, On Wed, Aug 09, 2006 at 08:31:45AM +0200, Dag-Erling Sm?rgrav wrote: >> Should we just listen to *:80 and be done with it ? > That's good enough for me... Is it possible to specify which ports and IP addresses to listen to? Some people might want to adjust this. Cheers, -- Anders. From ssm at linpro.no Wed Aug 9 10:38:36 2006 From: ssm at linpro.no (Stig Sandbeck Mathisen) Date: Wed, 09 Aug 2006 12:38:36 +0200 Subject: Varnish on Linux References: <8283.1155052905@critter.freebsd.dk> <20060809095330.GA81150@totem.fix.no> Message-ID: <7xk65ijis3.fsf@linpro.no> Anders Nordby writes: > Hi, > > On Wed, Aug 09, 2006 at 08:31:45AM +0200, Dag-Erling Sm?rgrav wrote: >>> Should we just listen to *:80 and be done with it ? >> That's good enough for me... > > Is it possible to specify which ports and IP addresses to listen to? > Some people might want to adjust this. I know I do. Several of our servers have different servers listening on port 80 on different addresses. But *:80 is a decent default for a http accellerator. -- Stig Sandbeck Mathisen, Linpro From phk at phk.freebsd.dk Wed Aug 9 10:41:42 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 10:41:42 +0000 Subject: Varnish on Linux In-Reply-To: Your message of "Wed, 09 Aug 2006 11:53:30 +0200." <20060809095330.GA81150@totem.fix.no> Message-ID: <12180.1155120102@critter.freebsd.dk> In message <20060809095330.GA81150 at totem.fix.no>, Anders Nordby writes: >Hi, > >On Wed, Aug 09, 2006 at 08:31:45AM +0200, Dag-Erling Sm?rgrav wrote: >>> Should we just listen to *:80 and be done with it ? >> That's good enough for me... > >Is it possible to specify which ports and IP addresses to listen to? >Some people might want to adjust this. We already have -p for port Adding an option for specifying address shouldn't be too much 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 des at linpro.no Wed Aug 9 11:36:05 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 09 Aug 2006 13:36:05 +0200 Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl References: <20060809112439.2C2711EC670@projects.linpro.no> Message-ID: des at projects.linpro.no writes: > Log: > Add support for using separate backends for separate virtual hosts: > > - remove the obj.backend variable, which is not connected to anything. > - define a req.backend variable and implement l/r functions for it > - complete / correct support for setting / comparing backend values With this patch, I have successfully proxied VG and Aftenposten through the same Varnish instance using the following VCL code: > backend vg { > set backend.host = "leonora.vg.no"; > set backend.port = "80"; > } > > backend tanta { > set backend.host = "80.91.37.210"; /* www.aftenposten.no */ > set backend.port = "80"; > } > > sub vcl_recv { > if (req.http.host ~ "^(www\\.)?vg\\.no$") { > /* set req.http.host = "www.vg.no"; */ > set req.backend = vg; > } elsif (req.http.host ~ "^(www\\.)?aftenposten\\.no$") { > /* set req.http.host = "www.aftenposten.no"; */ > set req.backend = tanta; > } else { > error 404; > } > } Note that this only works if the client provides a valid Host: header. What I want to do in the long run is: - define HTTP_HDR_HOST and the corresponding req.host variable to be used instead of req.http.host. - add code to cache_http.c to dissect and normalize the request URL, and set the initial value of req.host based on the host part of the request URL and / or the Host: header - make req.host and req.url writable so vcl_recv can perform further normalization if needed (e.g. rewrite vg.no to www.vg.no) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Aug 9 11:45:11 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 11:45:11 +0000 Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl In-Reply-To: Your message of "Wed, 09 Aug 2006 13:36:05 +0200." Message-ID: <12444.1155123911@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >> if (req.http.host ~ "^(www\\.)?vg\\.no$") { I think we should drop \ substitution in VCL strings in toto. Instead we could allow HTTP like %xx so that people can get " into a string. Comments ? >Note that this only works if the client provides a valid Host: header. >What I want to do in the long run is: > > - define HTTP_HDR_HOST and the corresponding req.host variable to be > used instead of req.http.host. Uhm, please don't. HOST is not a field in the HTTP protocol, it is a header and should be treated as such. > - add code to cache_http.c to dissect and normalize the request URL, > and set the initial value of req.host based on the host part of the > request URL and / or the Host: header I have yet to see a single requst which included the host in the URI. > - make req.host and req.url writable so vcl_recv can perform further > normalization if needed (e.g. rewrite vg.no to www.vg.no) yes. -- 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 Wed Aug 9 11:57:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 11:57:52 +0000 Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl In-Reply-To: Your message of "Wed, 09 Aug 2006 11:45:11 GMT." <12444.1155123911@critter.freebsd.dk> Message-ID: <12533.1155124672@critter.freebsd.dk> In message <12444.1155123911 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >> - define HTTP_HDR_HOST and the corresponding req.host variable to be >> used instead of req.http.host. > >Uhm, please don't. HOST is not a field in the HTTP protocol, it is >a header and should be treated as such. I realized I should explain this more fully. Part of the HTTP standard is that the Connection: header lists headers which should be supressed before forwarning, so it is possible to do things like: Connection: Host While it may not make sense, it is legal. If you introduce HTTP_HDR_HOST we will have to special case it in that code, and I'd rather avoid that. -- 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 Wed Aug 9 12:20:04 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 12:20:04 +0000 Subject: YAEH! milestone reached! Message-ID: <12656.1155126004@critter.freebsd.dk> I know this isn't an official milestone, but for me personally it is a major milestone: we've run for 24h continously. Yah! Poul-Henning 1d+00:01:04 syscalls: 14634.145/s 19.775/req Hitrate ratio: 2 2 2 Hitrate avg: 0.9911 0.9911 0.9911 5895592 116.85 68.19 Client connections accepted 40879728 740.05 472.79 Client requests received 40536769 732.06 468.83 Cache hits 2158 0.00 0.02 Cache hits for pass 285171 7.99 3.30 Cache misses 342780 7.99 3.96 Backend connections initiated 0 0.00 0.00 Backend connections recyles 27 2.00 0.00 Backend connections unused 1627 -3.99 0.02 N struct srcaddr 318 -6.99 0.00 N active struct srcaddr 417 -2.00 0.00 N struct sess 62576 10.99 0.72 N struct object 62578 9.99 0.72 N struct objecthead 51860 3.99 0.60 N struct smf 28 0.00 0.00 N struct vbe_conn 21 1.00 0.00 N worker threads 13076 1.00 0.15 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 16 -1.00 0.00 N busy worker threads 0 0.00 0.00 N queued work requests 235155 2.00 2.72 N expired objects 104 2.00 0.00 N objects on deathrow 0 0.00 0.00 HTTP header overflows 5881589 114.85 68.02 Total Sessions 40879712 741.05 472.79 Total Requests 1140 0.00 0.01 Total pipe 57503 0.00 0.67 Total pass 284136 11.98 3.29 Total fetch 4563105931 83639.24 52774.63 Total header bytes 136056072061 2199249.46 1573557.46 Total body bytes And here's top, notice that gzip'ing the output of varnishlog is a quite expensive activity :-) last pid: 5094; load averages: 0.43, 0.35, 0.31 up 33+23:54:42 14:18:09 74 processes: 1 running, 73 sleeping CPU states: 5.0% user, 0.0% nice, 3.3% system, 1.7% interrupt, 90.0% idle Mem: 796M Active, 2438M Inact, 272M Wired, 168M Cache, 214M Buf, 5400K Free Swap: 4096M Total, 560K Used, 4095M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 98522 varnish 1 -8 0 2844K 964K piperd 0 49:36 3.91% gzip 99174 root 14 20 0 10395M 1469M kserel 1 100:43 0.00% lt-varnishd 98521 varnish 1 8 0 13860K 9056K nanslp 1 4:52 0.00% lt-varnishlog -- 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 des at linpro.no Wed Aug 9 12:36:06 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 09 Aug 2006 14:36:06 +0200 Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl In-Reply-To: <12444.1155123911@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 09 Aug 2006 11:45:11 +0000") References: <12444.1155123911@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > "Dag-Erling Sm?rgrav" writes: > > if (req.http.host ~ "^(www\\.)?vg\\.no$") { > I think we should drop \ substitution in VCL strings in toto. > Instead we could allow HTTP like %xx so that people can get " into > a string. I'd rather have a different syntax for regexps (// instead of ""), if it can be done. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Aug 9 13:16:16 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 13:16:16 +0000 Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl In-Reply-To: Your message of "Wed, 09 Aug 2006 14:36:06 +0200." Message-ID: <12868.1155129376@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> "Dag-Erling Sm=F8rgrav" writes: >> > if (req.http.host ~ "^(www\\.)?vg\\.no$") { >> I think we should drop \ substitution in VCL strings in toto. >> Instead we could allow HTTP like %xx so that people can get " into >> a string. > >I'd rather have a different syntax for regexps (// instead of ""), if >it can be done. Using // sucks for URls, you have to escape all /'s. That's why "..." is better. -- 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 andersb at vgnett.no Wed Aug 9 14:10:32 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 9 Aug 2006 16:10:32 +0200 (CEST) Subject: YAEH! milestone reached! In-Reply-To: <12656.1155126004@critter.freebsd.dk> References: <12656.1155126004@critter.freebsd.dk> Message-ID: <1356.193.213.34.102.1155132632.squirrel@denise.vg.no> > > I know this isn't an official milestone, but for me personally it is > a major milestone: we've run for 24h continously. > > Yah! Wohoo! Nice! I see that we have 19 syscalls (including the 2 to actually measure it) per request. Thats really, really, really nice. Great work. Seems we are stable soon then. Anders Berg From des at linpro.no Wed Aug 9 14:56:52 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Wed, 09 Aug 2006 16:56:52 +0200 Subject: YAEH! milestone reached! References: <12656.1155126004@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I know this isn't an official milestone, but for me personally it is > a major milestone: we've run for 24h continously. Excellent work! > 1d+00:01:04 syscalls: 14634.145/s 19.775/req How do you count syscalls? these fields don't show up on my varnishstat output... DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Wed Aug 9 15:40:27 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 09 Aug 2006 15:40:27 +0000 Subject: YAEH! milestone reached! In-Reply-To: Your message of "Wed, 09 Aug 2006 16:56:52 +0200." Message-ID: <13341.1155138027@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> I know this isn't an official milestone, but for me personally it is >> a major milestone: we've run for 24h continously. > >Excellent work! > >> 1d+00:01:04 syscalls: 14634.145/s 19.775/req > >How do you count syscalls? these fields don't show up on my >varnishstat output... It's just a quick hack I did to test it. + ss = sizeof sc; + scr = sysctlbyname("vm.stats.sys.v_syscall", &sc, &ss, NULL, 0); -- 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 andersb at vgnett.no Wed Aug 9 20:54:33 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 9 Aug 2006 22:54:33 +0200 (CEST) Subject: r778 - in trunk/varnish-cache: bin/varnishd include lib/libvcl In-Reply-To: <12868.1155129376@critter.freebsd.dk> References: Your message of "Wed, 09 Aug 2006 14:36:06 +0200." <12868.1155129376@critter.freebsd.dk> Message-ID: <1381.193.213.34.102.1155156873.squirrel@denise.vg.no> > In message , Dag-Erling > Sm?rgrav writes: >>"Poul-Henning Kamp" writes: >>> "Dag-Erling Sm=F8rgrav" writes: >>> > if (req.http.host ~ "^(www\\.)?vg\\.no$") { >>> I think we should drop \ substitution in VCL strings in toto. >>> Instead we could allow HTTP like %xx so that people can get " into >>> a string. >> >>I'd rather have a different syntax for regexps (// instead of ""), if >>it can be done. > > Using // sucks for URls, you have to escape all /'s. I have to agree with Poul-Henning on this one, even if I am used to using // myself (perl school). For some reason escaping is hard for some people. Anders Berg From andersb at vgnett.no Wed Aug 9 21:28:39 2006 From: andersb at vgnett.no (Anders Berg) Date: Wed, 9 Aug 2006 23:28:39 +0200 (CEST) Subject: r780 - in trunk/varnish-cache: . bin/varnishd Message-ID: <1643.193.213.34.102.1155158919.squirrel@denise.vg.no> DES wrote: >Add an epoll()-based acceptor for Linux 2.6. Simple empirical tests >indicate that epoll() performs significantly better than poll() (less CPU >usage). For sure. epoll() is O(1), poll is FAR from it. http://bulk.fefe.de/scalability/ Also noticed movement again in the linux camp about scalable stuff (I asume you guys have seen the Zero-Copy Network discussion between the camps :)) Here are some good stuff: Old, but useful: http://marc.theaimsgroup.com/?l=linux-kernel&m=103607925020720&w=2 http://lwn.net/Articles/172844/ Some FreeBSD bashing but useful: http://lkml.org/lkml/2006/7/9/82 Again the same (with real world testing): http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent NAIO: http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio Linux kernel discussion for the above mentioned stuff: http://thread.gmane.org/gmane.linux.network/37595/focus=37673 Paper on Zero-Copy NAIO: http://people.redhat.com/drepper/newni.pdf and article: http://lwn.net/Articles/192410/ Some of this is good work and major improvements if they ever get adopted. Anders Berg From des at linpro.no Thu Aug 10 07:00:02 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 09:00:02 +0200 Subject: r780 - in trunk/varnish-cache: . bin/varnishd References: <1643.193.213.34.102.1155158919.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > Dag-Erling Sm?rgrav writes: > > Add an epoll()-based acceptor for Linux 2.6. Simple empirical > > tests indicate that epoll() performs significantly better than > > poll() (less CPU usage). > For sure. epoll() is O(1), poll is FAR from it. Even so, the behaviour I was seeing was far worse than I expected: CPU usage was pegged at 100% (almost all of it in system time) even with no clients; strace confirmed that nothing else was going on than a ping from the management process every three seconds. I don't know if this has anything to do with passing in bogus pollfds (with fd = -1); a colleague looked through the kernel source while I was working on the epoll code and could not find anything to indicate that this should be a problem. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 10 07:11:27 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 07:11:27 +0000 Subject: r780 - in trunk/varnish-cache: . bin/varnishd In-Reply-To: Your message of "Thu, 10 Aug 2006 09:00:02 +0200." Message-ID: <16474.1155193887@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Even so, the behaviour I was seeing was far worse than I expected: CPU >usage was pegged at 100% (almost all of it in system time) even with >no clients; strace confirmed that nothing else was going on than a >ping from the management process every three seconds. Did it stay in the kernel or did it do a lot of system calls ? What was the return value of poll(2) ? The timeout argument is probably more suspect than the fd. >I don't know if >this has anything to do with passing in bogus pollfds (with fd = -1); >a colleague looked through the kernel source while I was working on >the epoll code and could not find anything to indicate that this >should be a problem. fd = -1 is specifically allowed: If the value of fd is less than 0, events shall be ignored, and revents shall be set to 0 in that entry on return from poll(). Poll(2) suffers from the same discrepancy as select(2): you have to do the entire setup on every call, no state is retained in the kernel. 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 Thu Aug 10 07:14:38 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 07:14:38 +0000 Subject: r780 - in trunk/varnish-cache: . bin/varnishd In-Reply-To: Your message of "Thu, 10 Aug 2006 07:11:27 GMT." <16474.1155193887@critter.freebsd.dk> Message-ID: <16489.1155194078@critter.freebsd.dk> In message <16474.1155193887 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra >v?= writes: >Poll(2) suffers from the same discrepancy as select(2): you have s/discrepancy/inefficiency/ (I'm not fully awake yet) >to do the entire setup on every call, no state is retained in the >kernel. -- 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 des at linpro.no Thu Aug 10 07:18:29 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 09:18:29 +0200 Subject: r780 - in trunk/varnish-cache: . bin/varnishd In-Reply-To: <16474.1155193887@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 10 Aug 2006 07:11:27 +0000") References: <16474.1155193887@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Did it stay in the kernel or did it do a lot of system calls ? It stayed in the kernel for three seconds every time. > What was the return value of poll(2) ? 1 DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 10 07:23:02 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 07:23:02 +0000 Subject: r780 - in trunk/varnish-cache: . bin/varnishd In-Reply-To: Your message of "Thu, 10 Aug 2006 09:18:29 +0200." Message-ID: <16537.1155194582@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Did it stay in the kernel or did it do a lot of system calls ? > >It stayed in the kernel for three seconds every time. > >> What was the return value of poll(2) ? > >1 That sounds weird... (BTW: I'm not sure how much I'll get done today either, our cat has fallen sick and we're expecting the Vet to give us bad news) -- 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 andersb at vgnett.no Thu Aug 10 07:30:19 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 09:30:19 +0200 (CEST) Subject: r780 - in trunk/varnish-cache: . bin/varnishd In-Reply-To: <16537.1155194582@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 09:18:29 +0200." <16537.1155194582@critter.freebsd.dk> Message-ID: <1429.193.213.34.102.1155195019.squirrel@denise.vg.no> > In message , Dag-Erling > =?iso-8859-1?Q?Sm=F8rgra > v?= writes: >>"Poul-Henning Kamp" writes: >>> Did it stay in the kernel or did it do a lot of system calls ? >> >>It stayed in the kernel for three seconds every time. >> >>> What was the return value of poll(2) ? >> >>1 > > That sounds weird... > > > (BTW: I'm not sure how much I'll get done today either, our cat has > fallen sick and we're expecting the Vet to give us bad news) Sure. Good luck with the vet. Anders Berg From des at linpro.no Thu Aug 10 07:45:28 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 09:45:28 +0200 Subject: pass_chunked() Message-ID: The following URL shows up blank: http://www.dagbladet.no/kultur/2006/08/10/473490.html the log shows: 01 31 0 Debug [INCOMPLETE AT: pass_chunked(86)] Is the following patch sufficient, or is it more complicated than I think? === bin/varnishd/cache_pass.c ================================================================== --- bin/varnishd/cache_pass.c (revision 30982) +++ bin/varnishd/cache_pass.c (local) @@ -83,8 +83,9 @@ u = strtoul(p, &q, 16); if (q == NULL || (*q != '\n' && *q != '\r')) { - INCOMPL(); - /* XXX: move bp to buf start, get more */ + bp = p = buf; + be = buf + sizeof buf; + continue; } if (*q == '\r') q++; DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From andersb at vgnett.no Thu Aug 10 07:52:34 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 09:52:34 +0200 (CEST) Subject: FYI 10.08.2006 Message-ID: <2055.193.69.165.4.1155196354.squirrel@denise.vg.no> Bumped weight from 5 to 10. Anders Berg From phk at phk.freebsd.dk Thu Aug 10 07:52:53 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 07:52:53 +0000 Subject: pass_chunked() In-Reply-To: Your message of "Thu, 10 Aug 2006 09:45:28 +0200." Message-ID: <16645.1155196373@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >The following URL shows up blank: > >http://www.dagbladet.no/kultur/2006/08/10/473490.html > >the log shows: > >01 31 0 Debug [INCOMPLETE AT: pass_chunked(86)] > >Is the following patch sufficient, or is it more complicated than I >think? Good question, if you can reproduce it would be nice to know what the string looks like. I guess we could also encounter a string like: "83823 \n" so we should probably allow for SP and TAB in *q also. -- 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 Thu Aug 10 07:58:36 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 07:58:36 +0000 Subject: FYI 10.08.2006 In-Reply-To: Your message of "Thu, 10 Aug 2006 09:52:34 +0200." <2055.193.69.165.4.1155196354.squirrel@denise.vg.no> Message-ID: <16683.1155196716@critter.freebsd.dk> In message <2055.193.69.165.4.1155196354.squirrel at denise.vg.no>, "Anders Berg" writes: >Bumped weight from 5 to 10. Ok, I'm not monitoring it right now, my ssh sessions died, is it still running or is DES running 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 andersb at vgnett.no Thu Aug 10 08:01:35 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 10:01:35 +0200 (CEST) Subject: FYI 10.08.2006 In-Reply-To: <16683.1155196716@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 09:52:34 +0200." <2055.193.69.165.4.1155196354.squirrel@denise.vg.no> <16683.1155196716@critter.freebsd.dk> Message-ID: <2074.193.69.165.4.1155196895.squirrel@denise.vg.no> > In message <2055.193.69.165.4.1155196354.squirrel at denise.vg.no>, "Anders > Berg" > writes: > >>Bumped weight from 5 to 10. > > Ok, I'm not monitoring it right now, my ssh sessions died, is it still > running or is DES running it ? [andersb at c21 ~/work/svn/varnish/varnish-cache/bin/varnishncsa]$ ps aux|grep screen andersb 11564 0.0 0.0 5936 1308 p0 S+ 10:00AM 0:00.00 grep screen [andersb at c21 ~/work/svn/varnish/varnish-cache/bin/varnishncsa]$ ps aux|grep varnishd root 10551 0.0 17.9 10571972 720076 ?? S 5:40AM 17:23.91 lt-varnishd: Varnish-Chld (lt-varnishd) Ab > -- > 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 des at linpro.no Thu Aug 10 08:51:32 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 10:51:32 +0200 Subject: pass_chunked() In-Reply-To: <16645.1155196373@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 10 Aug 2006 07:52:53 +0000") References: <16645.1155196373@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Good question, if you can reproduce it would be nice to know what > the string looks like. 100% reproducable. I've found several bugs in pass_chunked(). > I guess we could also encounter a string like: > > "83823 \n" > > so we should probably allow for SP and TAB in *q also. RFC2616 does not allow it, and I've never encountered it with libfetch. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 10 08:53:05 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 08:53:05 +0000 Subject: pass_chunked() In-Reply-To: Your message of "Thu, 10 Aug 2006 10:51:32 +0200." Message-ID: <16939.1155199985@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Good question, if you can reproduce it would be nice to know what >> the string looks like. > >100% reproducable. I've found several bugs in pass_chunked(). I'm not surprised :-) It's a very tricky piece of code to write efficiently. It may not be worth the effort to try. -- 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 des at linpro.no Thu Aug 10 09:14:49 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 11:14:49 +0200 Subject: pass_chunked() References: <16939.1155199985@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Dag-Erling Sm?rgrav writes: > > 100% reproducable. I've found several bugs in pass_chunked(). > I'm not surprised :-) OK, here's what I found: > static int > pass_chunked(struct sess *sp, int fd, struct http *hp) > { > int i, j; > char *b, *q, *e; > char *p; > unsigned u; > char buf[PASS_BUFSIZ]; > char *bp, *be; > > i = fcntl(fd, F_GETFL); /* XXX ? */ > i &= ~O_NONBLOCK; > i = fcntl(fd, F_SETFL, i); > > bp = buf; > be = buf + sizeof buf; > p = buf; > while (1) { > i = http_Read(hp, fd, bp, be - bp); > i = read(fd, bp, be - bp); duplicate read, and we discard the data from the first read > assert(i > 0); wrong - we may still have data in our buffer which needs processing - in fact, this is almost always the case at the end of the document > bp += i; > /* buffer valid from p to bp */ > > u = strtoul(p, &q, 16); > if (q == NULL || (*q != '\n' && *q != '\r')) { > INCOMPL(); > /* XXX: move bp to buf start, get more */ easy enough to implement - memmove(), adjust pointers, continue > } > if (*q == '\r') > q++; > assert(*q == '\n'); > q++; > if (u == 0) > break; > > sp->wrk->acct.bodybytes += WRK_Write(sp->wrk, p, q - p); > > p = q; > > while (u > 0) { > j = u; > if (bp == p) { > bp = p = buf; > break; > } > if (bp - p < j) > j = bp - p; > sp->wrk->acct.bodybytes += WRK_Write(sp->wrk, p, j); > p += j; > u -= j; > } OK so far... > while (u > 0) { > if (http_GetTail(hp, u, &b, &e)) { > j = e - b; > sp->wrk->acct.bodybytes += > WRK_Write(sp->wrk, q, j); > u -= j; > } else > break; > } Can't see the point of this loop > if (WRK_Flush(sp->wrk)) > vca_close_session(sp, "remote closed"); > while (u > 0) { > j = u; > if (j > sizeof buf) > j = sizeof buf; > i = read(fd, buf, j); should be http_Read() > assert(i > 0); > sp->wrk->acct.bodybytes += WRK_Write(sp->wrk, buf, i); > u -= i; > if (WRK_Flush(sp->wrk)) > vca_close_session(sp, "remote closed"); > } this loop should be merged with the previous one. > } > return (0); > } DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Thu Aug 10 09:16:34 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 11:16:34 +0200 Subject: pass_chunked() References: <16939.1155199985@critter.freebsd.dk> Message-ID: des at linpro.no (Dag-Erling Sm?rgrav) writes: > OK, here's what I found: forgot one - >> u = strtoul(p, &q, 16); >> if (q == NULL || (*q != '\n' && *q != '\r')) { >> INCOMPL(); >> /* XXX: move bp to buf start, get more */ > > easy enough to implement - memmove(), adjust pointers, continue > >> } >> if (*q == '\r') >> q++; >> assert(*q == '\n'); >> q++; >> if (u == 0) >> break; this is also wrong - we break the loop before sending the final 0-length chunk. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 10 09:24:57 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 09:24:57 +0000 Subject: pass_chunked() In-Reply-To: Your message of "Thu, 10 Aug 2006 11:14:49 +0200." Message-ID: <17162.1155201897@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Dag-Erling Sm?rgrav writes: >> > 100% reproducable. I've found several bugs in pass_chunked(). >> I'm not surprised :-) > >OK, here's what I found: By all means fix. -- 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 des at linpro.no Thu Aug 10 09:35:12 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 10 Aug 2006 11:35:12 +0200 Subject: pass_chunked() References: <16939.1155199985@critter.freebsd.dk> Message-ID: We also seem to forget to tell the client that we are sending chunked data. Any idea why Transfer-Encoding doesn't get copied from the backend response to the client response? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 10 09:41:13 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 09:41:13 +0000 Subject: pass_chunked() In-Reply-To: Your message of "Thu, 10 Aug 2006 11:35:12 +0200." Message-ID: <17218.1155202873@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >We also seem to forget to tell the client that we are sending chunked >data. Any idea why Transfer-Encoding doesn't get copied from the >backend response to the client response? Because Transfer-Enconding is a link state header. We should build our own. -- 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 andersb at vgnett.no Thu Aug 10 18:36:42 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 20:36:42 +0200 (CEST) Subject: Varnish 0.9 released In-Reply-To: References: Message-ID: <1951.193.213.34.102.1155235002.squirrel@denise.vg.no> > We are proud to announce the release of Varnish 0.9, the first alpha > release of the Varnish high-performance HTTP accelerator. > > The source tarball can be obtained from SourceForge: > > http://sf.net/project/showfiles.php?group_id=155816 > > The following Wiki page provides instructions for building and testing > Varnish: > > http://varnish.projects.linpro.no/wiki/AlphaReadme > > Please direct any technical questions to the Varnish development > mailing list, . Great! A downloadable :) Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-announce mailing list > varnish-announce at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-announce > > From andersb at vgnett.no Thu Aug 10 19:08:22 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 21:08:22 +0200 (CEST) Subject: Something fishy Message-ID: <2152.193.69.165.4.1155236902.squirrel@denise.vg.no> Hi, I have been noticing a weird behavior the last couple of days (I first noticed this about a week ago). I have been hoping to find the error, but it has been so random. When I sometimes start up IE I get an old frontpage of VG Nett. With old I mean the last frontpage I had up in my IE. If that was 1 day ago, I get a 1 day old frontpage. I am not sure it's Varnish that does this, but I can't see any obvious errors or changes on any of the Squid's either. Today I got an email from work that I am not the only one noticing this. I find the whole thing weird, and I can't see no other reason than my IE sends a IMS request and gets an answer that nothing is changed, or something to that effect. A quick study of HEAD's I have done shows only small differences from Squid and Varnish: (andersb) fw:andersb $ HEAD http://www.vg.no 200 OK Cache-Control: max-age=900 Connection: close Date: Thu, 10 Aug 2006 18:38:23 GMT Accept-Ranges: bytes Age: 43 ETag: W/"2b400e-28af1-44db7d1e" Server: Apache/1.3.27 (Unix) Content-Length: 166641 Content-Type: text/html; charset=iso-8859-1 Expires: Thu, 10 Aug 2006 18:53:23 GMT Last-Modified: Thu, 10 Aug 2006 18:38:22 GMT Client-Date: Thu, 10 Aug 2006 18:39:06 GMT Client-Peer: 193.69.165.21:80 Client-Response-Num: 1 X-Cache: HIT from www.vg.no X-Cache: HIT from www.vg.no (andersb) fw:andersb $ HEAD http://www.vg.no 200 OK Connection: close Date: Thu, 10 Aug 2006 18:37:27 GMT Via: 1.1 varnish Age: 100 ETag: "2b400e-288d5-44db7c55" Server: Apache/1.3.27 (Unix) Content-Length: 166101 Content-Type: text/html; charset=iso-8859-1 Expires: Thu, 10 Aug 2006 18:52:27 GMT Last-Modified: Thu, 10 Aug 2006 18:35:01 GMT Client-Date: Thu, 10 Aug 2006 18:39:07 GMT Client-Peer: 193.69.165.21:80 Client-Response-Num: 1 X-Varnish: 2002714009 2002603403 The only differences I see are these (except that the doc's are somewhat different because of different timeouts): Cache-Control: max-age=900 on Squid, no header like this on Varnish. The next one is weird: ETag: W/"2b400e-28af1-44db7d1e" on Squid ETag: "2b400e-288d5-44db7c55" on Varnish. Every ETag from Squid has a W/ before the tag. This is new to me, and I don't know the implications. It's obviously consistent across all Squid's. Accept-Ranges: bytes on Squid but none on Varnish, but that's not whats causing this. Anyone care to guess? Anders Berg From andersb at vgnett.no Thu Aug 10 19:20:36 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 21:20:36 +0200 (CEST) Subject: Something fishy In-Reply-To: <2152.193.69.165.4.1155236902.squirrel@denise.vg.no> References: <2152.193.69.165.4.1155236902.squirrel@denise.vg.no> Message-ID: <2177.193.69.165.4.1155237636.squirrel@denise.vg.no> > Hi, > > I have been noticing a weird behavior the last couple of days (I first > noticed this about a week ago). I have been hoping to find the error, but > it has been so random. Weight 1 until we have some more data about the error. Anders Berg From phk at phk.freebsd.dk Thu Aug 10 19:29:37 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 19:29:37 +0000 Subject: Something fishy In-Reply-To: Your message of "Thu, 10 Aug 2006 21:08:22 +0200." <2152.193.69.165.4.1155236902.squirrel@denise.vg.no> Message-ID: <19529.1155238177@critter.freebsd.dk> In message <2152.193.69.165.4.1155236902.squirrel at denise.vg.no>, "Anders Berg" writes: >(andersb) fw:andersb $ HEAD http://www.vg.no >200 OK >Cache-Control: max-age=900 >Connection: close >Date: Thu, 10 Aug 2006 18:38:23 GMT >Accept-Ranges: bytes >Age: 43 >ETag: W/"2b400e-28af1-44db7d1e" >Server: Apache/1.3.27 (Unix) >Content-Length: 166641 >Content-Type: text/html; charset=iso-8859-1 >Expires: Thu, 10 Aug 2006 18:53:23 GMT >Last-Modified: Thu, 10 Aug 2006 18:38:22 GMT >Client-Date: Thu, 10 Aug 2006 18:39:06 GMT >Client-Peer: 193.69.165.21:80 >Client-Response-Num: 1 >X-Cache: HIT from www.vg.no >X-Cache: HIT from www.vg.no > >(andersb) fw:andersb $ HEAD http://www.vg.no >200 OK >Connection: close >Date: Thu, 10 Aug 2006 18:37:27 GMT >Via: 1.1 varnish >Age: 100 >ETag: "2b400e-288d5-44db7c55" >Server: Apache/1.3.27 (Unix) >Content-Length: 166101 >Content-Type: text/html; charset=iso-8859-1 >Expires: Thu, 10 Aug 2006 18:52:27 GMT >Last-Modified: Thu, 10 Aug 2006 18:35:01 GMT >Client-Date: Thu, 10 Aug 2006 18:39:07 GMT >Client-Peer: 193.69.165.21:80 >Client-Response-Num: 1 >X-Varnish: 2002714009 2002603403 > >The only differences I see are these (except that the doc's are somewhat >different because of different timeouts): > >Cache-Control: max-age=900 on Squid, no header like this on Varnish. This shouldn't matter when the object has an Expires header. I guess if you computers time were off, we would be more safe with an max-age as well. Create a ticket on it. >The next one is weird: > >ETag: W/"2b400e-28af1-44db7d1e" on Squid >ETag: "2b400e-288d5-44db7c55" on Varnish. This is whatever we got from the backend, Varnish does not touch ETag in anyway. >Every ETag from Squid has a W/ before the tag. This is new to me, and I >don't know the implications. It's obviously consistent across all Squid's. W/ means weak. I tried to wrap my head around why they wanted that in the RFC and failed. It was probably a good idea to somebody. >Accept-Ranges: bytes on Squid but none on Varnish, but that's not whats >causing this. Correct, we don't accept ranges. -- 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 andersb at vgnett.no Thu Aug 10 19:36:33 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 21:36:33 +0200 (CEST) Subject: Something fishy In-Reply-To: <19529.1155238177@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 21:08:22 +0200." <2152.193.69.165.4.1155236902.squirrel@denise.vg.no> <19529.1155238177@critter.freebsd.dk> Message-ID: <2220.193.69.165.4.1155238593.squirrel@denise.vg.no> > In message <2152.193.69.165.4.1155236902.squirrel at denise.vg.no>, "Anders > Berg" > writes: >> >>Cache-Control: max-age=900 on Squid, no header like this on Varnish. > > This shouldn't matter when the object has an Expires header. > > I guess if you computers time were off, we would be more safe with > an max-age as well. Mine is ntp updated. > Create a ticket on it. > >>The next one is weird: >> >>ETag: W/"2b400e-28af1-44db7d1e" on Squid >>ETag: "2b400e-288d5-44db7c55" on Varnish. > > This is whatever we got from the backend, Varnish does not touch > ETag in anyway. Okay, the output I got was from a #HEAD www.vg.no 80 command in FreeBSD 6 when I telnet I don't get it. >>Every ETag from Squid has a W/ before the tag. This is new to me, and I >>don't know the implications. It's obviously consistent across all >> Squid's. > > W/ means weak. I tried to wrap my head around why they wanted that > in the RFC and failed. It was probably a good idea to somebody. > Okay, probably not the reason then. >>Accept-Ranges: bytes on Squid but none on Varnish, but that's not whats >>causing this. > > Correct, we don't accept ranges. Jepp. So we can write that one off. To give some more data on this problem I just now did a HEAD from all machines manually: (andersb) fw:andersb $ telnet 10.0.2.2 80 Trying 10.0.2.2... Connected to blade2. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 347 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.3 80 Trying 10.0.2.3... Connected to blade3. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:23 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:23 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 Age: 333 X-Cache: HIT from www.vg.no Via: 1.0 cache3.c.vgnett.no:80 (squid/2.6.RC1-20060621) Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.4 80 Trying 10.0.2.4... Connected to blade4. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 359 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.12 80 Trying 10.0.2.12... Connected to blade12. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 364 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ (andersb) fw:andersb $ telnet 10.0.2.13 80 Trying 10.0.2.13... Connected to blade13. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 370 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.17 80 Trying 10.0.2.17... Connected to blade17. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 376 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ (andersb) fw:andersb $ telnet 10.0.2.18 80 Trying 10.0.2.18... Connected to blade18. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 380 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.19 80 Trying 10.0.2.19... Connected to blade19. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 385 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.20 80 Trying 10.0.2.20... Connected to blade20. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 390 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.21 80 Trying 10.0.2.21... Connected to 10.0.2.21. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Thu, 10 Aug 2006 19:27:36 GMT Server: Apache/1.3.27 (Unix) Expires: Thu, 10 Aug 2006 19:42:36 GMT Last-Modified: Thu, 10 Aug 2006 19:25:01 GMT ETag: "2b400e-27703-44db880d" Content-Type: text/html; charset=iso-8859-1 Content-Length: 161539 X-Varnish: 2005394511 Age: 0 Via: 1.1 varnish Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.28 80 Trying 10.0.2.28... Connected to blade28. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 399 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. (andersb) fw:andersb $ telnet 10.0.2.29 80 Trying 10.0.2.29... Connected to blade29. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Thu, 10 Aug 2006 19:21:02 GMT Server: Apache/1.3.27 (Unix) Cache-Control: max-age=900 Expires: Thu, 10 Aug 2006 19:36:02 GMT Last-Modified: Thu, 10 Aug 2006 19:20:01 GMT ETag: "2b400e-276f9-44db86e1" Accept-Ranges: bytes Content-Length: 161529 Content-Type: text/html; charset=iso-8859-1 X-Cache: HIT from www.vg.no Age: 405 X-Cache: HIT from www.vg.no Connection: close Connection closed by foreign host. ************* All the Squid's behave the same... Oter's mom actually gets this problem all time and she has Firefox :) Anders Berg > -- > 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 Thu Aug 10 19:41:47 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 19:41:47 +0000 Subject: Something fishy In-Reply-To: Your message of "Thu, 10 Aug 2006 21:36:33 +0200." <2220.193.69.165.4.1155238593.squirrel@denise.vg.no> Message-ID: <19645.1155238907@critter.freebsd.dk> In message <2220.193.69.165.4.1155238593.squirrel at denise.vg.no>, "Anders Berg" writes: >All the Squid's behave the same... Oter's mom actually gets this problem >all time and she has Firefox :) There is a browser setting for how often the browser checks it's local cache, from memory I think you can select once per session every time never or something like it. Could you try to see if that has anything to do with it ? There is nothing I can do in Varnish if the browser doesn't ask. I guess one could conceiveably write a browser to ignore Expires: but respec max-age, but that sounds wicked to me... -- 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 andersb at vgnett.no Thu Aug 10 20:01:32 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 22:01:32 +0200 (CEST) Subject: Something fishy In-Reply-To: <19645.1155238907@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 21:36:33 +0200." <2220.193.69.165.4.1155238593.squirrel@denise.vg.no> <19645.1155238907@critter.freebsd.dk> Message-ID: <2234.193.69.165.4.1155240092.squirrel@denise.vg.no> > In message <2220.193.69.165.4.1155238593.squirrel at denise.vg.no>, "Anders > Berg" > writes: > >>All the Squid's behave the same... Oter's mom actually gets this problem >>all time and she has Firefox :) > > There is a browser setting for how often the browser checks it's > local cache, from memory I think you can select > once per session > every time > never > or something like it. > > Could you try to see if that has anything to do with it ? Mine, Jo Christian's (oter), Geir Terje Ruud (Newseditor) and Live Bente (frontpage worker at VG) browser's haven't changed settings, this problem is "new" in a sense that I first encountered it a week ago and thought at first that something was amiss at my own PC (windows works in mystrious ways), and I have had it a couple of times since. Just now I learned that we have been receiving mails about this, and the abovementioned crew have all experienced it. I could try to find a more specific date of first time occurence if that would help. I suspect Varnish for some reason, since this has become "more of a problem" the last days and it topped today, this can be seen related to weight 10 in my mind. Anders Berg From andersb at vgnett.no Thu Aug 10 20:04:39 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 22:04:39 +0200 (CEST) Subject: Something fishy In-Reply-To: <19645.1155238907@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 21:36:33 +0200." <2220.193.69.165.4.1155238593.squirrel@denise.vg.no> <19645.1155238907@critter.freebsd.dk> Message-ID: <2250.193.69.165.4.1155240279.squirrel@denise.vg.no> > In message <2220.193.69.165.4.1155238593.squirrel at denise.vg.no>, "Anders > Berg" > writes: > >>All the Squid's behave the same... Oter's mom actually gets this problem >>all time and she has Firefox :) Here is one correspondance we had: ********* Han her rapporterer n? i kveld at ting ser ut til ? ordne seg. -oter- ------ Forwarded Message From: Jon Inge Teigland Date: Thu, 10 Aug 2006 21:58:04 +0200 To: 'Jo Christian Oterhals' Subject: SV: SV: Nettutgaven N? er VG sida helt i orden. N? er Kyv?g med tanksene sine byttet ut med at 24 er arrestert? - alts? helt ferske nyheter. Mulig det er serveren som er litt lunefull da kanskje. Mvh JI Teigland Fra: Jo Christian Oterhals [mailto:oter at vg.no] Sendt: 10. august 2006 21:52 Til: Jon Inge Teigland Emne: Re: SV: Nettutgaven Det kan ogs? v?re mulig at jeg har v?rt p? villspor. N? har flere enn deg rapportert det samme, og de rapporterer ulike utgaver av forsiden som gammel. Dermed synes det som om en av serverne v?re har ?hengt? seg noe. Skjer dette hver eneste gang, eller kun innimellom? Kunne du ogs? sjekket igjen i kveld eller i morgen og sett om du opplever det samme fremdeles? Jo Christian Oterhals, VG Multimedia On 10-08-06 21:46, "Jon Inge Teigland" wrote: Takk for svar. Skal sette kona p? saken. Det er hun som er dataeksperten her. At samme problemet dukker opp p? jobb skyldes nok en brannmur ? ja. Mulig at det er samme problemet vi har hjemme.. MVH JI Teigland Fra: Jo Christian Oterhals [mailto:Jo.Christian.Oterhals at vg.no] Sendt: 10. august 2006 15:56 Til: jon-inge at online.no Emne: SV: Nettutgaven Nei, vi jobber jevnt og trutt vi og har nok oppdatert noen hundre ganger siden det. For ? finne ut hva problemet kan v?re for deg, har jeg noen sp?rsm?l: Har du installert noen form for nett-akselleringssoftware, for eksempel Google sin, eller kan det v?re at du sitter bak en brannmur p? en skole, en bedrift eller lignende, som har installert noe lignende? Med vennlig hilsen Jo Christian Oterhals VG Multimedia Fra: Jon Inge Teigland [mailto:jon-inge at online.no] Sendt: to 10.08.2006 14:02 Til: Torry Pedersen Emne: Nettutgaven er det bare jeg som er s? uheldig at jeg f?r opp VG sin nettutgave fra 01.08.06? G?r inn via sol.no. Bare sp?r. Cruser innom VG noen ganger pr. dag, og begynner ? bli "lei av" ? lese om Kyv?g som forsvarer tanks p? Norway cup.... ----- Denne tilbakemeldingen er sendt til deg via VG NETTs websider. ----- Sendt av: Jon Inge Teigland IP-adresse: 83.108.148.160 e-post: jon-inge at online.no telefon: 1 ----- ***************************************************************** Denne fotnoten bekrefter at denne e-postmeldingen ble skannet av MailSweeper og funnet fri for virus. ***************************************************************** This footnote confirms that this email message has been swept by MailSweeper for the presence of computer viruses. ***************************************************************** ------ End of Forwarded Message Anders Berg From phk at phk.freebsd.dk Thu Aug 10 20:46:25 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 20:46:25 +0000 Subject: Something fishy In-Reply-To: Your message of "Thu, 10 Aug 2006 22:01:32 +0200." <2234.193.69.165.4.1155240092.squirrel@denise.vg.no> Message-ID: <19997.1155242785@critter.freebsd.dk> In message <2234.193.69.165.4.1155240092.squirrel at denise.vg.no>, "Anders Berg" writes: >> local cache, from memory I think you can select >> once per session >> every time >> never >> or something like it. >> >> Could you try to see if that has anything to do with it ? > >Mine, Jo Christian's (oter), Geir Terje Ruud (Newseditor) and Live Bente >(frontpage worker at VG) browser's haven't changed settings, this problem >is "new" [...] yes, I know, but I would still like to know if these settings affect it, as that will indicate what actually happens. >I suspect Varnish for some reason, since this has become "more of a >problem" the last days and it topped today, this can be seen related to >weight 10 in my mind. I agree, but I still need to figure out the cause... -- 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 andersb at vgnett.no Thu Aug 10 20:57:49 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 22:57:49 +0200 (CEST) Subject: Something fishy In-Reply-To: <19997.1155242785@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 22:01:32 +0200." <2234.193.69.165.4.1155240092.squirrel@denise.vg.no> <19997.1155242785@critter.freebsd.dk> Message-ID: <2859.193.69.165.4.1155243469.squirrel@denise.vg.no> > In message <2234.193.69.165.4.1155240092.squirrel at denise.vg.no>, "Anders > Berg" > writes: > >>> local cache, from memory I think you can select >>> once per session >>> every time >>> never >>> or something like it. Mine is set to "Automatic" (default) opposed to: Look for new versions of saved pages: Every time the page is viewed. Every time IE starts. Never. > yes, I know, but I would still like to know if these settings affect > it, as that will indicate what actually happens. "Never" is offline. No need to try that one. "Every time a page is viewed" is cache off I guess. "Every time IE starts." is clear cache between each session. Want me to try any of them? Now weight is 1 so there is less chance of this problem accuring, and it's hard to reproduce (maybe it's triggered if we stopped last seesion on Varnish, and get Varnish the first time we fire browser). On a sidenote, GbE is gonna be tried installed tomorrow, we can direct all traffic to Varnish then, and see what happens. Anders Berg > -- > 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 Thu Aug 10 21:00:58 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 10 Aug 2006 21:00:58 +0000 Subject: Something fishy In-Reply-To: Your message of "Thu, 10 Aug 2006 22:57:49 +0200." <2859.193.69.165.4.1155243469.squirrel@denise.vg.no> Message-ID: <20069.1155243658@critter.freebsd.dk> In message <2859.193.69.165.4.1155243469.squirrel at denise.vg.no>, "Anders Berg" writes: >> In message <2234.193.69.165.4.1155240092.squirrel at denise.vg.no>, "Anders >> Berg" >> writes: >> >>>> local cache, from memory I think you can select >>>> once per session >>>> every time >>>> never >>>> or something like it. > >Mine is set to "Automatic" (default) opposed to: OK, just leave it at that. >On a sidenote, GbE is gonna be tried installed tomorrow, we can direct all >traffic to Varnish then, and see what happens. I need to pick up our cat at the vet tomorrow, but I will try to get the max-age header fixed and I will try to do something about the more trivial cases of backend errors, then probably in the afternoon we can try to hit it if you're ready. -- 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 andersb at vgnett.no Thu Aug 10 21:27:28 2006 From: andersb at vgnett.no (Anders Berg) Date: Thu, 10 Aug 2006 23:27:28 +0200 (CEST) Subject: Something fishy In-Reply-To: <20069.1155243658@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 22:57:49 +0200." <2859.193.69.165.4.1155243469.squirrel@denise.vg.no> <20069.1155243658@critter.freebsd.dk> Message-ID: <3305.193.69.165.4.1155245248.squirrel@denise.vg.no> > In message <2859.193.69.165.4.1155243469.squirrel at denise.vg.no>, "Anders > Berg" > writes: >>> In message <2234.193.69.165.4.1155240092.squirrel at denise.vg.no>, >>> "Anders >>> Berg" >>> writes: >>> >>>>> local cache, from memory I think you can select >>>>> once per session >>>>> every time >>>>> never >>>>> or something like it. >> >>Mine is set to "Automatic" (default) opposed to: > > OK, just leave it at that. Okay. >>On a sidenote, GbE is gonna be tried installed tomorrow, we can direct >> all >>traffic to Varnish then, and see what happens. > > I need to pick up our cat at the vet tomorrow, but I will try to > get the max-age header fixed and I will try to do something about > the more trivial cases of backend errors, then probably in the > afternoon we can try to hit it if you're ready. Sure, good luck. I hope he will be back to his tailchasing in no time :) We have planned installment at 12:30 tomorrow, but if we are able to do it then depends on a few things. Anyway, I'll try to give a ethercap/pcap dump from my machine tomorrow, so we can see how IE really behaves when we fire it up. Anders Berg > -- > 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 ssm at linpro.no Fri Aug 11 05:37:09 2006 From: ssm at linpro.no (Stig Sandbeck Mathisen) Date: Fri, 11 Aug 2006 07:37:09 +0200 Subject: Missing LICENSE for varnish alpha release Message-ID: <7x1wrnj0je.fsf@linpro.no> Looks like the tarball is missing the LICENSE file from http://varnish.projects.linpro.no/svn/trunk/varnish-cache/LICENSE -- Stig Sandbeck Mathisen, Linpro From des at linpro.no Fri Aug 11 06:24:59 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 11 Aug 2006 08:24:59 +0200 Subject: Missing LICENSE for varnish alpha release References: <7x1wrnj0je.fsf@linpro.no> Message-ID: Stig Sandbeck Mathisen writes: > Looks like the tarball is missing the LICENSE file from > http://varnish.projects.linpro.no/svn/trunk/varnish-cache/LICENSE Yes, it needs to be added to EXTRA_DIST. I'll take care of it. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Fri Aug 11 09:31:52 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Aug 2006 09:31:52 +0000 Subject: Varnish 0.9.1 released In-Reply-To: Your message of "Fri, 11 Aug 2006 11:30:35 +0200." Message-ID: <38842.1155288712@critter.freebsd.dk> Have we seen any actual downloads yet ? :-) -- 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 des at linpro.no Fri Aug 11 09:54:38 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Fri, 11 Aug 2006 11:54:38 +0200 Subject: Varnish 0.9.1 released References: <38842.1155288712@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Have we seen any actual downloads yet ? :-) Yes, five so far (possibly including me five minutes ago - I'm not sure the stats are updated in real time) DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Fri Aug 11 09:57:03 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Aug 2006 09:57:03 +0000 Subject: Something fishy In-Reply-To: Your message of "Thu, 10 Aug 2006 23:27:28 +0200." <3305.193.69.165.4.1155245248.squirrel@denise.vg.no> Message-ID: <38991.1155290223@critter.freebsd.dk> In message <3305.193.69.165.4.1155245248.squirrel at denise.vg.no>, "Anders Berg" writes: You should be getting the Cache-control from the backend sent to the client now. Can you try to see if the problem is still there ? -- 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 andersb at vgnett.no Fri Aug 11 10:42:30 2006 From: andersb at vgnett.no (Anders Berg) Date: Fri, 11 Aug 2006 12:42:30 +0200 (CEST) Subject: Something fishy In-Reply-To: <38991.1155290223@critter.freebsd.dk> References: Your message of "Thu, 10 Aug 2006 23:27:28 +0200." <3305.193.69.165.4.1155245248.squirrel@denise.vg.no> <38991.1155290223@critter.freebsd.dk> Message-ID: <2500.193.213.34.102.1155292950.squirrel@denise.vg.no> > In message <3305.193.69.165.4.1155245248.squirrel at denise.vg.no>, "Anders > Berg" > writes: > > You should be getting the Cache-control from the backend sent to the > client now. Can you try to see if the problem is still there ? Sure. I will set weight to 10, and tell people to notify me if the problem consists. I have downloaded a packetcapture program, and can send some debug code on the IE headers if we need some. Anders Berg > -- > 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 andersb at vgnett.no Fri Aug 11 10:45:35 2006 From: andersb at vgnett.no (Anders Berg) Date: Fri, 11 Aug 2006 12:45:35 +0200 (CEST) Subject: GbE equipment In-Reply-To: <1860.193.69.165.4.1154988807.squirrel@denise.vg.no> References: <1860.193.69.165.4.1154988807.squirrel@denise.vg.no> Message-ID: <2758.193.213.34.102.1155293135.squirrel@denise.vg.no> > Hi, > > I am receiving the GbE equipment on friday most probably. > It should be a quick job to install it when it's here. So I look forward > to test Varnish with full traffic next week :) > > For maximum traffic, we need to serve www.vg.no and flash.vg.no (flash > files mostly) at the same time. If we do that, traffic in the 400-500Mbit > range should be normal on daytime. We have planned to install the GbE equip today, but we are not sure if and when we are gonna do it (we have to wait for some other equipment to arrive first). When/If we install GbE, we have to take down c21, so don't be surprised if we suddenly boot it down. I guess ppl are not working directly on it, so that should be no problem Anders Berg > Anders Berg > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From phk at phk.freebsd.dk Fri Aug 11 10:51:44 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Aug 2006 10:51:44 +0000 Subject: GbE equipment In-Reply-To: Your message of "Fri, 11 Aug 2006 12:45:35 +0200." <2758.193.213.34.102.1155293135.squirrel@denise.vg.no> Message-ID: <50293.1155293504@critter.freebsd.dk> In message <2758.193.213.34.102.1155293135.squirrel at denise.vg.no>, "Anders Berg " writes: >When/If we install GbE, we have to take down c21, so don't be surprised if >we suddenly boot it down. I guess ppl are not working directly on it, so >that should be no problem You just pull it when you have to. -- 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 Aug 11 11:27:55 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Aug 2006 11:27:55 +0000 Subject: VCL syntax change Message-ID: <61100.1155295675@critter.freebsd.dk> I have changned the VCL syntax for strings so that regexps on URLs do not become a nightmarish maze of back-slashes. We recognize %xx escapes now, but until we know a use for them, it will balk at any that turns into a control character. -- 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 Aug 11 12:39:04 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 11 Aug 2006 12:39:04 +0000 Subject: IRC Message-ID: <64467.1155299944@critter.freebsd.dk> I'm on the irc channel now if we need to talk -- 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 Sun Aug 13 15:25:08 2006 From: anders at fupp.net (Anders Nordby) Date: Sun, 13 Aug 2006 17:25:08 +0200 Subject: PR Message-ID: <20060813152508.GB9921@totem.fix.no> Hi, How come Varnish is not listed on freshmeat.net? Announcing releases there as well could help bring some more publicity for the project. Cheers, -- Anders. From phk at phk.freebsd.dk Sun Aug 13 15:44:08 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 13 Aug 2006 15:44:08 +0000 Subject: PR In-Reply-To: Your message of "Sun, 13 Aug 2006 17:25:08 +0200." <20060813152508.GB9921@totem.fix.no> Message-ID: <7964.1155483848@critter.freebsd.dk> In message <20060813152508.GB9921 at totem.fix.no>, Anders Nordby writes: >Hi, > >How come Varnish is not listed on freshmeat.net? Announcing releases >there as well could help bring some more publicity for the project. next release, not quite yet... -- 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 andersb at vgnett.no Sun Aug 13 16:16:03 2006 From: andersb at vgnett.no (Anders Berg) Date: Sun, 13 Aug 2006 18:16:03 +0200 (CEST) Subject: PR In-Reply-To: <20060813152508.GB9921@totem.fix.no> References: <20060813152508.GB9921@totem.fix.no> Message-ID: <1756.193.213.34.102.1155485763.squirrel@denise.vg.no> > Hi, > > How come Varnish is not listed on freshmeat.net? Announcing releases > there as well could help bring some more publicity for the project. > > Cheers, As Poul-Henning says, it's to early. I hope to use alot more than freashmeat to get Varnish out to the public :) Anders Berg From des at linpro.no Tue Aug 15 07:28:20 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 15 Aug 2006 09:28:20 +0200 Subject: If-Modified-Since Message-ID: Arne managed to get a trace of an HTTP session where Varnish incorrectly sent a 304 reply to an If-Modified-Since request. The object in his browser cache was: > HTTP/1.1 200 OK > Date: Mon, 14 Aug 2006 13:30:28 GMT > Server: Apache/1.3.27 (Unix) > Cache-Control: max-age=900 > Expires: Mon, 14 Aug 2006 13:45:28 GMT > Last-Modified: Mon, 14 Aug 2006 13:30:03 GMT > Etag: "2b400e-24922-44e07adb" > Content-Type: text/html; charset=iso-8859-1 > Content-Length: 149794 > X-Varnish: 44998368 44998332 > Age: 20 > Via: 1.1 varnish the request sent by his browser: > GET / HTTP/1.1 > Host: vg.no > User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.5) Gecko/20060727 Ubuntu/dapper-security Firefox/1.5.0.5 > Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Keep-Alive: 300 > Connection: keep-alive > If-Modified-Since: Mon, 14 Aug 2006 13:30:03 GMT > If-None-Match: "2b400e-24922-44e07adb" > Cache-Control: max-age=0 the reply from Varnish: > HTTP/1.1 304 Not Modified > Via: 1.1 varnish > X-Varnish: 44998848 > Last-Modified: Mon, 14 Aug 2006 13:30:03 GMT (note that the reply lacks a Date: header, we should fix that as well) unfortunately, I don't have the corresponding Varnish log. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 15 07:43:21 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 15 Aug 2006 07:43:21 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Tue, 15 Aug 2006 09:28:20 +0200." Message-ID: <17556.1155627801@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >Arne managed to get a trace of an HTTP session where Varnish >incorrectly sent a 304 reply to an If-Modified-Since request. Well, without the varnish log we can't tell if it was really incorrect, but we can pressume that it was. > >> HTTP/1.1 304 Not Modified >> Via: 1.1 varnish >> X-Varnish: 44998848 >> Last-Modified: Mon, 14 Aug 2006 13:30:03 GMT Inspecting the code I can see that we print the wrong thing in Last-Modified: header, we print what the user asked us about. >(note that the reply lacks a Date: header, we should fix that as well) > >unfortunately, I don't have the corresponding Varnish log. Which is the trouble because I can't possibly see how this test can fail: if (ims > sp->obj->last_modified) { VSL(SLT_Debug, sp->fd, "Cond: %d > %d ", sp->obj->last_modified, ims); return (0); } unless we have no last_modified field on the object. -- 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 andersb at vgnett.no Tue Aug 15 08:53:01 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 15 Aug 2006 10:53:01 +0200 (CEST) Subject: If-Modified-Since In-Reply-To: <17556.1155627801@critter.freebsd.dk> References: Your message of "Tue, 15 Aug 2006 09:28:20 +0200." <17556.1155627801@critter.freebsd.dk> Message-ID: <1648.193.213.34.102.1155631981.squirrel@denise.vg.no> > In message , Dag-Erling > =?iso-8859-1?Q?Sm=F8rgra > v?= writes: >>Arne managed to get a trace of an HTTP session where Varnish >>incorrectly sent a 304 reply to an If-Modified-Since request. Great. Good work. > Well, without the varnish log we can't tell if it was really > incorrect, but we can pressume that it was. I guess this is an example of the "old-page" problem? If it is, we now know that it can be triggered with: Last page served by Varnish, new page served by Varnish. Anders Berg >> >>> HTTP/1.1 304 Not Modified >>> Via: 1.1 varnish >>> X-Varnish: 44998848 >>> Last-Modified: Mon, 14 Aug 2006 13:30:03 GMT > > Inspecting the code I can see that we print the wrong thing > in Last-Modified: header, we print what the user asked us about. > >>(note that the reply lacks a Date: header, we should fix that as well) >> >>unfortunately, I don't have the corresponding Varnish log. > > Which is the trouble because I can't possibly see how this test > can fail: > > if (ims > sp->obj->last_modified) { > VSL(SLT_Debug, sp->fd, > "Cond: %d > %d ", sp->obj->last_modified, ims); > return (0); > } > > unless we have no last_modified field on the object. > > > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From des at linpro.no Tue Aug 15 09:01:59 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 15 Aug 2006 11:01:59 +0200 Subject: If-Modified-Since References: <17556.1155627801@critter.freebsd.dk> <1648.193.213.34.102.1155631981.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > I guess this is an example of the "old-page" problem? Yes. > If it is, we now know that it can be triggered with: > > Last page served by Varnish, new page served by Varnish. We now know that it is a result of Varnish sending an incorrect 304 reply to a conditional request from a client that has been idle for a long time (or a client which is using an old cache from a previous instance), so we need to look closer at the circumstances surrounding a call to res_do_304(). Unfortunately, I'm too busy to investigate any further today, so it will have to wait a little longer. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 15 09:07:59 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 15 Aug 2006 09:07:59 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Tue, 15 Aug 2006 11:01:59 +0200." Message-ID: <18177.1155632879@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >We now know that it is a result of Varnish sending an incorrect 304 >reply to a conditional request from a client that has been idle for a >long time (or a client which is using an old cache from a previous >instance), No, we do still not know that, we _suspect_ that. Since we don't have the logfile, we do not know what Varnishs copy of the relevant page looked like at the time where it replied with 304. -- 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 des at linpro.no Tue Aug 15 09:17:59 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 15 Aug 2006 11:17:59 +0200 Subject: If-Modified-Since In-Reply-To: <18177.1155632879@critter.freebsd.dk> (Poul-Henning Kamp's message of "Tue, 15 Aug 2006 09:07:59 +0000") References: <18177.1155632879@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > Since we don't have the logfile, we do not know what Varnishs copy > of the relevant page looked like at the time where it replied with > 304. We know that other clients received an up-to-date copy of the same page from Varnish prior to Arne getting a 304. BTW, this is a Varnish instance running locally on my workstation, using leonora as backend. Both Arne and I have appropriate lines in /etc/hosts to redirect part of our traffic to Varnish. See the following Wiki page for configuration details: http://varnish.projects.linpro.no/wiki/NorskeNettaviser DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 15 09:29:39 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 15 Aug 2006 09:29:39 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Tue, 15 Aug 2006 11:17:59 +0200." Message-ID: <18486.1155634179@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >"Poul-Henning Kamp" writes: >> Since we don't have the logfile, we do not know what Varnishs copy >> of the relevant page looked like at the time where it replied with >> 304. > >We know that other clients received an up-to-date copy of the same >page from Varnish prior to Arne getting a 304. > >BTW, this is a Varnish instance running locally on my workstation, >using leonora as backend. Both Arne and I have appropriate lines in >/etc/hosts to redirect part of our traffic to Varnish. See the >following Wiki page for configuration details: I take it that you have started varnislog so we can nail it next 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 des at linpro.no Tue Aug 15 09:30:35 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 15 Aug 2006 11:30:35 +0200 Subject: If-Modified-Since References: <18486.1155634179@critter.freebsd.dk> Message-ID: "Poul-Henning Kamp" writes: > I take it that you have started varnislog so we can nail it next time ? Yes. I expect it will happen again tomorrow morning. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Tue Aug 15 10:33:21 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Tue, 15 Aug 2006 12:33:21 +0200 Subject: If-Modified-Since References: <18486.1155634179@critter.freebsd.dk> Message-ID: des at linpro.no (Dag-Erling Sm?rgrav) writes: > "Poul-Henning Kamp" writes: > > I take it that you have started varnislog so we can nail it next time ? > Yes. I expect it will happen again tomorrow morning. Got one right after lunch: 13 SessionOpen c 87.238.44.2 36809 13 ReqStart c XID 1143246301 13 Debug c State RECV 13 RxRequest c GET 13 RxURL c / 13 RxProtocol c HTTP/1.1 13 RxHeader c Host: vg.no 13 RxHeader c User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.5) Gecko/20060727 Ubuntu/dapper-security Firefox/1.5.0.5 13 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 13 RxHeader c Accept-Language: en-us,en;q=0.5 13 RxHeader c Accept-Encoding: gzip,deflate 13 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 13 RxHeader c Keep-Alive: 300 13 RxHeader c Connection: keep-alive 13 RxHeader c If-Modified-Since: Tue, 15 Aug 2006 07:05:04 GMT 13 RxHeader c If-None-Match: "2b400e-25407-44e17220" 13 VCL_call c recv 26 31.14 27 32.13 28 32.49 1 1.22 2 2.9 5 5.5 6 5.9 8 8.5 9 8.9 10 8.34 12 11.5 lookup 13 Debug c State LOOKUP 13 Debug c State LOOKUP2 13 Debug c State MISS 13 VCL_call c miss 17 21.22 fetch 13 Backend c 14 vg 13 Debug c State FETCH 13 TTL c 1143246301 RFC 900 1155637301 1155637301 1155638201 900 0 13 VCL_call c fetch 18 25.23 19 26.9 21 29.5 22 29.9 24 32.5 insert 13 ObjProtocol c HTTP/1.1 13 ObjStatus c 200 13 ObjResponse c OK 13 ObjHeader c Date: Tue, 15 Aug 2006 10:21:41 GMT 13 ObjHeader c Server: Apache/1.3.27 (Unix) 13 ObjHeader c Cache-Control: max-age=900 13 ObjHeader c Expires: Tue, 15 Aug 2006 10:36:41 GMT 13 ObjHeader c Last-Modified: Tue, 15 Aug 2006 10:20:48 GMT 13 ObjHeader c ETag: "2b400e-25525-44e1a000" 13 ObjHeader c Content-Type: text/html; charset=iso-8859-1 13 ObjHeader c Content-Length: 152869 13 Debug c State DELIVER 13 Debug c Cond: 1155637248 <= 1155625504 13 Length c 0 13 TxProtocol c HTTP/1.1 13 TxStatus c 304 13 TxResponse c Not Modified 13 TxHeader c Date: Tue, 15 Aug 2006 10:21:41 GMT 13 TxHeader c Via: 1.1 varnish 13 TxHeader c X-Varnish: 1143246301 13 TxHeader c Last-Modified: Tue, 15 Aug 2006 10:20:48 GMT 13 Debug c State DONE 13 ReqEnd c 1143246301 1155637301.279049000 0.000179000 0.103224000 0.000102000 This looks fishy: if (ims > sp->obj->last_modified) { VSL(SLT_Debug, sp->fd, "Cond: %d > %d ", sp->obj->last_modified, ims); return (0); } Note how the if test and the debug message disagree. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Tue Aug 15 12:22:17 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 15 Aug 2006 12:22:17 +0000 Subject: If-Modified-Since In-Reply-To: Your message of "Tue, 15 Aug 2006 12:33:21 +0200." Message-ID: <19351.1155644537@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= writes: >This looks fishy: > > if (ims > sp->obj->last_modified) { > VSL(SLT_Debug, sp->fd, > "Cond: %d > %d ", sp->obj->last_modified, ims); > return (0); > } > >Note how the if test and the debug message disagree. DUH! Yes, that test is the wrong way around. -- 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 andersb at vgnett.no Tue Aug 15 15:47:51 2006 From: andersb at vgnett.no (Anders Berg) Date: Tue, 15 Aug 2006 17:47:51 +0200 Subject: If-Modified-Since In-Reply-To: <19351.1155644537@critter.freebsd.dk> References: <19351.1155644537@critter.freebsd.dk> Message-ID: <985389A0-8EEB-4520-808D-7FDC7525264D@vgnett.no> On Aug 15, 2006, at 14:22, Poul-Henning Kamp wrote: > In message , Dag-Erling =?iso-8859-1? > Q?Sm=F8rgrav?= writes: > >> This looks fishy: >> >> if (ims > sp->obj->last_modified) { >> VSL(SLT_Debug, sp->fd, >> "Cond: %d > %d ", sp->obj- >> >last_modified, ims); >> return (0); >> } >> >> Note how the if test and the debug message disagree. > > DUH! > > Yes, that test is the wrong way around. > Okay, so we can assume/confirm that this is what has been causing the "old page" bug? Anders Berg > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > From phk at phk.freebsd.dk Fri Aug 18 19:04:16 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 18 Aug 2006 19:04:16 +0000 Subject: Alteon detail Message-ID: <23180.1155927856@critter.freebsd.dk> This is probably an alteon configuration detail, but when it asked for /systemmeldinger/h.html it did so as HTTP/1.0 but the /h.html was HTTP/1.1 Not sure what significance this might have. -- 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 Aug 18 20:18:08 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 18 Aug 2006 20:18:08 +0000 Subject: Connection: handling for HTTP/1.0 Message-ID: <26843.1155932288@critter.freebsd.dk> I have the Connection: header handling for HTTP/1.0 in place now and it looks like it has lowered the "bad connection attempts" rate a bit, but it is still not zero. At the current request rate of approx 100/sec I see one or two "bad connection attempts" per second. I'm somewhat leaning towards the theory that it is a FreeBSD or network driver tuning issue. -- 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 andersb at vgnett.no Fri Aug 18 22:56:40 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 00:56:40 +0200 (CEST) Subject: Alteon detail In-Reply-To: <23180.1155927856@critter.freebsd.dk> References: <23180.1155927856@critter.freebsd.dk> Message-ID: <1546.193.69.165.4.1155941800.squirrel@denise.vg.no> > > This is probably an alteon configuration detail, but when it asked > for /systemmeldinger/h.html it did so as HTTP/1.0 but the /h.html > was HTTP/1.1 > > Not sure what significance this might have. This is because Alteon can have more than 1 service to a group of servers. Lets say I have a group of machine X and Y. This group can have virtual servers on them, a.vg.no and b.vg.no for example. In Alteon I can say that if a.vg.no works, then b.vg.no works (only 1 healthcheck as HTTP 1.0). But I can also set it to healthcheck a.vg.no and b.vg.no. Since a.vg.no and b.vg.no are on the same servers X and Y, I have to use virtual servers. Alteon uses HTTP 1.1 to do that. So a.vg.no can be "down" while b.vg.no is "up". www.vg.no, 193.69.165.21 and the group of machines that serv it only run 1 service, so Alteon does a HTTP/1.0. flash.vg.no and the group of servers that serv it have virtual hosts (they also serv download.vg.no, even if IP adress is not the same, the group of servers are). Ab > > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From andersb at vgnett.no Fri Aug 18 23:02:17 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 01:02:17 +0200 (CEST) Subject: Connection: handling for HTTP/1.0 In-Reply-To: <26843.1155932288@critter.freebsd.dk> References: <26843.1155932288@critter.freebsd.dk> Message-ID: <1558.193.69.165.4.1155942137.squirrel@denise.vg.no> > > I have the Connection: header handling for HTTP/1.0 in place now > and it looks like it has lowered the "bad connection attempts" rate > a bit, but it is still not zero. Good. I am unsure if we ever can hit 0 bad conn. We can take a look on the flash.vg.no servers. They serv alot of traffic also if I reduce the servers from 4 to 1. The bad conn number there is of interest. > At the current request rate of approx 100/sec I see one or two > "bad connection attempts" per second. > > I'm somewhat leaning towards the theory that it is a FreeBSD or > network driver tuning issue. Okay. I wanna ask ?ge R?bekk to take a look next time we pound it with traffic. He has experience with finding/fixing problems like this. We hit a wall like this on flash.vg.no once. And he tuned some parameters that fixed it. Ab > -- > 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-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > > From des at linpro.no Sat Aug 19 09:04:55 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sat, 19 Aug 2006 11:04:55 +0200 Subject: Alteon detail References: <23180.1155927856@critter.freebsd.dk> <1546.193.69.165.4.1155941800.squirrel@denise.vg.no> Message-ID: "Anders Berg" writes: > Lets say I have a group of machine X and Y. This group can have virtual > servers on them, a.vg.no and b.vg.no for example. In Alteon I can say that > if a.vg.no works, then b.vg.no works (only 1 healthcheck as HTTP 1.0). But > I can also set it to healthcheck a.vg.no and b.vg.no. Since a.vg.no and > b.vg.no are on the same servers X and Y, I have to use virtual servers. > Alteon uses HTTP 1.1 to do that. So a.vg.no can be "down" while b.vg.no is > "up". > > www.vg.no, 193.69.165.21 and the group of machines that serv it only run 1 > service, so Alteon does a HTTP/1.0. > > flash.vg.no and the group of servers that serv it have virtual hosts (they > also serv download.vg.no, even if IP adress is not the same, the group of > servers are). This explains why we couldn't run both www.vg.no and flash.vg.no on Varnish... the Alteon would probe www.vg.no without a Host: header and would get a 404. DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From des at linpro.no Sat Aug 19 09:05:56 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Sat, 19 Aug 2006 11:05:56 +0200 Subject: Connection: handling for HTTP/1.0 References: <26843.1155932288@critter.freebsd.dk> Message-ID: Poul-Henning Kamp writes: > At the current request rate of approx 100/sec I see one or two > "bad connection attempts" per second. > > I'm somewhat leaning towards the theory that it is a FreeBSD or > network driver tuning issue. ...or they could be bad clients. have we checked the squids to see if they too have "bad connection attempts"? DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Sat Aug 19 09:40:39 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 19 Aug 2006 09:40:39 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sat, 19 Aug 2006 11:04:55 +0200." Message-ID: <29333.1155980439@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >This explains why we couldn't run both www.vg.no and flash.vg.no on >Varnish... the Alteon would probe www.vg.no without a Host: header >and would get a 404. Bingo! -- 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 Aug 19 10:05:01 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 19 Aug 2006 10:05:01 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sat, 19 Aug 2006 00:56:40 +0200." <1546.193.69.165.4.1155941800.squirrel@denise.vg.no> Message-ID: <29420.1155981901@critter.freebsd.dk> Anders, I tried to find the two alteon docs you sent me while were were livetesting in Oslo, but I can't find them, could you dump them on c21 or fw so I can pick them there ? -- 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 andersb at vgnett.no Sat Aug 19 11:04:06 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 13:04:06 +0200 Subject: Alteon detail In-Reply-To: References: <23180.1155927856@critter.freebsd.dk> <1546.193.69.165.4.1155941800.squirrel@denise.vg.no> Message-ID: <8DCB6087-41FD-4C6F-86BC-C77E62D723AB@vgnett.no> On Aug 19, 2006, at 11:04, Dag-Erling Sm?rgrav wrote: > "Anders Berg" writes: >> Lets say I have a group of machine X and Y. This group can have >> virtual >> servers on them, a.vg.no and b.vg.no for example. In Alteon I can >> say that >> if a.vg.no works, then b.vg.no works (only 1 healthcheck as HTTP >> 1.0). But >> I can also set it to healthcheck a.vg.no and b.vg.no. Since >> a.vg.no and >> b.vg.no are on the same servers X and Y, I have to use virtual >> servers. >> Alteon uses HTTP 1.1 to do that. So a.vg.no can be "down" while >> b.vg.no is >> "up". >> >> www.vg.no, 193.69.165.21 and the group of machines that serv it >> only run 1 >> service, so Alteon does a HTTP/1.0. >> >> flash.vg.no and the group of servers that serv it have virtual >> hosts (they >> also serv download.vg.no, even if IP adress is not the same, the >> group of >> servers are). > > This explains why we couldn't run both www.vg.no and flash.vg.no on > Varnish... the Alteon would probe www.vg.no without a Host: header > and would get a 404. Oh? I didn't catch that that was the reason. Sorry, I could have informed you guys about it then. My bad. I'll fix it right this instant that it will send a HTTP 1.1 request. Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > From andersb at vgnett.no Sat Aug 19 11:05:44 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 13:05:44 +0200 Subject: Connection: handling for HTTP/1.0 In-Reply-To: References: <26843.1155932288@critter.freebsd.dk> Message-ID: <92E3B69A-B947-4E4E-89BC-9FA29BB1CB39@vgnett.no> On Aug 19, 2006, at 11:05, Dag-Erling Sm?rgrav wrote: > Poul-Henning Kamp writes: >> At the current request rate of approx 100/sec I see one or two >> "bad connection attempts" per second. >> >> I'm somewhat leaning towards the theory that it is a FreeBSD or >> network driver tuning issue. > > ...or they could be bad clients. have we checked the squids to see if > they too have "bad connection attempts"? Yes, we can either check a Squid or a flash server. I'll make a login on a squid and put connectinfo on c21 or on irc. I suspect clients to make bad connects from time to time at the level of traffic we have. Anders Berg > DES > -- > Dag-Erling Sm?rgrav > Senior Software Developer > Linpro AS - www.linpro.no > _______________________________________________ > varnish-dev mailing list > varnish-dev at projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-dev > From andersb at vgnett.no Sat Aug 19 11:06:49 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 13:06:49 +0200 Subject: Alteon detail In-Reply-To: <29420.1155981901@critter.freebsd.dk> References: <29420.1155981901@critter.freebsd.dk> Message-ID: <160EEBAF-00B0-4732-A46E-657B8258D44C@vgnett.no> On Aug 19, 2006, at 12:05, Poul-Henning Kamp wrote: > > Anders, > > I tried to find the two alteon docs you sent me while were were > livetesting in Oslo, but I can't find them, could you dump > them on c21 or fw so I can pick them there ? Sure, I'll put them on /home/varnish/alteon Anders Berg > -- > 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 Aug 19 18:14:12 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 19 Aug 2006 18:14:12 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sat, 19 Aug 2006 13:04:06 +0200." <8DCB6087-41FD-4C6F-86BC-C77E62D723AB@vgnett.no> Message-ID: <30901.1156011252@critter.freebsd.dk> Can one of you tell me which state the Alteon was left in, I'm going to try to see if I can find out why it hates us, and it would be useful to know what metric and weight is in effect -- 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 andersb at vgnett.no Sat Aug 19 21:26:08 2006 From: andersb at vgnett.no (Anders Berg) Date: Sat, 19 Aug 2006 23:26:08 +0200 Subject: Alteon detail In-Reply-To: <30901.1156011252@critter.freebsd.dk> References: <30901.1156011252@critter.freebsd.dk> Message-ID: <4D874FF3-31E1-4609-974A-23783F904713@vgnett.no> On Aug 19, 2006, at 20:14, Poul-Henning Kamp wrote: > > Can one of you tell me which state the Alteon was left in, > I'm going to try to see if I can find out why it hates us, > and it would be useful to know what metric and weight is > in effect I was left in leastconn metric and weight 1. Other Squids weight 5 and 1 Squid in 10. Thanks for todays testing guys. Great that we got to test some. I feel we should focus on one thing right now, and that is getting Varnish to function when we give it all of the traffic. The multiple Host: testing can wait. We have to find out if it is FreeBSD or Varnish that can't handle it to good. Getting to know Alteon is needed. Though more in the context of opening connections, keeping them alive and closing them. Not so much in the metric that put traffic there in the first place. One way we can try to even out the traffic more in a linear way when switching weights is to maybe use a source-adress hash (sticky sessions) and then use weight. Weight should then use the number of IP adresses to weight with, not the mystic leastconn (based on connections). That way we can maybe control the amount of traffic we push to Varnish more. But I fear we will not get to much out of balancing on the work/not-working threshold. Either we are hitting a FreeBSD barrier, or a Varnish barrier, and we should be able to pinpoint that out with just doing what we normally do before we give all the traffic to Varnish (weight 30-40 Varnish, 5 on others, then 100% to varnish). The barrier should show itself somewhere. If you guys don't diagree we should just focus on switching between working and not-working traffic patterns next time, and see what we find. We can probably learn some from looking how Squid does it's connection handling. I am gonna teach DES some Alteon commands tomorrow, so he can control some traffic while I am gone. I can spend a couple of hours tomorrow throwing some traffic on Varnish if you guys are up for it? Anders Berg > -- > 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 andersb at vgnett.no Sat Aug 19 22:04:15 2006 From: andersb at vgnett.no (Anders Berg) Date: Sun, 20 Aug 2006 00:04:15 +0200 Subject: Alteon detail In-Reply-To: <30901.1156011252@critter.freebsd.dk> References: <30901.1156011252@critter.freebsd.dk> Message-ID: Btw, http://www.freebsd.org/cgi/man.cgi? query=tuning&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html is good for finding out what can be wrong. I read alot of good hints there. kern.ipc.somaxconn, net.inet.tcp.always_keepalive, net.inet.tcp.inflight.enable, might be worth trying out as one of them states: "The default value of 128 is typically too low for robust handling of new connections in a heavily loaded web server environment. For such environments, we recommend increasing this value to 1024 or higher." Ab From phk at phk.freebsd.dk Sat Aug 19 22:11:29 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 19 Aug 2006 22:11:29 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sat, 19 Aug 2006 23:26:08 +0200." <4D874FF3-31E1-4609-974A-23783F904713@vgnett.no> Message-ID: <62962.1156025489@critter.freebsd.dk> In message <4D874FF3-31E1-4609-974A-23783F904713 at vgnett.no>, Anders Berg writes : >I was left in leastconn metric and weight 1. Other Squids weight 5 >and 1 Squid in 10. Ok, I can use that. >Thanks for todays testing guys. Great that we got to test some. Yeah, although I don't feel I learned anything "postive" today, I only managed to eliminate a number of theories, not nail down the right one. >I feel we should focus on one thing right now, and that is getting >Varnish to function when we give it all of the traffic. The multiple >Host: testing can wait. Well, there is little preventing us from progressing on two fronts at once, but yes, the main objective is the load. >Host: testing can wait. We have to find out if it is FreeBSD or >Varnish that can't handle it to good. Yes. This might be tricky work. It would be very useful if the Alteon would tell us why it hates us instead of just throttling us. I have created ticket #38 with a fault tree we can use to nail this problem down, feel free to amend and update, but please don't eliminate any causes without documenting how you did 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 phk at phk.freebsd.dk Sat Aug 19 22:20:18 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat, 19 Aug 2006 22:20:18 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sun, 20 Aug 2006 00:04:15 +0200." Message-ID: <63003.1156026018@critter.freebsd.dk> In message , Anders Berg writes : >is good for finding out what can be wrong. I read alot of good hints >there. yes, it's a good source of wisdom. >kern.ipc.somaxconn, net.inet.tcp.always_keepalive, >net.inet.tcp.inflight.enable, somaxconn does not seem to be an issue, we have no listen queue overflows according to netstat -s, but we can try to tweak it. always_keepalive is on by default and we should probably yank the timeouts waaay down (15 sec + 8 * 5 sec) or something, but it's certainly not our trouble right now. I'm not sure the inflight stuff will help us, we have no signs of memory starvation. -- 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 Sun Aug 20 08:44:05 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 20 Aug 2006 08:44:05 +0000 Subject: Alteon detail In-Reply-To: Your message of "Sat, 19 Aug 2006 22:11:29 GMT." <62962.1156025489@critter.freebsd.dk> Message-ID: <75743.1156063445@critter.freebsd.dk> In message <62962.1156025489 at critter.freebsd.dk>, "Poul-Henning Kamp" writes: >In message <4D874FF3-31E1-4609-974A-23783F904713 at vgnett.no>, Anders Berg writes >: > >>I was left in leastconn metric and weight 1. Other Squids weight 5 >>and 1 Squid in 10. > >Ok, I can use that. "leastconn" is very sensitive to our session timeout. I brief test shows that there is little benefit from having it higher than a few seconds anyway. I have reduced it to 3 seconds now. Can I get you to increase the weight to 10 for varnish ? -- 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 Sun Aug 20 10:45:47 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 20 Aug 2006 10:45:47 +0000 Subject: A few missed SYN's Message-ID: <76067.1156070747@critter.freebsd.dk> I'm seeing a few cases were we fail to reply to a SYN, but we are talking 3 cases in 5 minutes at 50mbit/sec load. %grep 129.241.138.93.15578 /tmp/_syns 1156070576.840399 IP 129.241.138.93.15578 > 10.0.2.21.80: S 2999862850:2999862850(0) win 5840 1156070579.849804 IP 129.241.138.93.15578 > 10.0.2.21.80: S 2999862850:2999862850(0) win 5840 1156070579.849821 IP 10.0.2.21.80 > 129.241.138.93.15578: S 3653626228:3653626228(0) ack 2999862851 win 65535 1156070579.849951 IP 129.241.138.93.15578 > 10.0.2.21.80: . ack 1 win 5840 1156070579.849953 IP 129.241.138.93.15578 > 10.0.2.21.80: P 1:550(549) ack 1 win 5840 1156070579.850091 IP 10.0.2.21.80 > 129.241.138.93.15578: P 1:153(152) ack 550 win 65535 1156070579.858764 IP 129.241.138.93.15578 > 10.0.2.21.80: . ack 153 win 6432 1156070583.851173 IP 10.0.2.21.80 > 129.241.138.93.15578: F 153:153(0) ack 550 win 65535 1156070583.860066 IP 129.241.138.93.15578 > 10.0.2.21.80: F 550:550(0) ack 154 win 6432 1156070583.860086 IP 10.0.2.21.80 > 129.241.138.93.15578: . ack 551 win 65534 -- 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 andersb at vgnett.no Sun Aug 20 10:48:03 2006 From: andersb at vgnett.no (Anders Berg) Date: Sun, 20 Aug 2006 12:48:03 +0200 Subject: A few missed SYN's In-Reply-To: <76067.1156070747@critter.freebsd.dk> References: <76067.1156070747@critter.freebsd.dk> Message-ID: <587E9CE1-A047-447E-A771-C95496F93C94@vgnett.no> On Aug 20, 2006, at 12:45, Poul-Henning Kamp wrote: > > I'm seeing a few cases were we fail to reply to a SYN, but we are > talking 3 cases in 5 minutes at 50mbit/sec load. Could it be that we fail to reply alot more when the traffic is "high"? Anders Berg From phk at phk.freebsd.dk Sun Aug 20 10:49:43 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 20 Aug 2006 10:49:43 +0000 Subject: A few missed SYN's In-Reply-To: Your message of "Sun, 20 Aug 2006 12:48:03 +0200." <587E9CE1-A047-447E-A771-C95496F93C94@vgnett.no> Message-ID: <76085.1156070983@critter.freebsd.dk> In message <587E9CE1-A047-447E-A771-C95496F93C94 at vgnett.no>, Anders Berg writes : > > > >On Aug 20, 2006, at 12:45, Poul-Henning Kamp wrote: > >> >> I'm seeing a few cases were we fail to reply to a SYN, but we are >> talking 3 cases in 5 minutes at 50mbit/sec load. > >Could it be that we fail to reply alot more when the traffic is "high"? Yes, that is likely, the question is why we fail to reply. -- 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 Sun Aug 20 18:39:54 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 20 Aug 2006 18:39:54 +0000 Subject: A few missed SYN's In-Reply-To: Your message of "Sun, 20 Aug 2006 10:45:47 GMT." <76067.1156070747@critter.freebsd.dk> Message-ID: <94094.1156099194@critter.freebsd.dk> In message <76067.1156070747 at critter.freebsd.dk>, Poul-Henning Kamp writes: > >I'm seeing a few cases were we fail to reply to a SYN, but we are >talking 3 cases in 5 minutes at 50mbit/sec load. A lot of work on the kqueue acceptor seems to have nailed these. -- 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 andersb at vgnett.no Mon Aug 21 07:23:39 2006 From: andersb at vgnett.no (Anders Berg) Date: Mon, 21 Aug 2006 09:23:39 +0200 (CEST) Subject: Eventbased/driven webserver Message-ID: <1399.193.213.34.102.1156145019.squirrel@denise.vg.no> Hi, I have recently looked a little at Lighttpd. It is an eventdriven webserver much like us. http://www.lighttpd.net/ I guess a quick look on the kqueue and sessionclosing part can give us some possibly valuable hint's as to what we may be doing different. Lighttpd has been around for some time and probably has all those quirks sorted out. Anders Berg From phk at phk.freebsd.dk Mon Aug 21 08:32:50 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 21 Aug 2006 08:32:50 +0000 Subject: Eventbased/driven webserver In-Reply-To: Your message of "Mon, 21 Aug 2006 09:23:39 +0200." <1399.193.213.34.102.1156145019.squirrel@denise.vg.no> Message-ID: <97344.1156149170@critter.freebsd.dk> In message <1399.193.213.34.102.1156145019.squirrel at denise.vg.no>, "Anders Berg " writes: >Hi, > >I have recently looked a little at Lighttpd. It is an eventdriven >webserver much like us. > >http://www.lighttpd.net/ > >I guess a quick look on the kqueue and sessionclosing part can give us >some possibly valuable hint's as to what we may be doing different. >Lighttpd has been around for some time and probably has all those quirks >sorted out. I think I have kqueue licked now. The problem was that I assumed that the changelist as applied atomically with respect to other threads on the same kqueue, but it isn't, it's applied one change at a time. So when a session had been services and came back, I would add to kevents: A reader and a timer. The reader would get applied, and trigger instantly, the acceptor would get the event, conclude that the session was closed, and delete the two kevents any session has when in the acceptor. Except the first thread had not gotten around to add the timer kevent yet, so removing it would fail and then it would get added after the corresponding session was destroyed by the acceptor. Now I add the timer kevent first and everything is happy. -- 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 Aug 21 20:47:17 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 21 Aug 2006 20:47:17 +0000 Subject: sort of a milestone Message-ID: <36389.1156193237@critter.freebsd.dk> Today is the first day where the majority of my time has been spent on performance rather than development and bugfixing. That's sort of a milestone too :-) It looks like we hit contention of some kind around 140Mbit/sec and 3100 req/sec. The responsetime flips from being less than 100usec to being around 10msec. This also means that we can not test these issue at any time of the day, we need to have the traffic first. -- 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 Aug 22 06:49:13 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Aug 2006 06:49:13 +0000 Subject: Todays work Message-ID: <38299.1156229353@critter.freebsd.dk> I will be concentrating on the hashing today, I suspect that is were our next performance bottleneck is and I see a few things that can be improved. -- 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 Tue Aug 22 09:52:47 2006 From: anders at fupp.net (Anders Nordby) Date: Tue, 22 Aug 2006 11:52:47 +0200 Subject: NUUG presentation on september 19? Message-ID: <20060822095247.GB93484@totem.fix.no> Hi, Anders just called me. After discussing dates with him I am checking with NUUG if the Varnish meeting can be held on september 19th. He wants to have it then. Cheers, -- Anders. From phk at phk.freebsd.dk Tue Aug 22 10:12:32 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 22 Aug 2006 10:12:32 +0000 Subject: NUUG presentation on september 19? In-Reply-To: Your message of "Tue, 22 Aug 2006 11:52:47 +0200." <20060822095247.GB93484@totem.fix.no> Message-ID: <56678.1156241552@critter.freebsd.dk> In message <20060822095247.GB93484 at totem.fix.no>, Anders Nordby writes: >Hi, > >Anders just called me. After discussing dates with him I am checking >with NUUG if the Varnish meeting can be held on september 19th. He wants >to have it then. I have reserved it in my calendar. -- 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 Wed Aug 23 11:46:20 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 23 Aug 2006 11:46:20 +0000 Subject: Worlds first "real world" VCL program Message-ID: <77453.1156333580@critter.freebsd.dk> Implementing PURGE in squid style: acl purge { "localhost"; "10.0.0.1"; } sub vcl_recv { if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } lookup; } } sub vcl_hit { if (req.request == "PURGE") { set obj.ttl = 0s; error 200 "Purged."; } } sub vcl_miss { if (req.request == "PURGE") { error 404 "Not in cache."; } } -- 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 des at linpro.no Thu Aug 24 07:47:27 2006 From: des at linpro.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Date: Thu, 24 Aug 2006 09:47:27 +0200 Subject: URL normalization Message-ID: 12:14 < phk> Other detail: It looks like Host: normalization might make sense from a cache-size point of view: 12:14 < phk> 358578.03 Host: www.vg.no 12:14 < phk> 13655.51 Host: vg.no 12:14 < phk> 145.80 Host: www.vg.no 12:14 < phk> 56.58 Host: www.vg.no. 12:14 < phk> 55.67 Host: 193.69.165.21 12:14 < phk> 37.25 Host: www.vg.no:80 12:14 < phk> 23.52 Host:www.vg.no 12:14 < phk> 4.69 Host: vg.no:80 Not just from a cache-size point of view... PURGE won't catch all copies of a page if we don't normalize the URL (or at least the host). DES -- Dag-Erling Sm?rgrav Senior Software Developer Linpro AS - www.linpro.no From phk at phk.freebsd.dk Thu Aug 24 08:00:03 2006 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 24 Aug 2006 08:00:03 +0000 Subject: URL normalization In-Reply-To: Your message of "Thu, 24 Aug 2006 09:47:27 +0200." Message-ID: <97979.1156406403@critter.freebsd.dk> In message , Dag-Erling =?iso-8859-1?Q?Sm=F8rgra v?= writes: >12:14 < phk> Other detail: It looks like Host: normalization might make sense > from a cache-size point of view: >12:14 < phk> 358578.03 Host: www.vg.no >12:14 < phk> 13655.51 Host: vg.no >12:14 < phk> 145.80 Host: www.vg.no >12:14 < phk> 56.58 Host: www.vg.no. >12:14 < phk> 55.67 Host: 193.69.165.21 >12:14 < phk> 37.25 Host: www.vg.no:80 >12:14 < phk> 23.52 Host:www.vg.no >12:14 < phk> 4.69 Host: vg.no:80 > >Not just from a cache-size point of view... PURGE won't catch all >copies of a page if we don't normalize the URL (or at least the host). true. -- 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 Aug 31 06:39:31 2006 From: anders at fupp.net (Anders Nordby) Date: Thu, 31 Aug 2006 08:39:31 +0200 Subject: NUUG presentation on september 19? In-Reply-To: <56678.1156241552@critter.freebsd.dk> References: <20060822095247.GB93484@totem.fix.no> <56678.1156241552@critter.freebsd.dk> Message-ID: <20060831063931.GA62503@totem.fix.no> Hi, On Tue, Aug 22, 2006 at 10:12:32AM +0000, Poul-Henning Kamp wrote: >>Anders just called me. After discussing dates with him I am checking >>with NUUG if the Varnish meeting can be held on september 19th. He wants >>to have it then. > I have reserved it in my calendar. I just got an OK from NUUG, so we're all set for september 19. What I need now is: - title of the presentation. - 1-2 paragraphs about the presentation. - 1 paragraph about the speaker. This is so that we can put some information out on the web, and announce the meeting. See: http://nuug.no/meetings/speakerinfo.shtml Cheers, -- Anders.