Re: Literal ip4/6 addresses in VCL
In message <4b93b6ea.9010...@schokola.de>, Nils Goroll writes: >> The syntax for this is already decided, just not implemented: >> >> set client.ip = IP(req.http.x-forwarded-for); > >Thank you for pointing this out, so I am going to implement this syntax for >the >case where runtime conversion is needed. > >Do you have an opinion regarding the suggestion for the VCL compile time case? There should not be two different syntaxes, the above should be used in both cases. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Literal ip4/6 addresses in VCL
In message <4b93b0ab.4080...@schokola.de>, Nils Goroll writes: >My main question is if they should be tokenized as CSTRs or rather as new >tokens, e.g. of token type IP (not to be confused with variable type IP). The syntax for this is already decided, just not implemented: set client.ip = IP(req.http.x-forwarded-for); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: more VTLAs
In message <4b9390d1.8000...@schokola.de>, Nils Goroll writes: >I've tried to add some more definitions, maybe someone could review those? > >http://varnish-cache.org/wiki/VTLA?action=diff&version=5 good catch. I have expanded the explations a bit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Response Content Modifications
In message , Moshe K aplan writes: >I understand that you are well into Varnish, and that you are familiar with >the internal functions (those that are used in the inline C) >Is there any exposure in the code (C and not VCL) to the C pointer to the >response and object content? >Is it available in the http struct? or in any other struct in the system? or >is it just not available anywhere? It is available, but it is far from trivial to substitute a new content, because of the various reference counts etc. I think a more conventional proxy process is much better suited to what you are trying to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Response Content Modifications
In message , Moshe Kaplan writes: >The target is to modify the received content from the backend (for example >changing embedded URLs in HTML, removing parts of the content based on >regular expressions and so on). > >P.S. I don't have control on the back end content, so I cannot use esi. Sorry for asking a point blank rude question, but what you describes sounds like theft of copyrighted content from somebody else. Do you have the necessary legal rights to use the contents on the backend ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: adding header question
In message , Eran Sandler writes: >I tried setting the header in vcl_recv (set req.http.MyHeader = "1";), >[...] but it doesn't seem to get sent to the backend. That should work. Try running varnishlog, and keep an eye on the "TxHeader" lines, which show what is sent to the backend. You can also enable the vcl_trace parameter, which will put records into the varnishlog, with line+char_pos of the VCL as it is executed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4480 - trunk/varnish-cache/bin/varnishncsa
In message , =?iso-8859-1? Q?Ask_Bj=F8rn_Hansen?= writes: > >On Feb 1, 2010, at 1:35, Anders Nordby wrote: > >> I must object to this change, as I use varnishncsa -b extensively to >> pull out reports on missed objects being fetch from the backends too >> often. Please revert this change, as varnishncsa -b has its use. > >I don't know why it was removed or if there's a good alternative, >but I've found the -b option very useful, too. Well, the code to implement it full was never there, and people were reporting core dumps because of it, so we figured we would make the non-support for -b explicit, until the code could be written. There are no objections to supporting it, it's just code to be written by somebody... (nudge, nudge, wink, wink...) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Response bodies cached for HitPass objects
In message , Matthew Page writes: >It looks like response bodies are cached for the entire life of a HitPass >object. Is this true? Yes, it's a shortcut we made back then. The reasoning was that hit-for-pass objects probably would have pretty short lifetimes (usually the default TTL) and thus not cost too much storage for too long. As part of changes on the drawingboard now, that will be fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: module init hook
In message <6d0f643a1001060745k3cb5dcc9n766cf52e0a809...@mail.gmail.com>, Cal H eldenbrand writes: >Is there a good method to load my module in the main varnishd thread? Not right now. I am working on a way to use "libraries" from varnish, but it is not ready yet. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: idea for load "balancer" with fan-out/ voting
In message <4b44b968.6060...@taptu.com>, Paul Mansfield writes: >just some ideas for discussion... > >whilst varnish has been very good at alleviating load by virtue of its >forced caching feature, I was wondering whether it's be possible to have >one request be duplicated to multiple back-end servers and the first one >to reply is used and the others ignored. Ouch. That one is not easy, we pretty much hardcoded that we would only fetch from one backend at a time for each session. Sounds sort of hackish though. Couldn't you solve this by aggressively probing your backends and let them go sick during GC ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: inline C code and post data
In message <6d0f643a0912311432v1e594e5cl601f1a5b19b59...@mail.gmail.com>, Cal H eldenbrand writes: >I just started experimenting with the coolness of using inline C in VCL, and >I've run into a bit of a hurdle -- I can't find any VRT functions that allow >me to dig into the request body where the post data is at. The post data is not available at any point near VCL, it is transferred to the backend as part of the backend fetch. Poul-Henning PS: Happy NewYear -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: scheduling off the waiting list
In message <4b39210f.7080...@schokola.de>, Nils Goroll writes: >So basically there are two different scenarios when hsh_rush is called. > >* Trigger delivery of an object which just got unbusied >* and trigger delivery of more sessions which did not fire in the first round The basic point here is that we do not want to unleash 500 waiting sessions when the object is unbusied, so we release a few, and when they are done they each release a few etc. Sort of inspired by TCP-slowstart, but not half as advanced. I'm not entirely happy with how this works in practice, but within the current reach, I have no better ideas. Grace mode helps a lot, if you can use it. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: scheduling off the waiting list
In message <4b2004ce.5080...@schokola.de>, Nils Goroll writes: >Hi Poul-Henning, > >thank you for taking the time to respond. > >> What happens here is that another client/thread holds this object >> "busy" while it is being fetched from the backend. Once the object >> is marked unbusy, the waiting threads are relased, and calls hash >> again. > >My understanding is that the waiting sessions are re-scheduled on threads, >right? Correct. >What I would really like to see is that the waitinglist gets rescheduled when >the busy object is actually becomes in the cache. I am suspecting this has to >do >with calling HSH_Deref(&Parent) in HSH_Unbusy and/or the fact that HSH_Drop >calls both Unbusy and Deref, but I don't understand this yet. That is how it is supposed to work, and I belive, how it works. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: HSH_Lookup entered multiply - why could that happen?
In message <4b1ffa7d.3020...@schokola.de>, Nils Goroll writes: >Hi, >what I get is this (URL removed to protect the innocent): > >48 VCL_call c recv lookup >48 VCL_call c hash hash >48 Debugc 24115201202978841 8d6278 on waiting list 8b72e0 <##URL##> What happens here is that another client/thread holds this object "busy" while it is being fetched from the backend. Once the object is marked unbusy, the waiting threads are relased, and calls hash again. I'm not quite sure you you keep hitting it so many times, it smells like som weird situation where the object takes a long time to fetch, has no cacheability, but does not get marked "pass" in vcl_fetch ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching of ESI snippets
In message , Joe Van Dyk writes: >> You browser sends cookies along ? > >Nope. > >However, /include has this cache-control: private, max-age=3D0, >must-revalidate. But I wouldn't think that would matter when varnish >decides whether or not to request /esi? Unless Varnish sees that, it will not matter. Varishlog is, as always, your friend. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching of ESI snippets
In message , Joe Va n Dyk writes: >I have two pages /main and /esi. > >/main returns: > > >/esi has a cache-control of "max-age=60, public" and returns the current time. > >I'd expect that when I load /main, /esi would be requested once a >minute. In a browser, /esi is loaded from the server everytime >(instead of the varnish sending the cached version). In curl, it all >works as expected. You browser sends cookies along ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Varnish and sticky sessions
In message <4b027ecb.9050...@qbranch.se>, Robert Olsson writes: >Hello! >Is there any plan to support sticky sessions in varnish? Plans ? yes. Deadlines ? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: bug in esi:include handling (with patch)
In message <19203.62532.605771.461...@bio-iisrv1.bio.ic.ac.uk>, Bob MacCallum w rites: > >Oh, well, at least great minds think alike. > >Are includes like this supposed to work: > >http://some.other.site/stuff"; /> It only works if you have a backend defined for that server. Look at bin/varnistest/tests/e00006.vtc for an example. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: bug in esi:include handling (with patch)
In message <19203.52561.488165.347...@bio-iisrv1.bio.ic.ac.uk>, Bob MacCallum w rites: >I found an off-by-one bug in esi_handle_include() - ESI requests were being >made for URLs with one extra character that was left over from the previous >request. He, I beat you by a day, I fixed that in r4351 :-) >If you'd like me to add the ticket, please send the Trac login info off list. You can create your own trac-login. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Backend polling not working
In message <4aded57c.3020...@upfrontsystems.co.za>, Izak Burger writes: >Hello again, > >I've discussed this issue on zope-dev. The agreement seems to be that >there is some ambiguity in the HTTP1.1 specification, but that the >general accepted interpretation is that if the other end closes the >connection you should close your end as well (it signals a timeout). > >There is also no browser implementation out there that does half-closing >(except where SSL is involved). None that I know of anyway. I wasn't quite sure which way to interpret the text originally so I did it the way that was most convenient for the code. I'll change it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: [PATCH] Add PCRE support
I think it is time to wrap this discussion up. Being as it may, that I happen to be the supreme master and arbiter of all bikeshed coloring in the Open Source domain. (Please see www.bikeshed.org if you doubt my credencials.) First of all, I my spectroscope clearly indicates that the discussion is in bikeshed territory now, reading lambda = 536 +/- 107 nm I will therefore don my Official Psycedelic Overalls, and wielding the Brush Of Authority, pronounce my judgment in the matter. Which shall be as follows: Having in mind, the many examples that Varnish users have proffered, why PCRE would be A Good Thing over POSIX regexps... Beeing keenly aware that having binary packages of Varnish differ in this point would be a catastrophe for documentation and user support. Having studied PCRE at some length, and reached the firm belief, that if Dennis and Ken had been in charge, PCRE would have been adopted as the standard UNIX regexp library on the spot... Recognizing, that PCRE is BSD licensed... Having in mind, that if the external dependency on PCRE causes us grief, we can import PCRE into Varnish, like we did with and ... I hereby decide: We will add a "vre.c" file to libvarnish, and all the varnish code will call vre_comp(), vre_exec() etc. functions from there. By default, this file will simply call PCRE functions, and as shipped Varnish will depend in PCRE. If somebody for reasons of policy does not want to use PCRE, they will only have to change the vre.c file to do so. Dixit. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Backend polling not working
In message <4ad60d6d.1070...@upfrontsystems.co.za>, Izak Burger writes: >Hi all, > >10.0.0.12 - Anonymous [14/Oct/2009:18:38:38 +0200] "GET /plonesite >HTTP/1.1" 200 0 "" > >Note the zero after the 200 status. I suspect this causes a problem on >line 220 of bin/varnishd/cache_backend_poll.c, where rlen is the length >of data read from zope: > > if (rlen == 0) > return; > >The result of this is a sick backend, eg: Yes, if we get no bytes, we do not accept it as a good probe. >Using wireshark to log at the network traffic confirms that the HTTP >request is sent, but no response, corresponding with the access log. That would sort of indicate that the problem is on the backend. You may need to customize the HTTP request used for probing with the ".request =" line in your backend probe definition, in order to explain things to your backend. A Host: header maybe ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: [PATCH] Fix typo in esi diagnostic
Sorry about the delay, your email had gotten sorted into the "later"
mailbox.
It's fixed now, thanks for noticing.
Poul-Henning
In message <591b5df8-a755-40f2-9677-be0d3614f...@dwim.org>, "Jos I. Boumans" wr
ites:
>Greetings,
>
>While browsing the source, I came a cross a small typo. Patch below sig.
>
>Cheers,
>
>--
>
> Jos Boumans
>
> "Whenever you find you are on the side of the majority,
> it is time to pause and reflect." - Mark Twain
>
>Index: varnish-cache/bin/varnishd/cache_esi.c
>===
>--- varnish-cache/bin/varnishd/cache_esi.c (revision 4207)
>+++ varnish-cache/bin/varnishd/cache_esi.c (working copy)
>@@ -370,7 +370,7 @@
> continue;
> if (Tlen(val) == 0) {
> esi_error(ew, tag.b, Tlen(tag),
>- "ESI esi:include src attribute withou
>value");
>+ "ESI esi:include src attribute without
>value");
> continue;
> }
>
>
>
>___________
>varnish-dev mailing list
>varnish-dev@projects.linpro.no
>http://projects.linpro.no/mailman/listinfo/varnish-dev
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Saint mode
In message <22964b960908311958r211f8ac9g1b6eee46ed92d...@mail.gmail.com>, Javie
r Frias writes:
>Specifically, we are looking to not store bad documents unless we have to,
>iow, not replace a known good document ( status 200 or 404 ), with a bad
>document ( status 503 ), if it would otherwise would be served from grace.
503's are never cached to my knowledge.
the rest can be obtained by:
sub vcl_fetch {
if (beresp.status != 200 && beresp.status != 404) {
set beresp.ttl = 0;
return (pass);
}
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4097 - trunk/varnish-cache/lib/libvarnish
In message <86ocqt55aa@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >"Poul-Henning Kamp" writes: >> This is nice, and we should have that, _as well_, for people like >> sky@ who muck about with their own branch. >> >> But it is no substitute for a tree-wide version number, and the >> two schemes are in no way conflicting or in each others way. > >There is no such thing. It's a sham. No, it is not a sham, for a very large majority of users, it is indeed plenty to allow me to figure which version they are running. Anyway, if you don't like it, don't use it. I like it, I use it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4097 - trunk/varnish-cache/lib/libvarnish
In message <864osl6nav@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >"Poul-Henning Kamp" writes: >> "Dag-Erling Sm=C3=B8rgrav" writes: >> > There is a better solution: the RCS ID of every source file is embedded >> > in a string in the object, "just like FreeBSD does it". This is a >> > better solution not only because it does not break dependency tracking, >> > but because it is more detailed, and covers more than just libvarnish. >> Provide a patch ? > >I committed it two months ago (r4093 on 2009-06-06). This is nice, and we should have that, _as well_, for people like sky@ who muck about with their own branch. But it is no substitute for a tree-wide version number, and the two schemes are in no way conflicting or in each others way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4097 - trunk/varnish-cache/lib/libvarnish
In message <86r5vp6o5s@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >There is a better solution: the RCS ID of every source file is embedded >in a string in the object, "just like FreeBSD does it". This is a >better solution not only because it does not break dependency tracking, >but because it is more detailed, and covers more than just libvarnish. Provide a patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r4097 - trunk/varnish-cache/lib/libvarnish
>I sent you an email a long time ago explaining why this was wrong, and >gave you adequate time to respond before I committed. Amongst other >things, it breaks the build on non-GNU platforms, and it doesn't work >with releases, source tarballs, or trees checked out with 'svn export' >instead of 'svn co'. I think we have to call a time-out on this one. I originally asked to have the SVN version in there, and if not exactly in those words, then by intention of "just like FreeBSD does it". I certainly don't run a GNU platform and I have not had problems with the code, so I would like it back, until a better solution, which will be very welcome, is offered. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Handling Dynamic Backend Redirects
In message <4a305b14.7080...@caringo.com>, Mike Melson writes: >Is there anyway to catch & follow a 301 redirect from a backend server >to a host that has NOT been defined as a backend in varnish? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: VCL compiler coverage test FAILED
In message <48eba6130906011847x6bea3956nc8951455dfcba...@mail.gmail.com>, Beau Burrier writes: >## v1 VCL compilation failed (as expected) >### v1 CLI STATUS 200 > v1 VCL compilation got 200 expected 106 > TEST FILE: ././tests/v00017.vtc > TEST DESCRIPTION: VCL compiler coverage test: vcc_acl.c >FAIL: ./tests/v00017.vtc Can you try to run that test by hand with a -v flag ? cd .../bin/varnishtest ./varnishtest -v tests/v00017.vtc -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Huge number for N struct vbe_conn
In message <4a05e1020905201057v56d2ff47j7b345e19b5602...@mail.gmail.com>, Cloud e Porteus writes: >Is this something I should be concerned with? No, just ignore it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Huge number for N struct vbe_conn
In message <4a05e1020905200849s3c79f8e3n498b659341e2f...@mail.gmail.com>, Cloud e Porteus writes: >The vbe_conn is flickering between 0-2 and 18446744073709551615. See >varnishstat below. > >Any ideas what might cause this? Yes, it is an unlocked counter, and you had a race updating it: 18446744073709551615 - 2^64 = -1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: accept_fd_holdoff second/millisecond confusion
Fixed, thanks! Poul-Henning In message <180e6a10903201237y1e86bc00vdd7c7b473a996...@mail.gmail.com>, Eden L i writes: >Hi all, > >We ran into a situation where our backend held connections open for so >long that we ran into the open file limit. After clearing up the >backend and ensuring, varnish never came back and we had to restart it >in order for it to start relaying connections again. > >Flipping on debug mode shows the error "Too many open files when >accept(2)ing. Sleeping." which should sleep for 50 milliseconds >(according to param.show). Instead it seems to be sleeping for >50*1000 *seconds* (13 hours). Looking at the code, it appears that >this is either a doc bug or a code bug. I was able to fix the root >issue with this patch: > >--- a/varnish-2.0.1/bin/varnishd/cache_acceptor.c 2008-10-17 >11:59:49.0 -0700 >+++ b/varnish-2.0.1/bin/varnishd/cache_acceptor.c 2009-03-20 >12:16:15.0 -0700 >@@ -228,7 +228,7 @@ >case EMFILE: >VSL(SLT_Debug, ls->sock, >"Too many open files when >accept(2)ing. Sleeping."); >- >TIM_sleep(params->accept_fd_holdoff * 1000.0); >+ >TIM_sleep(params->accept_fd_holdoff * 0.001); >break; >default: >VSL(SLT_Debug, ls->sock, > >Is this the right fix? Should I create a ticket in trac for this? >We're getting around it now by setting the max open file limit and >listen_depth appropriately so that varnish never gets to this point, >but it'd be nice if this was fixed in case we ever accidentally get >here again. >_______ >varnish-dev mailing list >varnish-dev@projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: What's the best way to give feedback for future Varnish features?
In message <4a05e1020903111417w2c175418rd9bcf7a3aef10...@mail.gmail.com>, Cloud e Porteus writes: >Our testing with Varnish is going great, but the features around ESI >that haven't been implemented are going to make things a little bit >harder than I had hoped. I was reading the PostTwoShoppingList and saw >a request (please tell us which!) after more ESI features, but I'm not >sure how to voice my preference. Get a wiki login[1], edit the page. [1] They are free and we happily give them away, but you have to ask so we kan keep spammers away. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: vct.c trunk compilation failure
In message , 19191 9 writes: >Making all in varnishtest >gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include-g -O2 -MT >vtc.o -MD -MP -MF .deps/vtc.Tpo -c -o vtc.o vtc.c >vtc.c: In function 'cmd_shell': >vtc.c:250: error: invalid lvalue in unary '&' critter phk> sed -n 250p vtc.c assert(WEXITSTATUS(system(av[1])) == 0); I have no idea what the trouble is. As a first sanity-check, remove the vtc.c file and run "svn update" to make sure your local copy is not corrupt. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: sendfilev vs writev
The subject of sendfile is compounded by the lack of usable implementations, but the experience data I have gathered so far is that you need to have significant paging activity to backing store, and you still should not enable it for objects smaller than 8-16 VM pages. sendfile really shines with huge files on vastly overcommitted VM, such as ftp.cdrom.com where it was developed. For lots of small files, not so much. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Timeouts
In message <49aabc95.8090...@schokola.de>, Nils Goroll writes: >Theo, > >> http://bugs.opensolaris.org/view_bug.do?bug_id=4641715 >> >> Either that or application level support for timeouts. Given Varnish's >> design, this wouldn't be that hard, but still a bit of work. > >thank you for your answer. I was hoping that someone might had started work on >this, but I understand that this won't be too easy to implement. They can all be implemented in userland, but at a considerable cost in systemcalls required. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug: Child not responding to ping, killing it.
In message <494a2cb6.2010...@octopuce.fr>, Benjamin Sonntag writes: >I continue to investigate this problem. It seems that varnish is really >keeping ESTABLISHED connexions to the backend for a verryve verry verrry >long time : Varnish does not close backend connections, it leaves them open until the backend times them out. How you TCP connections get out of sync between varnish host and backend host I have no idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug : Assert error in exp_timer() | Child not responding to ping, killing it.
Hi Benjamin, I'll look at it.
Just wanted to point this out in the mean time:
> if (req.url ~ "&ttl=") {
>if (req.url ~ "&ttl=001") { set obj.ttl=3600s; }
>if (req.url ~ "&ttl=002") { set obj.ttl=7200s; }
>if (req.url ~ "&ttl=003") { set obj.ttl=10800s; }
>if (req.url ~ "&ttl=006") { set obj.ttl=21600s; }
>if (req.url ~ "&ttl=009") { set obj.ttl=32400s; }
>if (req.url ~ "&ttl=012") { set obj.ttl=43200s; }
>if (req.url ~ "&ttl=015") { set obj.ttl=54000s; }
>if (req.url ~ "&ttl=018") { set obj.ttl=64800s; }
>if (req.url ~ "&ttl=021") { set obj.ttl=75600s; }
>if (req.url ~ "&ttl=024") { set obj.ttl=86400s; }
>if (req.url ~ "&ttl=096") { set obj.ttl=345600s; }
>if (req.url ~ "&ttl=168") { set obj.ttl=604800s; }
>if (req.url ~ "&ttl=672") { set obj.ttl=2419200s; }
VCL supports other units of time than seconds, so for
increased readability, you could write:
set obj.ttl = 1h;
set obj.ttl = 2h;
...
set obj.ttl = 1d;
...
set obj.ttl = 1w;
set obj.ttl = 4w;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Using the test framework for other proxy products
In message <[EMAIL PROTECTED]>, "Dmitry Rubinstein" writes: >Is anyone known to >have tried (and succeeded) using the Varnish test framework in order to >test anything other than Varnish? Not that I know of, but I would be very happy to see the varnishtest tool developed into a more capable and general HTTP-proxy test tool. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: child exited on signal 11
In message <[EMAIL PROTECTED]>, "chen xiaoyong" writes: >gdb -c varnishd.core /usr/local/sbin/varnishd >.. >(gdb) bt >#0 0x000800da5850 in strcmp () from /lib/libc.so.7 >#1 0x0041c9b2 in http_DissectRequest (sp=0x260b113008) at >cache_http.c:500 Can you please go up to this frame and "print *sp" ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: please revise document or code
done. >http://varnish.projects.linpro.no/wiki/VCLExampleLongerCaching >section *How it should work* > "set obj.ttl = 1w;" >maybe changed to > "set obj.ttl = 7d;" >or in function "static double TimeUnit(struct tokenlist *tl) " add "w" Id -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Bug in 1.1.2: Multiple headers stripped (oops)
Hi Adrian,
Good catch.
I created a ticket (#292, now closed) for this because we number
our regression tests by ticket number.
Fixed in #3110.
Poul-Henning
>I found the reason why I hit this bug, but I need some tips to
>understand how to debug what's happening in the VCL code. First, I'll
>explain the bug:
>
>1) My default.vcl is configured to strip the Cookie header in
>vcl_recv like this:
>
>sub vcl_recv {
> if(req.http.Cookie) {
> remove req.http.Cookie;
> lookup;
> }
>}
>
>2) The Connection header sent from the client browser specified that
>the "TE" header should be stripped, and was so marked in position 13
>of http_DoConnection::hp->hdf, indicating that header at index 13
>should be skipped when headers are copied into the backend request.
>
>3) The VCL code ran to strip the cookie header, removed it, and
>shifted the other elements in the array UP one position. The Host
>header followed TE at position/index 14, and became position/index 13.
>
>4) The code for copying/morphing the client request to the backend
>ran, and skipped position/index 13, which was the Host header.
>
>5) Varnish kindly noticed that there was no Host header present in
>the backend connection, and added one of it's own using the IP
>address of the backend server as the content of that header.
>
>6) The incorrect document was fetched for the backend because the
>Host header was not correct.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: waitpid EINTR issue in varnishd (& testcases)
I have committed the EINTR patch and, I hope, fixed the two testcases, please check this and send me your latest solaris patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
Sorry for the comment at the end of my prevous email, got your emails in reverse order here :-) >> Doesn't Solaris have fcntl(F_SETLK) as mandated by POSIX ? >Ah, good catch. That wasn't a patch for Solaris. It was for Linux. >We've run into some issues with flock being more reliable than fcntl >on Linux under high concurrency environments. We're not even remotely close to concurrency, so I'd prefer to stick with fcntl until we see any actual problems. >> Is there a reason to name the shared object .so instead of .o or is it >> just cosmetics ? > >The Sun Studio toolchain barfs on the .o. It "knows better" [...] Ok, fair enough. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message <[EMAIL PROTECTED]>, Theo Schlossnagle writes: >Next pass: > >http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3080.diff You still have the err.h compat stuff, that's not necessary any more, I removed the two uses of err(). Why is the tcp.c patch necessay ? You have not answered my questions about .so and sendfile ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message <[EMAIL PROTECTED]>, Theo Schlossnagle writes: >http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3071.diff OK, I've picked the obvious stuff out. Various questions about the rest: Doesn't Solaris have fcntl(F_SETLK) as mandated by POSIX ? flock() is not a standardized API, and I havn't seen a system yet which supports it, which doesn't also have fcntl(F_SETLK), so I would rather not mess up the source with a pointless check. Do you know for sure that sendfile on Solaris has no reference to the relevant parts of the file when it returns ? Otherwise it is not safe to use. Why is the extra include of necessary in storage_file.c ? Is there a reason to name the shared object .so instead of .o or is it just cosmetics ? In cache_acceptor.c, please implement the "->pass" function which does the port_send() call. Why the initialization in mgt_child.c ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message <[EMAIL PROTECTED]>, Tollef Fog Heen writes: >]] Theo Schlossnagle > >| http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3071.diff >| >| This is cleaned up a bit. Nothing really new, just updated to trunk >| 3071. > >This seems to try to patch bin/varnishd/storage_umem.c which isn't in >the tree, causing it to fail to apply. > >Could you please update the patch? Wait a few hours, I'm cherry picking some of the low-hanging fruit -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Fresh patch for Solaris
In message <[EMAIL PROTECTED]>, Theo Schlossnagle writes: >http://lethargy.org/~jesus/misc/varnish-solaris-trunk-3071.diff > >This is cleaned up a bit. Nothing really new, just updated to trunk >3071. I'll take a peek at it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: " n_smf_large so large" -- varnish-dev Digest, Vol 28, Issue 1
In message <[EMAIL PROTECTED]>, "chen xiaoyong" writes: > >I found that there are reasons for this phenomenon because it is negative. >Not just n_smf_large, including n_smf_frag have this phenomenon too. > > Perhaps some code of storage_file.c should be some more stringent This is a know problem, and basically we decided that perfect statistics were not as important as fast speed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Monitoring varnish
Hi Paul, I have no problems with providing likns on the wiki page if you suggest some text. Poul-Henning In message <[EMAIL PROTECTED]>, Paul Millar writes: >Hi all, > >Just to introduce myself, I'm working on a project called MonAMI. It does >monitoring: aiming to be plumbing between the thing(s) you want to monitor >and the monitoring system itself. More details here: > http://monami.sourceforge.net/ > >A little while ago, someone asked for a plugin for Varnish, which turned out >to be very simple to implement. > >I noticed the wiki page has a few links for monitoring (under Performance >page). > >I have a few questions: > > would it be appropriate to add a link to MonAMI? > > would anyone be interested in checking whether the plugin is gathering > all >the correct information and presenting it correctly? > >For the second part, it would be really good to get feedback from the Varnish >developers as I don't run Varnish myself beyond a simple toy setup, (just to >verify the plugin works correctly). > >Cheers, > >Paul. > > > >___ >varnish-dev mailing list >varnish-dev@projects.linpro.no >http://projects.linpro.no/mailman/listinfo/varnish-dev > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish version question
In message <[EMAIL PROTECTED]>, Olivier Beau writes: >-> Which version of varnish is good for production ? Hi Olivier, We are getting very close to a 2.0 release, so right now the best code we have is the trunk version from subversion. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
GCOV and automated testing
I have spent the evening running a gcov'ed varnishd and writing a couple of test-cases to get more code covered. Unfortunately GCC's gcov does not support shared libraries, I'm not sure I understand why that would be hard, but they don't and I'm not going to spend time on it right now. The lack of shared library coverage means that we only have the central bin/varnishd directory covered and not the VCL compiler and libvarnish libraries. I have not spent time on the other programs (varnishlog, varnishstat etc). For bin/varnishd, We have 62.12% coverage right now, which is pretty decent for just 27 testcases. I'll add more testcases to get better coverage as we go, but I need to work a bit on the tester to make it less tedious. Some bits of code are going to be annoying to test, in particular expiry and grace: even with very short TTLs, the tests will run on timescales of a minute, rather than a few seconds. The plan is to get this stuff running in a crontjob on projects.linpro.no so that the results and statistics can be accessed via the web, but various weird things prevent that right now, so I'll just run it ad-hoc on my laptop. If interested, I have uploaded a copy of the colorcoded results here: http://phk.freebsd.dk/misc/varnish-gcov/bin/varnishd/ Red code has not been executed by any test-case. Testcases are of course welcome :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: HTCP Purger
In message <[EMAIL PROTECTED]>, Artur Bergman writes: >On Jun 23, 2008, at 1:26 AM, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, >> Artur Bergman >> writes: >> >>> I have written an multicast HTCP purger, essentially a perl script >>> that listens to HTCP purges and then purges from the local varnish. >> >> So this is only for HTCP CLR requests ? > >Yes > >> We should probably integrate support for that in Varnish (after 2.0 >> is out the door!) > >Awww, that is no fun :), would you take ifdefed patches? Sure. >> I suggest we add your perl script to the wiki somewhere, as an >> interrim >> workaround. > >Can I get a commit bit and commit it into the tools directory? I hate >having code on a wiki. I'd really prefer to not put temporary tools in the source tree, because that way it gets an official part of the release and all that jazz. How long is it anyway ? Can you mail it to me ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: HTCP Purger
In message <[EMAIL PROTECTED]>, Artur Bergman writes: >I have written an multicast HTCP purger, essentially a perl script >that listens to HTCP purges and then purges from the local varnish. So this is only for HTCP CLR requests ? We should probably integrate support for that in Varnish (after 2.0 is out the door!) I suggest we add your perl script to the wiki somewhere, as an interrim workaround. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
pre-2.0 Trac Ticket Triage
As some of you will have discovered, I am busy going through the tickets in Trac in preparation for 2.0 and have closed all those tickets that I deemed to be of no help to the project any longer. Since the 2.0 release will likely increase interest in Varnish considerably, I want to avoid having 1.x related bugs cluttering the database, when the default answer to any problem with 1.x pretty soon will be: Update to 2.x. Quite a number of tickets I have closed were "heisenbugs" at the time of filing, and the majority of them relates to the two major race conditions we had: kqueue/sess and backend/addr. Obviously I have no iron-clad guarantee that there is not another bug hiding there as well, but I trust my users to open new tickets in that case. Other more planning-oriented tickets have been moved to the wiki. If you feel any of your tickets were closed in error, please don't hessitate to say so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: a problem about _.vsl log file
In message <[EMAIL PROTECTED]>, "chen xiaoyong" writes: >I do a high load test, the test keep one hour. One hour later , varnish >works fine with restarting child process some times but don't write log >file. It don't write anything in _.vsl file after a period of time , even >these keep alive words 'Rd ping ...' ,'Wr 0 200 PONG...' . Prior to this, >it wrote about 16 M .What's wrong ? >Jun 16 08:02:29 bsd_cxy varnishd: Child (1104) said <STV_alloc(), stevedore.c line 71:>> >Jun 16 08:02:29 bsd_cxy varnishd: Child (1104) said << Condition((st) != >NULL) not true.>> You seem to run out of storage. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: about big flv files
In message <[EMAIL PROTECTED]>, Adrian Otto writes : >> There is no intrinsic limit on object size in varnish, but it is not >> particular geared towards such use. The major stumbling block is that >> Varnish will fetch the entire file from the backend before starting >> transmission to the client. > >Have you considered allowing a configuration for streaming a file to >a client while it's being fetched from the backend server? Yes. Do I have a sponsor for it ? No. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: about big flv files
In message <[EMAIL PROTECTED]>, "chen xiaoyong" writes: >Hey guys, > I'm thinking about big flv files in varnishd. Now,many web sites support >video, Typically, these files more than 5M. There is no intrinsic limit on object size in varnish, but it is not particular geared towards such use. The major stumbling block is that Varnish will fetch the entire file from the backend before starting transmission to the client. > I don't konw what's better .. split file in function fetch_straight ? >or do nothing , set up tcp parameters? I'm not sure I understand what you're trying to say here ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Linux performance enhancement
In message <[EMAIL PROTECTED]>, Rafael Umann wri tes: >For us, the ideal solution would be implementing a new thread to >control all this stuff. What do you think about it? I'm reconsidering the accept thread right now for other reasons, so I'll keep this in mind as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Linux performance enhancement
In message <[EMAIL PROTECTED]>, Rafael Umann wri tes: >We've a ticket and would like to hear anything from you: > >http://varnish.projects.linpro.no/ticket/235 Hi Rafael, I don't have linux machines in my lab to test this on, so I was hoping to get Dag-Erling to give it a spin. He is on another project right now, so that is probably not happening. So if you tell me the patch is guaranteed to work better than what's in trunk, I'll commit it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Objects for ESI includes incorrectly miss (Solved / Patch)
Can you try this patch instead:
Index: cache_center.c
===
--- cache_center.c (revision 2639)
+++ cache_center.c (working copy)
@@ -234,7 +234,6 @@
sp->xid = 0;
SES_Charge(sp);
sp->t_open = sp->t_end;
- sp->t_req = NAN;
sp->t_resp = NAN;
WSL_Flush(sp->wrk, 0);
@@ -242,6 +241,8 @@
if (sp->esis > 0)
return (1);
+ sp->t_req = NAN;
+
if (sp->fd >= 0 && sp->doclose != NULL)
vca_close_session(sp, sp->doclose);
if (sp->fd < 0) {
Poul-Henning
In message <[EMAIL PROTECTED]>, JT Justman writes:
>This is a multi-part message in MIME format.
>--020006040805080601000507
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>
>JT Justman wrote:
>> Hi, everyone. I've been doing my best to dig into the bug I opened:
>>
>> http://varnish.projects.linpro.no/ticket/240
>>
>> Basically, every object is inserted, but the second and subsiquent
>> objects always miss.
>
>I have found the cause for the bug, and a potential fix.
>
>In cache_hash.c function HSH_Lookup, there is a ttl check:
>
>if (o->ttl >= sp->t_req)
>
>This test passes on the first ESI and fails on the others. Debugging
>shows that the ttl is correct, but t_req is NAN. It seems that t_req is
>cleared, and needs to be reset somewhere in ESI or the step flow.
>
>My solution is to set sp->t_req = TIM_real() in ESI_Deliver. (See patch).
>
>Not being intimate with the program flow or timing, I don't know what
>other implications this could have. Suggestions?
>
>JT
>
>--020006040805080601000507
>Content-Type: text/x-diff;
> name="cache_vrt_esi-jt_2008-05-20.patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="cache_vrt_esi-jt_2008-05-20.patch"
>
>Index: cache_vrt_esi.c
>===
>--- cache_vrt_esi.c(revision 2635)
>+++ cache_vrt_esi.c(working copy)
>@@ -773,6 +773,8 @@
> obj = sp->obj;
> sp->obj = NULL;
> *sp->http = *sp->http0;
>+ if (isnan(sp->t_req))
>+ sp->t_req = TIM_real();
> /* XXX: reset sp->ws */
> http_SetH(sp->http, HTTP_HDR_URL, eb->include.b);
> if (eb->host.b != NULL) {
>
>--020006040805080601000507
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>___
>varnish-dev mailing list
>varnish-dev@projects.linpro.no
>http://projects.linpro.no/mailman/listinfo/varnish-dev
>
>--020006040805080601000507--
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Mapping VCL variables to internal variables
In message <[EMAIL PROTECTED]>, Charles Curley writes:
>I'd like to set a variable in VCL, and then use it in a modification
>of Varnish. Having added to req.hash with something like:
>
>sub vcl_hash
>{
>if (req.http.Accept-Encoding ~ "gzip") {
>set req.hash +=3D "gzip";
>} else if (req.http.Accept-Encoding ~ "deflate") {
>set req.hash +=3D "deflate";
>}
>}
>
>where do I find that in Varnish itself?
See cache_center.c::cnt_lookup() [search for "VCL_hash_method(sp);"],
and cache_hash.c::HSH_Copy(), HSH_Compare() and HSH_Lookup().
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: sendfile() in varnish
In message <[EMAIL PROTECTED]>, Yutaro Shimamura writ es: >value of varnishstat "Objects sent with sendfile" is almost 0. >0 0.00 0.00 Objects sent with sendfile > >so, write() called. > 37327571 335.20 157.86 Objects sent with write > >when do you use sendfile()? By default: never, there are problems with all sendfile() implementations that prevent them from being usable in Varnish. Only FreeBSD-Current and later FreeBSD-8 will support sendfile(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: mmap'd file vs. swap
In message <[EMAIL PROTECTED]>, "Brian Smith" writes: >My understanding is that Varnish uses a mmap'd file, but it doesn't re-use >the file's contents when it is restarted. Correct. > Why does Varnish use a mmap'd file >instead of just using regular virtual memory (swap) directly? For many small reasons, none of which are particularly good. You can use regular VM by enabling the "malloc" storage method and various people report good success with that. >I would think >that the operating system would be more eager to write the data to the >mmap'd file than it would be to write to swap; on a system where the hot >cache entries can be stored on disk, it would seem that the swap-based >method would be superior. Well, it's slightly more complex than that, we mmap with the MAP_NOSYNC flag so it should be about a wash. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Does Varnish support Pre-loading?
In message <[EMAIL PROTECTED]>, Louis Luo writes: >Hi, > >I have a question regarding pre-loading. When Varnish gets a >response from the backend server, does it do any parsing of the >page? If it does, and if it sees some embedded objects that might >be requested by user browser, will it do the pre-loading? No. The only circumstances where Varnish examines the content for anything, is if you ask for ESI processing to be performed. That's not to say that we could not do it in the future, but there are no plans for it right now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Upload Buffering and x-sendfile
In message <[EMAIL PROTECTED]>, Trey Long writ es: >> Downloading: yes, we buffer. >> >> Uploading: no, we don't. > >Are there plans to offer uploading as well? Since that is the normally >the slower part of the experience. I will put it on the "post-2.0 ideas" page and see if it sticks. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: r2561 - trunk/varnish-cache/bin/varnishd
In message <[EMAIL PROTECTED]>, Anders Nordby writes: >Hi, > >Would it be possible to log free session workspace also? Everything is possible :-) I think we need to reexamine the workspace (full) handling after 2.0 is out, so please add your observations to the "post-2.0 ideas" wiki page and we can hash it out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Upload Buffering and x-sendfile
In message <[EMAIL PROTECTED]>, Trey Long writ es: >Does varnish support upload (and download) buffering? > >Since varnish handles all of the traffic going to and from my host I >was wondering if it buffered the client when they were uploading a >large post body or downloading a large portion of HTML. Downloading: yes, we buffer. Uploading: no, we don't. >Does varnish support x-sendfile type responses? Not at present, but it sounds like it could be useful, I'll add it to the "post-2.0 ideas list". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Move re test method into libvcl
In message <[EMAIL PROTECTED]>, Paul Nasrat w rites: > >On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote: > >> Your patch breaks the convention that compiled code only calls VRT_* >> functions, you need to keep a VRT_re_test() wrapper around for that >> reason. > >I'm not sure that's breaking that convention - the call chain is in >vcc_regexp and it's a test before generating the C for the compiled >vcl binary. Maybe I'm misunderstanding what you mean by "compiled >code" in this case - I think that you mean that any generated C from >vcl should only call VRT_* functions, which this patch doesn't change, >as it's a validity check before code generation occurs. Correct, but your patch removes a VRT_ function which the generated code needs in order to run... >I looked on http://varnish.projects.linpro.no/wiki/DeveloperResources >but didn't see a mention of this convention - is there another place I >should be looking so that I can understand the coding conventions of >the project? They're not well documented, sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Move re test method into libvcl
In message <[EMAIL PROTECTED]>, Paul Nasrat w
rites:
>> The attached patch against trunk moves and renames the re_test
>> method into vcc_string.c so libvcl could be used outside of varnishd.
>-int
>-VRT_re_test(struct vsb *sb, const char *re, int sub)
>-{
Your patch breaks the convention that compiled code only calls VRT_*
functions, you need to keep a VRT_re_test() wrapper around for that
reason.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish consuming too much memory?
In message <[EMAIL PROTECTED]>, Jodok Batl ogg writes: >what is varnish's disk file exactly for? is varnish using "real" =20 >memory only and "swapping" to its own file? it is the backingstore to which the kernel can page the virtual memory which Varnish uses. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish consuming too much memory?
In message <[EMAIL PROTECTED]>, Jodok Batl ogg writes: >or is it really true that i need dedicated boxes for caching only? If your operating system has a VM system worth its salt, no. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish consuming too much memory?
In message <[EMAIL PROTECTED]>, Jodok Batl ogg writes: >>> i'm wondering how varnish determines how much memory it should >>> consume... >> >> It uses all memory it can for caching. > >- is there a way to limit it? no. >i'd like to assign the 4 varnishes running on this box 3 GB each and >leave 4GB for linux disk/nfs cache Why are you running multiple varnishes on the same box ? >- what effect has the size of the VARNISH_STORAGE_SIZE? That sets the size of the file varnish maps for storage, and in a sort of way limits the amount of memory varnish can use, but also severely limits your hit-rate when it runs full. >is this cache persistent? when are objects moved from memory to disk? No. Whenever the kernel VM subsystem decide it should happen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish consuming too much memory?
>i'm wondering how varnish determines how much memory it should >consume... It uses all memory it can for caching. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching issue
Is this FAQ fodder ?
In message <[EMAIL PROTECTED]>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=
writes:
>"Poul-Henning Kamp" <[EMAIL PROTECTED]> writes:
>> You could try the following in vcl_recv:
>>
>> if (req.http.accept-encoding) {
>> set req.http.accept-encoding =3D regsub(
>> req.http.accept-encoding,
>> "gzip, *", "gzip,");
>> }
>>
>> to get rid of the space(s), but it is not guaranteed to get all cases.
>>
>> Alternatively, the more brutal:
>>
>> if (req.http.accept-encoding ~ "gzip") {
>> set req.http.accept-encoding =3D "gzip";
>> } else {
>> unset req.http.accept-encoding;
>> }
>>
>> Will get the desired effect in all cases, provided your backend does
>> not attempt deflate as fallback.
>
>A slightly more complex solution, to cover all bases without losing
>functionality:
>
>set req.http.accept-encoding =3D regsub(req.http.accept-encoding,
>"^ *gzip, *deflate *$", "gzip,deflate");
>set req.http.accept-encoding =3D regsub(req.http.accept-encoding,
>"^ *deflate, *gzip *$", "gzip,deflate");
>
>This should take care of >99% of cases; I don't know of any browser that
>supports only one of the two, or supports anything *but* those two.
>
>However, Apache only supports gzip, so Poul-Henning's solution is
>sufficient in this case.
>
>DES
>--=20
>Dag-Erling Sm=C3=B8rgrav
>Senior Software Developer
>Linpro AS - www.linpro.no
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching issue
My guess is that Vary processing is getting you:
Firefox sends:
12 RxHeader c Accept-Encoding: gzip,deflate
which goes to the backend:
15 TxHeader b Accept-Encoding: gzip,deflate
which the backend uses:
15 RxHeader b Vary: Accept-Encoding
15 RxHeader b Content-Encoding: gzip
Then IE sends:
12 RxHeader c Accept-Encoding: gzip, deflate
Which you will notice, has a space between "gzip," and "deflate"
thus not matching the Vary string already on record in the
cached object.
Varnish requires exact matching, the logic to find out if they
match semantically is not trivial to implement.
You could try the following in vcl_recv:
if (req.http.accept-encoding) {
set req.http.accept-encoding = regsub(
req.http.accept-encoding,
"gzip, *", "gzip,");
}
to get rid of the space(s), but it is not guaranteed to get all cases.
Alternatively, the more brutal:
if (req.http.accept-encoding ~ "gzip") {
set req.http.accept-encoding = "gzip";
} else {
unset req.http.accept-encoding;
}
Will get the desired effect in all cases, provided your backend does
not attempt deflate as fallback.
And finally, giving up on gzip'ing in toto, which is probably a bad choice:
unset req.http.accept-encoding;
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching issue
In message <[EMAIL PROTECTED]>, Shain Miley writes: >I did run varnishlog from the command line without any arguments...it >could not reach the webserver because I turned it off...I was hoping to >setup varnish in such a way that if the webserver fails...varnish will >keep serving pages. > >For example: if user A requests index.html and varnish caches it...then >5 minutes later user B requests index.html (and varnish still has it in >the cache) then it should just serve up the file..without ever going to >check the backend. I know that it might not be the number one intended >use for varnish...but that is what I am trying to do...any suggestions? That's certainly possible, but you need to get it set up right. By default Varnish will respect whatever the backend says about caching, and in this case you want to override that. I don't know if your backend said "do not cache this" or "cache only 15 seconds", but whatever it is, you need to override it in VCL. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Caching issue
In message <[EMAIL PROTECTED]>, Shain Miley writes: > 12 VCL_call c miss > 12 VCL_return c fetch Varnish didn't find a cache-hit and I guess you didn't log the backend transaction here, so I don't know what the backend told us. > 12 Length c 455 > 12 VCL_call c deliver > 12 VCL_return c deliver > 12 TxProtocol c HTTP/1.1 > 12 TxStatus c 503 > 12 TxResponse c Service Unavailable It looks a lot like it didn't even get hold of the backend... Possibly because it couldn't resolve the name of it or because it didn't have a route to the backend. It looks like you ran varnislog with a -c argument, try leaving that out so that the backend transaction also gets logged. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Load Balancing Algorithms in VCL
In message <[EMAIL PROTECTED]>, Shiraz Kanga writes: > >Will it be possible to implement custom Load Balancing algorithms in >VCL? There are numerous algorithms that can be used to distribute load like >Round Robin, Weighted Round Robin, Least Connections, Fastest Response, >Most Bandwidth, etc. The plan is to implement such "directors" in C (we already have "random") and I'm not convinced that doing it in VCL makes much sense, but can be persuaded otherwise by good arguments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Adjusting the parents watchdog timer
In message <[EMAIL PROTECTED]>, Adrian Otto writes : >As an experiment, it >might be interesting to just dedicate one additional thread to >responding to something just like PING/PONG in addition to the PING/ >PONG already there, and use a separate client to generate checks. The cache-process already dedicates a thread to handling the CLI pipe, so that wouldn't prove anything. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Adjusting the parents watchdog timer
In message <[EMAIL PROTECTED]>, Dave Cheney write
s:
>I haven't looked at the PING code but i'm guessing its a connect, a
>dummy request and a close, so thread starvation or mutex contention
>could cause a blockage.
Not quite.
The master process has a pipe to the client for issuing commands
(purge, load vcl etc) and every $ping_interval it sends a "PING"
message that simply should elicit a PONG reply to show that the
child is responding.
You can also do this at any other varnish CLI:
ping
200 15
PONG 1204065967
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Adjusting the parents watchdog timer
In message <[EMAIL PROTECTED]>, Dave Cheney write s: >Adjusting the timeout to 15 seconds has keep a machine which was >previously restarting the child up to 4 times a day stable for over 24 >hours. > >Clearly the watchdog timeout exists for a reason and adjusting it this >high is only a placebo. I'll try reducing the timeout slowly to >figure out exactly what is causing the child to timeout. The default value is very much a number pulled out of thin air, and it is certainly not inconceiveable that it needs tweaking. In general I would expect 5 seconds to be enough, and I would like to find out why they are not. It may help if you plot (using munin ?) the activity on the machine and see if you can correlate the hickups with activitity. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Backend syntax changed
In message <[EMAIL PROTECTED]>, Dave Cheney write
s:
>Hi,
>
>I compiled r2505 from svn but the backend syntax has changed since
>this page
>
>http://varnish.projects.linpro.no/wiki/Backends
>
>was written. Can anyone please supply with the new round_robbin syntax
>for the following old style config
>
>backend_round_robin default {
> set backend.set = {
> { "172.16.0.72", "http" }
> { "172.16.0.73", "http" }
> };
>}
Hi Dave,
I have not converted the round_robin code yet, but you should be get
roughly the same effect with a 2 part random:
director default random {
{
.backend = { .host = "172.16.0.72"; }
.weight = 1;
}
{
.backend = { .host = "172.16.0.73"; }
.weight = 1;
}
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Apparent bug in exp_prefetch()
In message <[EMAIL PROTECTED]>, Adrian Otto writes
:
>Hello,
>
>I'm new to varnish but I think I've found a bug and I'm seeking help
>to confirm it. This is varnish 1.1.2 on RHEL4. I'm trying to use this
>in my VCL:
>
>sub vcl_timeout {
> fetch;
>}
This is not yet supported, I'm still working on the code.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: development efforts on the Solaris side.
In message <[EMAIL PROTECTED]>, Theo Schlossnagle
writes:
>> mgt_vcc.c:
>> The suffix shouldn't matter to dlopen(), please explain ?
>> White-space and {} spam.
>> Adding the c-compiler command to the error message is bound
>> to make it overflow the linewidth.
>
>It isn't dlopen, it is the compiler linker chain that fails on
>Solaris. While it is arguable that it is a SunStudio bug, I think the
>limitation is extremely unnecessary and annoying -- but alas. The
>work around does not break gcc.
Then just specify a compiler parameter as:
"cc -bla -bla -o %o.so %s && mv %o.so %o"
>> -/* Note: intentionally not IOV_MAX */
>> +#ifdef IOV_MAX
>> +#define MAX_IOVSIOV_MAX
>> +#else
>> #define MAX_IOVS (HTTP_HDR_MAX * 2)
>> +#endif
>>
>> Which bit of "intentionally" didn't you understand ?
>> Have you examined the value of IOV_MAX, looked at where
>> this is used and measured the impact ?
>
>I understood intentionally. I also understood that it doesn't work on
>Solaris. On Solaris, IOV_MAX is the maximum number of elements that
>can be passed to writev(2), using a larger number will fail.
I will fix this to use IOV_MAX if it is less than the desired size.
>> cache_acceptor.c
>> Under no circumstances should #ifdef HAVE_PORT_CREATE be
>> necessary here. If a new method is necessary for the
>> acceptors, so be it.
>
>Completely agreed. I noted that it was a hack in a previous email.
>I'd like that add the ping stuff as a function into each acceptor so
>they can have their own approach to waking the acceptor thread up.
>Solaris' portfs is much more like kqueue than epoll and support more
>than just filedescriptors. It allows user-space eventing, so it is
>really easy to have one thread just say "dude, wake up" to another
>waiting in port_get(n). People tend to have strong preferences to
>adding functions to structures in C, so I was pretty confident that I
>should propose the design before implementing it, as it would likely
>be redone.
I'm not sure I see what the point is here ?
I'll pull in the KEY_RESIZE #ifdef also.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: development efforts on the Solaris side.
In message <[EMAIL PROTECTED]>, Theo Schlossnagle
writes:
>> Can you mail me a link to the patch ?
>
>http://lethargy.org/~jesus/misc/varnish-solaris-trunk-2328.diff
Ok, various comments:
The autoconf stuff and the #inclusion of "varnish_config.h" all over
the place you will have to negotiate with DES, I only do C code.
lib/libvarnish/time.c:
I don't like #ifdefs like that in the middle of functions.
The appropriate way is to add a compat function in
libvarnishcompat.
flock/fcntl-locks you're already talking with DES about.
curses:
What exactly is the semantics of KEY_RESIZE ?
mgt_vcc.c:
The suffix shouldn't matter to dlopen(), please explain ?
White-space and {} spam.
Adding the c-compiler command to the error message is bound
to make it overflow the linewidth.
VCL_WaitForActive()
Need to look at that in more detail. I deliberately tried
to limit varnish to only use mutexes for locking, so introducing
semaphores just for this seems somewhat silly.
storage_umem.c
I'm not sure I see much point in this. The main advantage of
umem is SMP localized storage management, and the Varnish
objects are exactly not local to any one CPU.
Benchmarks could possibly convince me otherwise.
#include
This may be a portability issue where the easiest way to fix
is to avoid it.
sendfile():
Does the solaris sendfile guarantee that storage is no longer
touched when it returns ? Otherwise it's as little use as
the FreeBSD and Linux versions.
/* pick a stevedore and bump the head along */
/* XXX: only safe as long as pointer writes are atomic */
+/* jesus: dear god, are you crazy? */
stv = stevedores = stevedores->next;
God to Jesus: No I'm not.
-/* Note: intentionally not IOV_MAX */
+#ifdef IOV_MAX
+#define MAX_IOVS IOV_MAX
+#else
#define MAX_IOVS (HTTP_HDR_MAX * 2)
+#endif
Which bit of "intentionally" didn't you understand ?
Have you examined the value of IOV_MAX, looked at where
this is used and measured the impact ?
cache_acceptor.c
Under no circumstances should #ifdef HAVE_PORT_CREATE be
necessary here. If a new method is necessary for the
acceptors, so be it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: development efforts on the Solaris side.
In message <[EMAIL PROTECTED]>, Theo Schlossnagle writes: >Hi guys, > >I'd really like to be able to contribute some of the improvements >we've made to varnish back. Is there a way I can get access to >commit. I'd be happy to stay in my own branch. My current patch set >is unwieldy and I'm very tempted to just start my own repos... That, >of course, seems silly. I've fixed up (removed) some of the gccism in >favor or more portability (#include over -include). I've fixed a few >bugs, made the VCC line a but smarter and more accepting of non gcc >compiler, I've added a portfs acceptor and built a storage_umem >allocator facility that rides on Solaris' excellent libumem (highly >scalable allocator) which we also ported to run on Linux and FreeBSD >(and Mac OS X): https://labs.omniti.com/trac/portableumem > >Next steps? Can you mail me a link to the patch ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish using 100% cpu
In message <[EMAIL PROTECTED]>, Jodok Batlogg writes: >not yet, where can i find it? Try trunk. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: varnish using 100% cpu
In message <[EMAIL PROTECTED]>, Jodok Batlogg writes: >hi, > >we're using varnish in production and have roughly every 10 days the >problem that varnish is running at 100% CPU (but requests are beeing >served "normally"). > >today i've been able to attach gdb to the running process, look a >little bit around and generate a core dump. >if someone wants to help getting this bug solved - the core dump is at >http://download.lovelysystems.com/public/core.1237 Which version are you running ? I fixed a cpu-eating bug in the telnet/CLI code a few days ago, do you have the patch for that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Support Cache-Control no-cache/private as per RFC2616 ?
In message <[EMAIL PROTECTED]>, Mark Nottingha m writes: >On 2007/11/21, at 4:54 AM, Poul-Henning Kamp wrote: >> The only truly precise way to characterize varnish, IMO, is "A >> webserver that uses HTTP to get at its content". > >This is a good characterisation. It would probably be more correct to >say "gateway" than "webserver", but most casual readers won't know >what that means. Well, I specifically use "webserver" because Varnish should be RFC2616 compliant as one, seen from the clients side. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Support Cache-Control no-cache/private as per RFC2616 ?
In message <[EMAIL PROTECTED]>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rg rav?= writes: >The closest there is to a formal description of what Varnish is and >how it should behave is the Edge Architecture Specification, which >unfortunately is far less impressive than its title. ESI is indeed not impressive, but it is also aimed at a very narrow market which Varnish is not (3rd party but non-adverserial caching) The only truly precise way to characterize varnish, IMO, is "A webserver that uses HTTP to get at its content". That description on the other hand, is so general as to be almost without meaning. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Support Cache-Control no-cache/private as per RFC2616 ?
In message <[EMAIL PROTECTED]>, "BUSTARRET, Jean-francois" writes: > >Yet http://varnish.projects.linpro.no/wiki/FAQ says "Varnish was written = >from the ground up to be a high performance caching reverse proxy." = >Varnish is a cache, and should follow HTTP/1.1 RFCs. You're welcome to your opinion :-) We belive we have good arguments for the choices we have made, and as development continues, it is not inconceiveable that Varnish might some time in the future grow a "act like an RFC2616 cache", should somebody code the necessary changes or sponsor somebody else to do so. In the mean time, we try to get the maximum bang out of Varnish and think we have made the correct call on this point. One thing we have heard severalt times is that content providers want to be able to use Cache-Control for client instructions and not penalize their Varnish performance with its settings. There is a draft floating around which defines a "Surrogate-Control" along the lines of "Cache-Control" but it seems to have little backing and even less use. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Large file cache problem
In message <[EMAIL PROTECTED]>, Gea-Suan Lin writes: >I found that Varnish will download a file from backend, and then send >it to client. If the file is large, it might take some time to download. >And squid will "stream" it to client. > >Is there any configuration I can do with ? Not yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: W3C Extented Log Format
In message <[EMAIL PROTECTED]>, "Cale b Anthony" writes: >On 10/24/07, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: >> >s-ip (server ip) >> >s-port (server port) >> >> We don't log these right now, but we can do that relatively easily, >> they need to go into the SessionOpen log record. >> >> Open a ticket in our track record about this. > >Thanks for the quick reply. > >I have created an account on Trac. My username is "Caleb". Give me >access, and I'll create a ticket about the s-ip s-port issue. Done. >Both the W3C and Microsoft documentation states that this is the time >taken for the transaction to complete. So it looks like the total time >from connection open to response sent would be good for this field. >Using varnishlog -i ReqEnd I get the following information: > >15 ReqEnd c 1517105057 1193239772.341682196 1193239772.460953236 >0.000179291 0.119204998 0.66042 Then you want the difference between the two timestamps, in this case: 1193239772.460953236 - 1193239772.341682196 = .119271040 [s] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: W3C Extented Log Format
In message <[EMAIL PROTECTED]>, "Cale b Anthony" writes: >s-ip (server ip) >s-port (server port) We don't log these right now, but we can do that relatively easily, they need to go into the SessionOpen log record. Open a ticket in our track record about this. >cs-bytes (client to server bytes) header or body (or both ?) bytes ? Right now we don't support client to server bytes any other way than during pipe processing, so we don't even count this number. Cecilie is working on POST in the pass code, so that would give us a number to put here. >time-taken (time the action took in milliseconds) Do they say where this should be measured exactly ? We have four timestamps you can choose from: connection open request received response ready response sent and they're all represented in the ReqEnd record somehow. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: SES_Delete (#162)
In message <[EMAIL PROTECTED]>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rg
rav?= writes:
>What it certainly *doesn't* do in any way, shape or form is guarantee
>that the session no longer has an object or VCL associated with it.
>In other words, this assertion will fail every time the client closes
>the connection before the completion of the current request.
It should absolutely not under any circumstances have an object associated,
as soon as an object is delivered, the session must deref the object and
it certainly should not have an object while in the care of the acceptor.
The sessions borrow their vcl from the worker thread, which keeps a
ref until it dies (or notices a new active VCL). The code is in cnt_recv()
and cnt_done() respectively:
cnt_recv():
VCL_Refresh(&sp->wrk->vcl);
sp->vcl = sp->wrk->vcl;
sp->wrk->vcl = NULL;
cnt_done():
if (sp->vcl != NULL) {
if (sp->wrk->vcl != NULL)
VCL_Rel(&sp->wrk->vcl);
sp->wrk->vcl = sp->vcl;
sp->vcl = NULL;
}
So there is no way that a session should be able to end up in the
acceptor with a vcl either.
To get to the acceptor, the session passes through the acceptor
pipe, written by:
void
vca_return_session(struct sess *sp)
{
CHECK_OBJ_NOTNULL(sp, SESS_MAGIC);
AZ(sp->obj);
AZ(sp->vcl);
assert(sp->fd >= 0);
assert(sizeof sp == write(vca_pipes[1], &sp, sizeof sp));
}
Feel free to pierce this logic.
I have had asserts show me, that there were no obj or vcl in
vca_return_session() and they were present on the receiving side
of the pipe in kqueue_acceptor.
I have not been able to find an explanation for that, that doesn't
involve a hardware or kernel error.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | 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@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Hash Function
In message <[EMAIL PROTECTED]>, "Luke Macpherson" writes: >My understanding from a cursory read of the source is that Varnish is >using crc32 as a hash function. The hash code, function as well as data structure is a pluggable module in Varnish, so changes in this area is anticipated. The default "simple" hasher, uses a single hash-table and crc32 for and it doesn't work too badly for even quite large workloads. The important property of the hashing module in Varnish is that the hashing function distributes fast at the first level of locks, so that other threads can get in as well. The actual length of the hash-buckets seems to be of little consequence. At least so far. Some day when the requirement (and time) manifests itself, I want to add a hash module which scales to infinity (ie: 64 bits) and that will probably be an adaptive multi-level tree structure of hashes with MD4 as a distributor function. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Varnish Style Guide
In message <[EMAIL PROTECTED]>, "Luke M acpherson" writes: >Is there any documentation of code style for varnish? > >I did see an early post on naming conventions, but the code base >doesn't actually reflect that early description any more, and some of >the conventions I've not been able to reverse-engineer (I find the >capitalization strategy particularly confusing). The starting point is FreeBSD's style(9) manual page, and yes, the capitalization is not consistent. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
Re: Error
In message <[EMAIL PROTECTED]>, "sure ndar p" writes: > >Hi, >When i compile the code,i got this error >"Expected positive indentation". > >what is the actual error it is? file and line information, please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | 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@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev
