Re: Number of cached objects
In message c98122ba1003091910y6de964beue598f69b406a9...@mail.gmail.com, Brad Schick writes: Its not clear to which field is the number of cache entries. Perhaps shm_records? You want n_object -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: locking SHMFILE in core failed: Cannot allocate memory
In message 3e3a0c981002231659h2181697bpd8b1ebf97707a...@mail.gmail.com, Tami Lee writes: When I start Varnishd, I got the error below. Varnish still seems to work, but what does the error message mean? More importantly, what may not be working? Notice: locking SHMFILE in core failed: Cannot allocate memory Don't worry about it, it's just noise. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Varnish CLI user feedback, please.
I'm looking at the CLI/varnishadm stuff right now, and would like some feedback from you guys... Right now (in -trunk) we have these possible CLI configurations: A) no CLI at all. B) CLI on stdin (-d) C) CLI on TELNET (-T) D) CLI on call-back (-M) If the -S option is given, -T/-M CLI connections will require challenge/response authentication. (Before 2.1, I plan to add -S support to varnishadm, and maybe some API functions to access the CLI in libvarnishapi.) Which of these modes do you actually use ? Are more modes needed ? Any other insights on the CLI interface ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: health check path doesn't change after VCL reload (2.0.6)
In message b6b8b6b71002241315w1c62022t1bf941d6f2cac...@mail.gmail.com, John N orman writes: Still, the VCL indicated as active had a different path for the health check. Hopefully both got probed ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 4b7bc0d5.7080...@schokola.de, Nils Goroll writes: That's another piece of autocrap stuff that needs fixed... Do you want me to do it? Send patches! -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002170310g565a26d8s98170fcebb9b2...@mail.gmail.com, Paul Wright writes: On 17 February 2010 10:57, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I have pulled the latest revision and can confirm that unlink(/) failed as expected. I ran it briefly and saw this panic: Child (28554) died signal=3D6 Child (28554) Panic message: Assert error in http_copyheader(), cache_http.c line 647: Condition(n to-shd) not true. Sounds like you got too many headers from the backend, if so, consider increasing the parameter 'http_headers' -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002150322l57063a9ds98143093910c2...@mail.gmail.com, Paul Wright writes: On 13 February 2010 20:26, Poul-Henning Kamp p...@phk.freebsd.dk wrote: I'm still not 100% convinced that EBADF is not me screwing something up, so I have gone over the poll-waiter and made it even more paranoid and conservative than before. Can I get you to give -trunk r4561 a swing, and see if that changes anything ? I just ran r4561 for about 10 minutes and observed the same error with a client halfway through a KeepAlive session: Is there any way (dtrace ?) you can log which systemcalls happen, I would really like to be 100% sure that varnish does not close that socket by mistake... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 4b793e98.2020...@schokola.de, Nils Goroll writes: Poul-Henning, Just an idea from checking differences between the code I use and trunk: In cnt_wait, shouldn't we check pfd[0].revents for POLLERR and POLLHUP? Could it be that Solaris assumes that delivery an error once should suffice, so further use of the fd will return EBADF? That was one of my theories, but it does not fit the facs of the case, and it would violate POSIX, which I doubt Solaris would do... The best contender is still that varnish closes the fd by mistake, but I'll be damned if I can find where... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 89581.1265999...@critter.freebsd.dk, Poul-Henning Kamp writes: In message 282e72051002120949u56eb6914mbd55e5a355931...@mail.gmail.com, Paul Here's a snippet from varnishlog for one of these panics (also attached to this email in case line wraps wreck formatting): Interesting! This time the EBADF comes in the original worker thread, before we hand the file descriptor over to the waiter, eliminating that entire ball of wax from the picture. I'm still not 100% convinced that EBADF is not me screwing something up, so I have gone over the poll-waiter and made it even more paranoid and conservative than before. Can I get you to give -trunk r4561 a swing, and see if that changes anything ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Aiming for Varnish 2.1
Thanks to our new energy, we have been able to chase down and close a fair number of weird bugs in Varnish, and right now, -trunk looks pretty solid. Subject to the quantum-murphy-o-meter freaking out, I think we are ready to cut a 2.1 branch, maybe even in time for VUG2. This will become the new -stable release branch, and it is probably a good idea for you to plan to migrate to it at some point. I really appreciate the effort some of you already are throwing at crashing -trunk for me, and urge everybody to get in on that game before the release. I can't offer your cheques signed by Donald Knuth, for each bug you find, but I really do appreciate the effort and quality of bug-reports. To be honest, I have somewhat lost track of what has and what hasn't been merged into 2.0, so I skimmed the 25k+ line diff between -trunk and 2.0 and noticed: * A lot less bugs. * Dynamic minimum sizing of per-object storage. * Max number of HTTP headers a parameter. * -hcritbit the default, should be faster, self sizing. * -spersistent still aprototype, but it might be usable for a limited number of setups already now. * saint-mode. It's complicated to explain, but smart. * Authentication of CLI connections. * New expressive ban/purge syntax * ban-lurker to try to keep purge-list length under control * New hash director, distributes backend traffic according to the object hash-key. * New client directors, distributes backend traffic according to client IP#. * Separate VCL access to request sent to backend, reply from backend. * Elimination of magic numbers in varnishtest testcases (+23 new tests) * (More?) correct handling of HTTP/1.0 - HTTP/1.1 headers. + probably a lot of details I overlooked. + whatever bugs we manage to fix before 2.1 is cut. On the down-side: * -spersistent still not done. * Various solaris issues still not resolved. * You need to change your VCL at bit. * We still have a half hundred open tickets. * Some new bugs, didn't see them, but I know they are there. Enjoy, 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002120417w6c8ce8bcha2c96a809e9ba...@mail.gmail.com, Paul Wright writes: If so: how long time elapses between the ACK and the RST ? 0.031s Interesting. Can you try to run with this patch: http://phk.freebsd.dk/misc/poll.patch And see what values it puts in your varnishlog for these connections ? I wonder if Solaris has some kind of I already told you it were closed once logic... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002110739y50bc0b16j687bf75692f42...@mail.gmail.com, Paul Wright writes: I've had a go at 1.) and have two verbose `snoop` traces during child panics. I used sp.client from the backtrace to find out the port number and then looked at just matching packets. From my (limited) Wireshark comprehension they show the client establishing a connection to Varnish, issue a GET, receive the response (200 OK). Then the client sends a RST packet, from there the connection disappears. Would this cause the child to panic? Questions: Does the RST arrive after the entire response is sent ? If so: does the client ACK the response, before the RST ? If so: how long time elapses between the ACK and the RST ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: ESI include inserts garbage code
In message 4b748e05.3060...@bugbyte.nl, Bert-Jan de Lange writes: Hi folks, I'm experimenting with ESI and something weird has come up: varnish is adding garbage code to the output. What is the garbage that you are seing ? If it a separate line with hex digits, then it is the chunked encoding we use to transmit ESI with to HTTP/1.1 clients... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: ESI include inserts garbage code {SOLVED]
In message 4b749cb9.6080...@bugbyte.nl, Bert-Jan de Lange writes: The checksums are gone now. Well, they're not really checksums, they are byte counts, but... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Maintenance message
In message 2caa2d26-7b56-4402-88e1-559361135...@gmail.com, Brad Schick writes
:
I have a varnish server working well, but I'd like to have a standby
server that does nothing but server up Sorry we are preforming
maintenance. My thought was to write VCL code to check the health
of the director, and if that was bad use a different server (something
like the example below). But that doesn't work. Any suggestions?
Actually, it just takes a bit of a detour:
sub vcl_recv {
set req.backend = cluster;
if (!req.backend.healthy) {
set req.backend = maint;
}
}
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Error compiling VCL when using '% in regexp
In message dd929cd9109b0a4d8c34b732a6d35cc43c403...@mbx03.exg5.exghost.com, N
aama Bamberger writes:
I already tried using the escaped %25.
The compilation succeeded, but the regexp didn't find a match in the
problematic URLs:
# If the URL ends with % and one digit (a broken hex value) - remove
the last 2 characters.
if (req.url ~ (.*)%25[0-9a-fA-F]$) {
set req.url = regsub(req.url, (.*)%25[0-9a-fA-F]$, \1);
}
I just whipped up a varnishtest case, and it seems to work in -trunk:
test random test
server s1 {
rxreq
expect req.url == /foo
txresp
} -start
varnish v1 -vcl+backend {
sub vcl_recv {
if (req.url ~ (.*)%25[0-9a-fA-F]$) {
set req.url = regsub(req.url, (.*)%25[0-9a-fA-F]$,
\1);
}
}
} -start
client c1 {
txreq -url /foo%a
rxresp
} -run
### c1 Connect to 127.0.0.1:17621
### c1 Connected to 127.0.0.1:17621 fd is 9
c1 txreq| GET /foo%a HTTP/1.1\r\n
c1 txreq| \r\n
### c1 rxresp
### s1 Accepted socket fd is 4
### s1 rxreq
s1 rxhdr| GET /foo HTTP/1.1\r\n
s1 rxhdr| X-Forwarded-For: 127.0.0.1\r\n
s1 rxhdr| X-Varnish: 1001\r\n
s1 rxhdr| Host: 127.0.0.1\r\n
s1 rxhdr| \r\n
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002100305m5d7a0d1fj3a1afac6ea7dd...@mail.gmail.com, Paul Wright writes: Hi Paul, We have a number of tickets on this issue already (626,615,588). The problem is that EBADF return indicates that Varnish by mistake has closed a file descriptor, that should still be open. The alternative explanation, that Solaris can return EBADF because the other end closed a TCP connection, does not seem to have any support in Solaris documentation. We are trying to get a Solaris box running so we can figure this out once and for all. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Child panics on OpenSolaris
In message 282e72051002100615x701a37a8o416c9af6d1d7f...@mail.gmail.com, Paul Wright writes: Thanks for the explanation of what's going on. Looking at those tickets there are suggestions to try the poll waiter which we're already using - are there any further tests we could try to help narrow down this issue? I'm happy to assist trying out patches. I can see three ways to nail this issue: 1. Catch a tcpdump, when it happens, showing that the client side did close, and Solaris (incorrectly) returns EBADF. 2. Catch a ktrace/systrace/dtrace, when it happens, that show that Varnish incorrectly closes the fd. 3. Setup some synthetic test to show that solaris returns EBADF when it shouldn't If either of those are in your reach, by all means go for 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish Software
In message 52220de01002090612t6617242eleb63812bfd2ce...@mail.gmail.com, Per B uer writes: Therefore RL has decided to form a separate company around Varnish: Varnish Software AS. The company will initially consist of Tollef Fog Heen, Kristian Lyngstøl and myself, all moving from Redpill Linpro. Welcome Varnish Software! Although there has never been doubt about Redpill-Linpros heart being the right place for Varnish, it has never really fit that well into the RL organization. A new small focused company sounds just like what the doctor ordered :-) As you have guessed by now, I knew about these plans already, and no, I will not be joining Varnish Software. I will continue my own little company, where, I develop Varnish, funded by the Varnish Moral Licenses and do other stuff for my other customers. Per has indicated that Varnish Software will pick up a Varnish Moral License, to replace my current arrangement with RL, so the amount of time I have available for Varnish is unchanged. This is a good time to officially thank RL, and now Varnish Software, for running our the Varnish project server for the Varnish Project: Much appreciated! This new development, does give me an excuse for growing up the project a bit, so I have, hopefully for the last time, used my dictatorial powers and appointed: Arther sky Bergman (users) Kristan Lyngstol (commercial) Poul-Henning Kamp (developers) to the Interrim Varnish Governing Board, which is tasked with coming up with some sort of sensible project bylaws, ready for ratification no later than VUG3. (mail us your ideas, input etc) So, back to the keyboards and see you at VUG2 in Amsterdam (http://www.varnish-cache.org/wiki/VUG2) Poul-Henning (Until further notice: Defacto Ruler of The Varnish Project) -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishlog not behaving as expected (by me)
In message 871vgwc5vk@qurzaw.linpro.no, Tollef Fog Heen writes: ]] Poul-Henning Kamp | In message 4b6960da.6080...@bmjgroup.com, Alex Hooper writes: | |/usr/local/bin/varnishlog -o RxURL ^wp-admin$ | | This says you want to *O*mit all RxURL lines. The regexp argument | should have generated an argument error. No, it doesn't: -o Group log entries by request ID. This has no effect when writing to a file using the -w option. I must have been sleepy, I thought of -x sorry for the confusion. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Error compiling VCL when using '% in regexp
In message dd929cd9109b0a4d8c34b732a6d35cc43c34e...@mbx03.exg5.exghost.com, N
aama Bamberger writes:
I get this error:
Invalid hex char in %xx escape
(input Line 107 Pos 28)
if (req.url ~ (.*)%[0-9a-fA-F]$) {
---###--
Try: %25
One of the decisions I had most trouble with, was deciding which
kind of escape-mechanism we wanted for strings in VCL.
In the end I settled for URL-%xx encoding, because I pressume
webmasters know it, and because it avoids a nightmare of back-slashes
in regexps.
I'm not 100% convinced that was the perfect decision...
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: obj.cacheable vs expires headers?
In message 4b707314.5090...@gmail.com, Luc Stroobant writes: obj.ttl seems to be zero indeed, but I still don't get how his would make the request cacheable. At least it's not the behaviour one would expect? We distinguish between can be cached and how long should it be cached because they are very different questions. can be cached is a matter of correctness, whereas how long is just a performance issue. Secondly: I also thought that Varnish never caches requests with a Set-cookie header? Varnish has a special kind of cache entries called hit-for-pass. This is a cache entry that says that the object can not be cached, that solves a pile-up issue on busy objects. The fact that you see zero TTL, can be indicative of the clock on the varnish-host and the clock on the backend not agreeing what time it is. Check your ntpd. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: obj.cacheable vs expires headers?
In message 4b708469.9070...@gmail.com, Luc Stroobant writes: Poul-Henning Kamp wrote: Check your varnishlog output, it shows all headers sent/received and look for what cache-control the backend gives varnish... The cache-control headers of the backend seem to be ok? (btw, the Varnish test-instance is running on my laptop, but the behaviour is exactly the same as it was on the production server) 9 RxHeader b Expires: Sun, 19 Nov 1978 05:00:00 GMT This is your problem: the backend says that the object is already expired, so obviously we cannot cache it for any amount of time. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishlog not behaving as expected (by me)
In message 4b6960da.6080...@bmjgroup.com, Alex Hooper writes: /usr/local/bin/varnishlog -o RxURL ^wp-admin$ This says you want to *O*mit all RxURL lines. The regexp argument should have generated an argument error. What you want is probably: varnishlog -i RxURL -I ^wp-admin$ Ie: Include (only) RxURL lines, which match this regexp. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Upper and lower case strings in Varnish
In message 4b69ab1a.6010...@mangahigh.com, Richard Chiswell writes: Hi all, I've got a simple question which I've been puzzling on for the last 30 minutes or so - how do you change a string in Varnish to lowercase? Basically, all the links on our site should be lowercase, but some people have been randomly capitalising them when linking to them - I'd just like Varnish to issue a 301 redirect to the lowercased version of the URL: everything is in place apart from converting the string to lowercase. You'll have to use a bit of inline C code to do that. 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Memory usage
In message 24a219a51001261923n40146083yb221aac2cadbc...@mail.gmail.com, Marti n Goldman writes: 1. How can you tell whether your Varnish objects fit in RAM? If you start seeing disk-activity, they do not fit. 2. If I have objects residing in virtual memory, to what extent will my performance be adversely affected? If I want my site to be fast, do I basically need to go out and buy as much RAM as it will take so that virtual memory isn't needed? Well, the impact is the necessary disk-I/O to bring the object into RAM. Getting more RAM is one solution, but if your working set is much larger than 4G, getting a SSD disk instead might be a better investment. 3. I noticed tonight that my machine was using a few hundred megs of swap space, Yes, varnish will force inactive programs (inetd, getty, sendmail etc) out to swap so it can get at the RAM. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishhist x-axis?
In message 4b66a916.4000...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: So for my understanding (oversimplified): This is the number of seconds it takes Varnish to 'get the result', either from the backend or from it's cache? Yes. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish Prefetch
In message 75cf5801001270025s722f114ax9335dba334a84...@mail.gmail.com, Paras Fadte writes: Thanks for the response . So with grace mode is it possible to fetch an object from backend about x seconds before its expires time is reached ? No, sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish Prefetch
In message 75cf5801001241820w3e4afd34v64ad2031b8b7...@mail.gmail.com, Paras Fadte writes: Is prefetch by default enabled in varnish ? Prefetch never got implemented, we found other ideas to solve the problem, such as grace mode. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Compiling VCL with pcc
In message 4b59e0f9.9060...@fsn.hu, Attila Nagy writes: So I have three ways to get out of this problem: 1 install gcc (I can't and don't want currently) 2 use a small C compiler 3 use precompiled configuration So my questions are: - will 3 be possible in the near future? I have no plans about implementing this, because the content of the compiled configuration is very tightly bound to the varnishd internals so I really don't want to add a lot of complexity to prevent version skew. - can anything be made to make pcc usable with varnish? Report the trouble to the pcc people. Run varnishd with -C option to capture a copy of the C program which pcc is being asked to compile. Check the line number and see what it chokes on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish crashes
In message 4b5d70b5.5080...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: How are your disks configured ? 2 cheap SATA disks in a gmirror (it's a simple Dell R300). Hmm, that's going to hurt obviously... You would probably have been better off, not mirroring and giving Varnish a -sfile for each disk. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish crashes
In message 4b5ad8b0.6090...@netmatch.nl, =?ISO-8859-1?Q?Angelo_H=F6ngens?= wr ites: By the way: the balancers do a total of 2000 req/sec now, but when stresstesting I can easily get 9000 cache/hits persec. So I don't think it's hanging on the upper limits of its performance. At that level of load, make sure to kldload the http accept filter. Your varnish-stat looks pretty OK. Have you configured health-polling of all those backends ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish use for purely binary files
In message b5ef6a23-b6bb-49a6-8eab-1043fc7bf...@dynamine.net, Michael S. Fis cher writes: Does Varnish already try to utilize CPU caches efficiently by employing = some sort of LIFO thread reuse policy or by pinning thread pools to = specific CPUs? If not, there might be some opportunity for optimization = there. You should really read the varnish_perf.pdf slides I linked to yesteday... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Feature REQ: Match header value against acl
In message 002501ca9918$aa519aa0$fef4cf...@paulissen@qbell.nl, Henry Pauliss
en writes:
What I tried to do is as follow:
if ( !req.http.X-Forwarded-For ~ purge ) {
I have decided what the syntax for this will be, but I have still
not implemented it.
In general all type conversions, except to string, will be explicit
and provide a default, so the above would become:
if (!IP(req.http.X-Forwarded-For, 127.0.0.2) ~ purge) {
...
If the X-F-F header is not there, or does not contain an IP#,
127.0.0.2 will be used instead.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Health check -- just connect, or full response?
In message b6b8b6b71001191152u7be99773o5ec70b20026...@mail.gmail.com, John No rman writes: Folks, For the health check (or, ahem, backend probe, as the docs has it -- ouch!), does health constitute ability to connect? Or does it check for a 200? It checks 200 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? Andavoiding single-point-of-failure?
In message 53c652a09719c54da24741d0157cb26904c5f...@tfprdexs1.tf1.groupetf1.fr It's probably simplest to paraphrase the code: Calculate hash over full complement of backends. Is the selected backend sick Calculate hash over subset of healthy backends Let's get back to consistent hashing and it's use... Correct me if I am wrong, but doesn't this mean that adding a new varnish instance implies a full rehash ? Yes, that is pretty much guaranteed to be the cost with any stateless hashing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message a8edc1fb-e3e2-4be7-887a-92b0d1da9...@dynamine.net, Michael S. Fis cher writes: What VM can overcome page-thrashing incurred by constantly referencing a working set that is significantly larger than RAM? No VM can overcome the task at hand, but some work a lot better than others. Varnish has a significant responsibility, not yet fully met, to tell the VM system as much about what is going on as possible. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish use for purely binary files
In message 4c3149fb1001181416r7cd1c1c2n923a438d6a0df...@mail.gmail.com, pub c rawler writes: So far Varnish is performing very well for us as a web server of these cached objects. The connection time for an item out of Varnish is noticeably faster than with web servers we have used - even where the items have been cached. We are mostly using 3rd party tools like webpagetest.org to look at the item times. The average workload of a cache hit, last I looked, was 7 system calls, with typical service times, from request received from kernel until response ready to be written to kernel, of 10-20 microseconds. Compared to the amount of work real webservers do for the same task, that is essentially nothing. I don't know if that is THE best performance, but I know of a lot of software doing a lot worse. Try running varnishhist if you have not already :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish use for purely binary files
In message 02d0ec1a-d0b0-40ee-b278-b57714e54...@dynamine.net, Michael S. Fis cher writes: But we are not discussing serving dynamic content in this thread anyway. We are talking about binary files, aren't we? Yes? Blobs on disk? Unless everyone is living on a different plane then me, then I think that's what we're talking about. For those you should be using a general purpose webserver. There's no reason you can't run both side by side. And I stand by my original statement about their performance relative to Varnish. Why would you use a general purpose webserver, if Varnish can deliver 80 or 90% of your content much faster and much cheaper ? It sounds to me like you have not done your homework with respect to Varnish. For your information, here is the approximate sequence of systemcalls Varnish performs for a cache hit: read(get the HTTP request) timestamp timestamp timestamp timestamp writev (write the response) With some frequency, depending on your system and OS, you will also see a few mutex operations. The difference between the first and the last timestamp is typically on the order of 10-20 microseconds. The middle to timestamps are mostly for my pleasure and could be optimized out, if they made any difference. This is why people who run synthetic benchmarks do insane amounts of req/s on varnish boxes, for values of insane 100.000. I suggest you look at how many systems calls and how long time your general purpose webserver spends doing the same job. Once you have done that, I can recommend you read the various architects notes I've written, and maybe browse through http://phk.freebsd.dk/pubs/varnish_perf.pdf Where you decide to deposit your conventional wisdom afterwards is for you to decide, but it is unlikely to be applicable. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish use for purely binary files
In message 364f5e3e-0d1e-4c95-b101-b7a00c276...@slide.com, Ken Brownfield wri tes: A cache hit under Varnish will be comparable in latency to a dedicated static server hit, regardless of the backend. Only provided the dedicated static server is written to work in a modern SMP/VM system, which few, if any, of them are. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish use for purely binary files
In message 87f6439f-76fe-416c-b750-5a53a9712...@dynamine.net, Michael S. Fis cher writes: I'm merely contending that the small amount of added = latency for a cache hit, where neither server is operating at full = capacity, is not enough to significantly affect the user experience. Which translated to plain english becomes: If you don't need varnish, you don't need varnish. I'm not sure how much useful information that statement contains :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Handling of cache-control
In message de028c9e-4618-4ebc-8477-6e308753c...@dynamine.net, Michael S. Fis cher writes: On Jan 18, 2010, at 5:20 AM, Tollef Fog Heen wrote: My suggestion is to also look at Cache-control: no-cache, possibly also private and no-store and obey those. Why wasn't it doing it all along? Because we wanted to give the backend a chance to tell Varnish one thing with respect to caching, and the client another. I'm not saying we hit the right decision, and welcome any consistent, easily explainable policy you guys can agree on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message 1ff67d7369ed1a45832180c7c1109bca13e23e7...@tmmail0.trademe.local, Ross Brown writes: So it is possible to start your Varnish with one VCL program, and have a small script change to another one some minutes later. What would this small script look like?=20 sleep 600 varnishadm vcl.load real_thing /usr/local/etc/varnish/real.vcl varnishadm vcl.use real_thing -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message ff646d15-26b5-4843-877f-fb8d469d2...@slide.com, Ken Brownfield wri tes: It is important to be absolutely clear about what your objective is here, availability, cache-hit-ratio or raw performance, the best solution will depend on what you are after. For a lot of purposes, you will get a lot of mileage out of a number of parallel Varnish machines with DNS round-robin, for all practical purposes, a zero-cost solution. In the other end, you have a load-balancer in front of your varnishes, which gives you all sorts of neat features at a pretty steep cost. The spectrum between is filled with things like pound, haproxy and other open-source solution, which may, or may not, run on their own hardware. There is no perfect fit for all solutions in this space, you will need to make your own choice. Squid has a peering feature; [...] Squids peering feature was created for hit-rate only, the working scenario is two squids each behind a very slow line to the internet, asking each other before they pull down a file. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message 4c3149fb1001151733g73f7a5dfjc84342b9df7f0...@mail.gmail.com, pub c
rawler writes:
Varnish performs very well. Extending this to have a cluster
functionality within Varnish I think just makes sense.
You can do some clever stuff with the hash director to distribute the
content over a cluster of varnishes:
varnish1 has:
backend webserver {...}
backend varnish2 {...}
backend varnish3 {...}
acl partner {
varnish1 ip
varnish2 ip
varnish3 ip
}
director h1 hash {
{ .backend webserver; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend varnish3; .weight 1; }
}
sub vcl_fetch {
if (beresp.http.x-partner == yes) {
set beresp.ttl = 0s;
unset beresp.http.x-partner;
}
}
sub vcl_deliver {
if (client.ip ~ partner) {
set resp.http.x-partner = yes;
}
}
On varnish2 you change the h1 director to read:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend webserver; .weight 1; }
{ .backend varnish3; .weight 1; }
}
On varnish3:
director h1 hash {
{ .backend varnish1; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend webserver; .weight 1; }
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message 4c3149fb1001160738l2233481dn82c34c2ba1fcc...@mail.gmail.com, pub c rawler writes: Poul, is anyone running the hash director distribution method like you provided (in production)? No idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message d002c4031001160741q63dd5a50i6342116daba15...@mail.gmail.com, Micha
el Fischer writes:
On Sat, Jan 16, 2010 at 1:59 AM, Poul-Henning Kamp p...@phk.freebsd.dkwrote:
director h1 hash {
{ .backend webserver; .weight 1; }
{ .backend varnish2; .weight 1; }
{ .backend varnish3; .weight 1; }
What happens when varnish2 or varnish3 dies?
If a particular backend in the director is unhealthy, the requests
for it will be redistributed by rehashing over the healthy subset
of directors. Once it becomes healthy, normality will be restored.
So everything should work out fine, for some value around 99.9% of fine.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message d002c4031001160929p1f688fc9mcc927dda2c684...@mail.gmail.com, Micha el Fischer writes: For instance sizes larger than 2, I think a consistent hash is needed. Otherwise, the overall hit ratio will fall dramatically upon failure of an instance as the requests are rerouted. If you have perfect 1/3 splitting between 3 varnishes, having one die will do bad things to your hitrate until the remaining two distribute the load between them. That's a matter of math, and has nothing to do with the hash algorithm. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message dcccdf791001161258s3e960aa8t3cd379e42d760...@mail.gmail.com, David Birdsong writes: Right, but those 2 remaining are at least still being asked for the same url's they were prior to the 1 dying. Correct, the hashing is canonical in the sense that if the configured backend is up, all traffic for its objects will be sent to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strategies for splitting load across varnish instances? And avoiding single-point-of-failure?
In message 4c3149fb1001161400n38a1ef1al18985bc3ad1ad...@mail.gmail.com, pub c rawler writes: Just trying to figure out the implications of this because in our environment we regularly find ourselves pulling servers offline. Wondering if the return of a Varnish would operate like a cold-cache miss or what magic in Varnish deals with the change in hashing per se. There is no built-in magic for that[1]. One of the really powerful things Varnish can do, is chance VCL code on-the-fly, instantly. So it is possible to start your Varnish with one VCL program, and have a small script change to another one some minutes later. You can use that, to start with a VCL where it only uses its neighbors as backends, and then some minutes later when the cache has the most common objects loaded, switch to another VCL that goes directly to the backend. If you want to get fancy, you can use VCL restarts, to ask the neighbors and if they don't have it, go directly to the backend on restart. Poul-Henning [1] In general Varnish has no built in magic, all the magic is your responsibility to write in the VCL code :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange different behavior
In message 20100114215025.gb9...@kjeks.kristian.int, Kristian Lyngstol writes
:
Vary on User-Agent is generally bad, and you should Just Fix That [tm].
Apart from the compatibility issue, a secondary reason it is a bad
idea, is that User-Agent is practically unique for every single PC
in the world, so you will cache up to hundreds of copies of the pages
for no good reason.
If your site is running live on Varnish, try running:
varnishtop -i rxheader -I User-Agent
and see how many different strings your clients send you...
In all likelyhood, your backend looks at only one or two of the bits
in User-Agent (MSIE or Mozilla ?) but Varnish has to look at the
entire string, since it has no way of knowing what your backend
looks at.
One workaround, is to do what we call User-Agent-Washing, where
Varnish rewrites the Useragent to the handfull of different variants
your backend really cares about, along the lines of:
sub vcl_recv {
if (req.http.user-agent ~ MSIE) {
set req.http.user-agent = MSIE;
} else {
set req.http.user-agent = Mozilla;
}
}
So that you only cache the relevant number of copies.
But as Kristian says: The best thing, is to not Vary on User-Agent
in the first place, that's how the InterNet is supposed to work.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange different behavior
In message b6b8b6b71001150646w7f3ba876y30401d85f1813...@mail.gmail.com, John Norman writes: OK. But if your application backend really doesn't do anything different for different user agents, then one should probably remove the user-agent? yes, by all means do so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: tool for dumping contents of cache
In message dcccdf791001151324l5b15909br954a438738b2...@mail.gmail.com, David Birdsong writes: I know this would be a huge performance problem, but I'd really like a tool that could examine the storage file(s) of a running varnish instance that could dump out url's and hit counts. Play around with varnishlog and varnishtop. If you havn't yet, try: varnishtop -i rxurl -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Does a Varnish restart clear the existing cache?
In message b6b8b6b71001141306g4dbf4292qad39e2abb86e...@mail.gmail.com, John N orman writes: I think the answer is no, but . . . Does a Varnish restart clear the existing cache? (using the file storage.) Actually it does, we are working on the persistent storage module. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish logging and data merging
In message 4c3149fb1001102237xaf0d732hb22418df4cf21...@mail.gmail.com, pub cr awler writes: We have a lot of logging going on in our applications. Logs pages, IP info, time date, URL parameters, etc. Since many pages are being served out of Varnish cache, they don't get logged by our application. run varnishncsa or varnishlog to collect your loginfo. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: AW: Varnish poisoned cache avoidance
In message 4c3149fb1001100307s4364a201n9164abbe10957...@mail.gmail.com, pub c rawler writes: Is the delay 100ms something that could be made available in Varnish near term? You can do it with inline C code already, just call usleep(10) in your inline C. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Bug? Related to ticket 547
In message d26f7e3f42600549a27a4433eb952e8404031...@sbs03.ecnext03.local, Ji
m Hayter writes:
I'm sorry, but I'm not sure how/where to report this.
I'm running varnish-2.0.6 on Solaris 10. I had the issue noted in
http://varnish.projects.linpro.no/ticket/547 when testing 2.0.5, which
was fixed in 2.0.6. I just tried 2.0.6 on a production system and ran
into the issues noted in the varnishd output below. It appears to be a
similar call to setsockopt to the one noted in ticket 547. This error
occurred every 3-6 minutes.
It seems to be Solaris returning EBADF if the connection is closed
before it gets around to do something to it.
Can you open a ticket with this report, I'll try to find a way to
add checks for this.
Poul-Henning
Any input is welcomed. We had hoped to run this on one of our
production web servers all weekend as a prelude to putting it into full
production.
Thanks,
Jim
Varnishd output
---
...
Child (21784) said , 1, 3)
Child (21784) not responding to ping, killing it.
Child (21784) not responding to ping, killing it.
Child (21784) not responding to ping, killing it.
Child (21784) died signal=6 (core dumped)
Child (21784) Panic message: Assert error in VCA_Prep(),
cache_acceptor.c line 148:
Condition((setsockopt(sp-fd, 0x, 0x0080, linger, sizeof linger))
== 0) not true.
errno = 9 (Bad file number)
thread = (cache-worker)
sp = 8f29974 {
fd = 84, id = 84, xid = 0,
client = 66.68.180.213:2086,
step = STP_FIRST,
handling = error,
restarts = 0, esis = 0
ws = 8f299c0 {
id = sess,
{s,f,r,e} = {8f2a470,+19,0,+32768},
},
http[req] = {
ws = 0[]
},
worker = 731cdee0
},
Child cleanup complete
child (21816) Started
Child (21816) said Closed fds: 4 5 25 26 28 29
...
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: AW: Varnish poisoned cache avoidance
In message 01cf01ca91db$8c29b790$a47d26...@de, Mike Schiessl writes:
How can varnishd help me prevent DDOS / DOS attacks ?
Firstly, by being damn fast.
Originally we had some plans for specific antiDoS measures, something
like:
sub vcl_recv {
if (client.bandwidth 100 mbit/s) {
delay 100ms;
}
if (client.missratio 20%) {
close;
}
}
et cetera...
There are some issues and fine details to doing it, amongst other things
that we need to have a data structure for the client which survives
the individual session long enough for it to make any difference
in the above context.
The trouble of course is that a DDoS cannot be identified by IP#,
prompting ideas long the lines of
sub vcl_recv {
if (backend.hitrate 70%) {
/* do something... */
}
}
etc.
But before we get anywere, somebody needs to figure out what we
can do.
Basically any countermeasure has two equally troublesome components:
1. detection. Knowing that you need to do something.
2. mitigation. What are we going to do ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: VCL config file for specific URLs
In message 4c3149fb1001090240l53a26f5eg9452abdbdd820...@mail.gmail.com, pub c
rawler writes:
Any idea of how to accomplish the cache exception of these handful of pages?
If you have a short-ish list of URLs, you can simply test for them:
sub vcl_recv {
if (req.url ~ (foo.html|bar.html|baz.html)) {
pass;
}
}
If the list is long-ish, consider having the webserver mark them
as non-cacheable by adding a HTTP header varnish can check for
instead. That way the knowledge about cacheability is maintained
with the content.
Of course, you can also mix the two methods...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: logging statements in vcl
In message 458a97201001081354s50a74935o2a2d36a8dab44...@mail.gmail.com, Frank van Lingen writes: Hello, I recently started to use varnish. The installation with the default vcl starts without problems. However if I turn varnish logging on It seems to cache nothing (I see only 'pass' and 'deliver' statements). Is there a way to add logging statements in the vcl file that will be displayed when I turn on varnish logging? I was not able to find anything about this on the varnish pages. It would help analyzing the vcl configurations. Set the vcl_trace parameter, that will add logging entries for every branch taken in your VCL. The number 1 case of not caching is cookies. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Architectural heads-up/call for comments
In message op.u55n4olks5t...@id-c0805.oslo.osa, Cosimo Streppone writes:
On 06 january 2010 12:46:07, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
1. Kill the magic default VCL.
It's great that you're asking feedback, thanks.
You will no longer be able to just give Varnish a subset of the VCL
instruction, ie. just a vcl_recv{} function
I understand and appreciate the motivation for this.
However, I must say I find it really easy to just have
a default behavior built-in.
It will still be, because we are not going to give up on the -b option.
Interestingly, after sending that email, I realized that I would be
the person who got hit hardest by this change, since I have 187 different
VCL programs in the regression test-suite :-/
That is a really bad reason to change, what I think is otherwise a
sound decision, but for reasons if sanity, I need to have some kind
of workaround.
One of the obvious ways to do it, is to offer the default VCL methods
as callable functions.
Ie something like:
sub vcl_recv {
if (req.url ~ [.]exe) {
error 503;
}
call default_recv;
}
Apart from making the reference to the default code explicit, that is
very very close to what we have today.
OTOH, it's true that you have to know what you're doing.
I would suggest to have several presets files, sort of what
mysql does with my-huge.cnf, etc...
I'm not sure I have seen sufficiently generic VCL programs
to make this make sense. I fear VooDoo configurations that way.
Back in the ancient mists of time, spirits were brave, stakes were
high and we thought it would be possible for users to use VCL
libraries and have a VCL file that looked like:
include typo3.vcl;
include anti_dos.vcl;
include anti_malware.vcl;
...
Obviously, that does not work, because of the ordering necessary
of the checks..
Please, can you explain?
Well, they all want to do something first in vcl_recv{} and there
is no way to tell who is more important than the others.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Persistent mode statistics
In message 20100107155526.ga61...@fupp.net, Anders Nordby writes: So it seems that n_object is emptied, while n_objectcore and n_objecthead is not? Also I notice that resident memory usage is down by around 96%, I don't know if that is to be expected? n_object will increase as the objects are instantiated from the silo. Resident will increase as it gets paged in. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Architectural heads-up/call for comments
503 -txt bugger off!;
}
}
sub vcl_fetch {
beresp.ttl = duration(beresp.http.myttl, 10s);
}
If the conversion fails because the string value is not a valid
IP/time/duration, the second parameter gets used instead.
Thanks for listening, now it's your turn to tell me if this is
stupid...
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Architectural heads-up/call for comments
In message 4b44814a.3010...@gmail.com, Rob S writes: Poul-Henning Kamp wrote: I'd like to mutter something here about adding some form of return pass, rather than just writing pass. That is already the syntax in -trunk: return(pass); 2. Client identity Access to cookies is great, but I don't necessarily think that a client.ident idea is sensible. Is the client object going to be persistent between requests? Between requests: yes. Between TCP connections: no. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishtest
In message 4b3c5703.8020...@gmail.com, ll writes: Is there any manual about the command varnishtest ? I useing varnish 2.0.4 edition . very little. The best docs is the testcases in the tests subdirectory. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: only 503s after a few hours (trunk-4384)
In message 002b01ca78d6$a7de2b10$7802a...@interactive.live.net, Fernando Pap a writes: Happened again. This time I left varnishlog running, and got... 5 Debug- Too many open files when accept(2)ing. Sleeping. EOF That's your trouble: The kernel does not allow varnish to open as many filedescriptors as it needs. Use whatever means your kernel has to change this number, possibly ulimit(1) or similar. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: vcl_error synthetic escape chars
In message 4b18488d.8030...@joetify.com, Joe Williams writes:
I am attempting to write my own error message in vcl_error and am
running into an issue with escaping out { and }.
synthetic {\{error:not_found,reason:missing\}
This compiles and works but when I produce the error I get the slashes
in the response:
r...@ubuntu:~# curl http://localhost:6081/test/adsf
\{error:not_found,reason:missing\}
I searched around and didn't find anything, is it possible to escape out
the curly braces and keep them from showing up in the response?
Yes I belive %7b ... %7d will work.
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish bottleneck?
In message 4b0f276a.9000...@gmail.com, ll writes:
if (req.request == POST){
pipe;
}
Use pass, not pipe.
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish bottleneck?
That is correct. If you use pipe, the TCP connection turns into a straight pipe where bytes are moved from client to server, without further inspection, until either side closes the TCP connection. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Worker thread stack size
I have added a parameter to set the worker thread stack size. I suspect we can get away with something as low as maybe 64k + $sess_workspace, but I have absolutely no data to confirm or deny this claim. If a couple of you could spend a few minutes to examine actual stack sizes and report back, that would be nice. The number I am interested in, is the number of mapped and modified pages in the worker-thread stacks. On FreeBSD, the mincore(2) could report this, but on Linix mincore(2) only reports mapped vs. unmapped pages, which may or may not be enough. In either case, it would require some hackish code in Varnish. A better way is to ask your systems VM system, for instance by looking at /proc/$pid/map. On a 64bit FreeBSD system, the entries you are looking for look like this: 0x7ddd 0x7ddf 3 0 0xff003d87e0d8 rw- 1 0 0x3100 NCOW NNC default - CH 488 0x7dfd1000 0x7dff1000 3 0 0xff0028845d80 rw- 1 0 0x3100 NCOW NNC default - CH 488 0x7e1d2000 0x7e1f2000 3 0 0xff00635eea20 rw- 1 0 0x3100 NCOW NNC default - CH 488 0x7e3d3000 0x7e3f3000 3 0 0xff0095d57870 rw- 1 0 0x3100 NCOW NNC default - CH 488 0x7e5d4000 0x7e5f4000 3 0 0xff00630ec0d8 rw- 1 0 0x3100 NCOW NNC default - CH 488 And the number I need is the difference between the first two colums for all your worker threads, (min, max, average accepted also ) and the value of your sess_workspace parameter. In the case you would find: 0x7ddf - 0x7ddd = 128K 0x7dff1000 - 0x7dfd1000 = 128K ... Poul-Henning In message 20091118123439.6a18c38...@projects.linpro.no, p...@projects.linpro. no writes: Author: phk Date: 2009-11-18 13:34:39 +0100 (Wed, 18 Nov 2009) New Revision: 4352 Modified: trunk/varnish-cache/bin/varnishd/cache_pool.c trunk/varnish-cache/bin/varnishd/heritage.h trunk/varnish-cache/bin/varnishd/mgt_pool.c Log: Add a parameter to set the workerthread stacksize. On 32 bit systems, it may be necessary to tweak this down to get high numbers of worker threads squeezed into the address-space. I have no idea how much stack-space a worker thread normally uses, so no guidance is given, and we default to the system default. Fixes #572 -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Fwd: Cache utilization?
In message 2af2dcee-6443-41c2-8be4-c338203f2...@gyldendal.dk, =?iso-8859-1?Q? Lars_J=F8rgensen?= writes: I have: = n_lru_nuked 0 . N LRU nuked objects n_lru_saved 0 . N LRU saved objects n_lru_moved 3692590 . N LRU moved objects = I guess what you call kill activity is the same as nuked objects? Correct, you seem to have plenty cache space. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Benchmarks [was: Yahoo! Traffic Server]
In message 2009093140.ga9...@kjeks.linpro.no, Kristian Lyngstol writes: I'm reasonably certain that I can get close to breaking 300k req/s on a dual quad core with ht, but I don't think I can convince anyone to lend me a small city worth of computers to generate the traffic. I thought the way to do that kind of benchmark was to send a twitter message like: Hehe, looks like Jessica Biels bikini straps snapped (http...) :-) -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Back from the dea^H^H^Hsoul-less
Hi Guys, I owe you all an apology for disappering for the last couple of weeks, but I had to spend pretty much all my time writing my reply in my Windows-refund case against Lenovo. Tomorrow I'll drop off the result at the court-house, and than I should be able to ignore that until X-mas, when Lenovo is supposed to reply. And then it's back to hacking varnish... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Back from the dea^H^H^Hsoul-less
In message 002c01ca5da3$77a93230$66fb96...@paulissen@qbell.nl, Henry Pauliss en writes: Windows-refund case?=BF? Did i miss something? http://phk.freebsd.dk/MicrosoftSkat/ You should be able to read 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish virtual memory usage
In message 003201ca5da9$57ae7e30$070b7a...@paulissen@qbell.nl, Henry Pauliss en writes: Our load balancer transforms all connections from keep-alive to close. That is a bad idea really, it increases the amount of work varnish has to do significantly. but 1,610 threads with your 1MB stack limit will use 1.7GB of RAM. It is very important to keep Virtual Address Space and RAM out from each other. The stacks will use 1.7G of VM-space, but certainly not as much RAM as most of the stacks are not accessed. The number you care about is the resident size, the _actual_ amount of RAM used. Only on 32bit systems is there any reason to be concerned about VM-space used. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Yahoo! Traffic Server
In message 2e51048e-58cd-4599-b4be-85cdac78f...@develooper.com, =?iso-8859-1? Q?Ask_Bj=F8rn_Hansen?= writes: I thought this might be of interest: http://wiki.apache.org/incubator/TrafficServerProposal It probably is -- for some people. My impression of Inktomi is that it is a much more comprehensive solution than Varnish, it does SMTP, NNTP and much else. If I were to start Yahoo, HotMail or a similar app today, I would seriously consider starting out on Inktomi, because of the scalability, horizontal and vertical, it offers. Varnish on the other hand, only does HTTP, but aims to do it with ultimate performance and flexibility, by pushing the technological envelope as far as it can be pushed. But For me, personally, the main difference is one of size: Inktomi: *.h93920 *.c50892 *.hh 0 *.cc 350199 495011 Varnish: *.h 5957 *.c38871 *.hh 0 *.cc 0 44828 We have a rhyming saying in Denmark that goes: En lille og vågen, er bedre end en stor og doven which roughly translates to: Small and alert is better than big and inert. But I'm happy to see the Inktomi code out in the free air, I've heard much good about it, over the years, from my FreeBSD cronies at Yahoo. And because I like a healty competition, I particularly welcome Inktomi, because quite frankly: competing with squid is not much fun... :-) 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: call a sub function and return
In message 4ad5d327.9040...@danielbruessler.de, Daniel Bruessler writes:
Hi!
I'd like to call a sub function and use the return-function. But is
there a return-function?
#called from vcl_fetch: call vcl_custom_cachingtime;
sub vcl_custom_cachingtimes {
if (req.url ~ ^/abc/* {
set obj.ttl = 10m;
#return (0);
}
if (req.url ~ ^/def/* {
set obj.ttl = 30s;
}
}
It's not clear from you example what you would use the return for,
but you can simulate it, but putting you return value in a header
instead
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: call a sub function and return
In message 4ad5e2bb.2020...@danielbruessler.de, Daniel Bruessler writes:
Hello,
I don't need a return to return a value, I just want to jump out
before the end of the function. I posted a simplified version of my
function, the real one has several if-clauses.
Use elseif ?
if (foo) {
} elseif (bar) {
} elseif (foomble) {
} else {
}
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Panic message: Assert error in VSL(), shmlog.c line 157
-serif; color:#5AC100'408.806.8621/spanspan style=3D'font-size:7.5pt;font-famil= y: Verdana,sans-serif;color:black'br /spanbspan style=3D'font-size:6.0pt;font-family:Verdana,sans-serif= ; color:black'F gt;/span/bspan style=3D'font-size:7.5pt;font-family:V= erdana,sans-serif; color:black' /spanspan style=3D'font-size:7.5pt;font-family:Verdana,= sans-serif; color:#5AC100'nbsp;650.328.3901/spanspan style=3D'font-size:7.5pt; font-family:Verdana,sans-serif;color:black' br br /spanbspan style=3D'font-size:9.0pt;font-family:Verdana,sans-serif= ; color:black'SolutionSet/span/bspan style=3D'font-size:7.5pt;font-fami= ly: Verdana,sans-serif;color:black' br The Brand Technology Company br a href=3Dhttp://www.solutionset.com/;span style=3D'color:blue'http://w= ww.SolutionSet.com/span/a br br /spanbspan style=3D'font-size:6.0pt;font-family:Verdana,sans-serif= ; color:black'PA gt;/span/bspan style=3D'font-size:7.5pt;font-family:= Verdana,sans-serif; color:#5AC100' 275 Alma Street, Palo Alto, CA 94301/spanspan style=3D'font-size:7.5pt;font-family:Verdana,sans-serif;color:black'b= r /spanbspan style=3D'font-size:6.0pt;font-family:Verdana,sans-serif= ; color:black'SF gt;/span/bspan style=3D'font-size:7.5pt;font-family:= Verdana,sans-serif; color:#5AC100' 85 Second St., San Francisco, CA 94105/spanspan style=3D'font-size:7.5pt;font-family:Verdana,sans-serif;color:black' = o:p/o:p/span/p p class=3DMsoNormalo:pnbsp;/o:p/p /div /body /html --_000_F1B9797980995749A47520A7F9136E48103DAAE5E7MVLMAILBOXsol_-- --===1052186233== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc --===1052186233==-- -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: POST body logging
In message 20091002212608.gd19...@digdug.corp.631h.metaweb.com, Niall O'Higgi ns writes: Hi all, I'm trying to get Varnish to log POST body contents. Sorry, we have no code to support that presently. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: PIPE asserts
In message 4ab8d635.5060...@1art.cz, =?ISO-8859-1?Q?V=E1clav_B=EDlek?= writes
:
i redefined vcl_recv this way:
if (req.request != GET
req.request != HEAD
req.request != PUT
req.request != POST
req.request != TRACE
req.request != OPTIONS
req.request != DELETE) {
/* Non-RFC2616 or CONNECT which is weird. */
return (error);
}
Please open a ticket on this one.
As a workaround, you can use:
[...]
req.request != DELETE) {
/* Non-RFC2616 or CONNECT which is weird. */
error 503;
(or any other status code than 503 which you might prefer)
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
VUG1 meeting resport
I thought I would drop you a short report on our Varnish User Group meeting this monday and tuesday in London. About a dozen people participated, filling the meeting room Canonical Software kindly provided to us for free. Obviously, my TODO list grew continuously during the meeting but it was my impression that everybody got something out of the meeting, but on that I will let people speak for themselves. We talked about a lot of things, and the result is more or less a sort of a roadmap, but I need to do some text-procesing before I can give a coherent view of it. My personal impression was that the user group format worked out well, we are not a big enough community to do actual conferences yet. I also think most of the knowledge that needs to be shared, are in the brains of everybody else than me[1]. One of the action items were to get more VCL code up on the wiki, both snippets and complete examples, so that Varnish users can learn and find inspiration from each other. We talked about frequency of these meetings, and I think the overall consensus was no more than a couple of times every year. There were no clear consensus, if it would be a good idea to piggyback on other conferences (FOSSDEM etc) to synergize travel and the end result I think, was that whoever arranges the meeting gets to decide where and when. Next meeting will probably be in .NL in the feb-march time-frame. See you there! Poul-Henning [1] I was the only on in the room who did not run Varnish :-) -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish User Group Meeting 2009-09
In message 20090920153645.gb5...@kjeks, Kristian Lyngstol writes: We will begin at 09:00 London-time and keep going through the day. Canonical have been kind enough to lend us the meeting room we'll be using. I will attempt to be there at 9, but I have still not figured out the details of getting from Cambridge to London out, working on that right now. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish User Group Meeting 2009-09
In message e95443d90909201009k7fddd1etc6e1d9e7900ab...@mail.gmail.com, Lauren ce Rowe writes: From Cambridge, take the train to London Kings Cross (approximately 50 minutes, runs every half hour). From Kings Cross take the Victoria Line (Underground) to Pimlico. Millbank tower is then a 1km walk. Yes, I have reached the same conclusion. I think I'll aim for the 0715 from cambridge, that should have me at Pimlico around 0830. 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
travel: eurobsdcon2009 and vug1
Hi guys, I will be semi-offline from tomorrown, while I attend EuroBSDcon2009 in Cambridge. After EuroBSDcon2009 I will take a train to London to attend the very first V(arnish) U(ser) G(roup) meeting monday and tuesday. (http://varnish.projects.linpro.no/wiki/200909UserGroupMeeting) Wednesday I'll hang out with an old friend and thursday I'll start to dig myself out of the heaps which have accumulated. See you there... 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: smart health check response?
In message dcccdf790909132251o360dd2f1if10619325fb87...@mail.gmail.com, David Birdsong writes: ...are any of the stats available inside vcl_error? Not directly, but you can relatively easily get your hands on them if you use inline C-code. 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Sub-second granularity logs
In message 20090910212740.gv6...@digdug.corp.631h.metaweb.com, Niall O'Higgin s writes: Hi all, I am currently working on a custom logger for Varnish. One of the things we need is sub-second granularity for the start request log event (millisecond). All the internal timestamps are in nanosecond resolution, just find the right printf and fix the format. Getting a timespec is just as expensive as getting a time_t, because time(2) simply calls clock_gettime(2) under your feet. Which shmrecord are we talking about ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: performance scalability of a multi-core
In message 4aa7ad33.1060...@1art.cz, =?UTF-8?B?VsOhY2xhdiBCw61sZWs=?= writes: Helo what are your experiences using varnish on multi CPU systems on Linux/Freebsd? my experience in Linux on 8core is that varnish never gets more than 20% of all CPUs, only vhen it is overloaded, then it takes all CPU ( but berformance drops). That is pretty typical behaviour. In general Varnish does not need much CPU, it needs only an average of seven sytem calls for a cache hit (last I looked). The problem is that when things pile up, for whatever reason, Varnish sort of climbs the pile. Various ideas have been floated, how to deal better with that, but no really good idea has been found yet. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: client keepalive on high trafic site
In message 4aa633e3.6030...@1art.cz, =?UTF-8?B?VsOhY2xhdiBCw61sZWs=?= writes: I think that is not the problem... when I disable keepalive by seting connection: close header then i get 4x higher throughput ( but works bad in IE6) ... till the 8K established connection everithing works fine (low latency responses, only 10%cpu usage on server, load around 1-2) Why don't you restrict connection: close to non-IE6 then ? You can test the User-Agent header in your VCL code -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: req.xid semantics?
In message 20090904235827.ga6...@digdug.corp.631h.metaweb.com, Niall O'Higgin s writes: I am looking for some sort of VCL identifier which I can use to disambiguate requests which occur within the same second, but in different threads. That is indeed what req.xid is for. It starts from a random value on startup, and each request gets a unique value. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: purging
In message 4a9f5b15.8070...@1art.cz, =?UTF-8?B?VsOhY2xhdiBCw61sZWs=?= writes: 1) How does purging work with duplicate request? We try to eliminate them, and if they are exactly identical, we succeed. 2) is it a problem for performance to have thousands of purges? They will cost you some memory and cpu time, but it shouldn't be a problem. 3) how does purge request change state from total active purges to old purges deleted or to duplicate purges removed? Old purges deleted are purges that no longer apply, ie: the have been tested against all objects in the cache when they were entered (or the objects expired without being requested or tested) Duplicates are the ones above. If you add a purge for req.url == FOO Then any older identical purges will be marked gone and not tested against, as the new purge will catch the offending objects. (We cannot remove the old purge from the list for reference counting reasons) -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish redundancy
In message d340a0f10909030341w477afb0fvbe7bb23d12a65...@mail.gmail.com, Rob A
yres writes:
Does anyone have any experience or tips on using varnish in this way?
You can do some really insteresting things, such as:
One such is to configure the two varnishes along these lines:
vcl_recv {
if (client.ip ~ other_varnish) {
set req.backend = real_backend;
} else {
set req.backend = other_varnish;
}
}
vcl_pass {
set req.backend = real_backend;
}
vcl_pipe {
set req.backend = real_backend;
}
For it to be really smart you want to use directors for the
other_varnish and probes to ascertain health.
We do not have a priority_director (we probably should have)
but you can get much the same effect with the random director
and very uneven weights:
director other_backend {
{ .backend = b_other_varnish ; weight=10; }
{ .backend = b_real_backend ; weight=1; }
}
Should the probes mark the other_varnish unhealthy, all trafic
will go to the real backend.
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: many workers threads failed with EAGAIN
In message dcccdf790908311636g39bbf036icdc66405e46aa...@mail.gmail.com, David Birdsong writes: What does your responstimes look like in varnishhist ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: if obj.status == 50[1|2|3|x] - reissue request on next backend(s)
In message 1251797169.13050.48.ca...@pioneer, Gerald Leier writes:
hello again,
Is or isnt it possible to make varnish ask another backend
if the first returns a HTTP 500 or any other user defined
HTTP code when forwarding a users request?
and if its possible - whats the varnish way to do that?
Use the restart facility, which basically tried the request
once more from the beginning, with any possible modifications
you have made or will make.
Typically, you would set another backend in vcl_recv{},
something like:
...
if (req.restarts 0) {
set req.backend = better_one;
} else {
set req.backend = normal_one
}
--
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-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Raising funds for developing Varnish
Software development may be open, and the result shared with an Open Source Software licence, but the actual hours of programming are not gratis. Just like everybody else, I need money for mortgage, kids and food, money I make, by doing things with computers, for people who are willing to pay for that. One of the things I do for money, is develop Varnish. From the very beginning of the project the Norwegian company Redpill-Linpro, has channeled money from sponsors and customers and paid for my time. Redpill-Linpro also offer commercial services based on Varnish, consultancy, hosting, support and other services. That way, the companies which have a contract with Redpill-Linpro, help pay for the future development of Varnish. For all practical purposes this has worked great until now. Unfortunately, some obscure tax rules makes it pretty nasty for me and my accountant: if more than 30% of my work is for the same customer in a Nordic country, I may be deemed an employee of said company with possible double taxation, and other unpleasant paper work as a result. This effectively puts a cap on the amount of work I can do on Redpill-Linpro and consequently: on Varnish. It is my impression, that a fair number of Varnish users are not likely to need the professional services of Redpill-Linpro, and thus unlikely to help pay for future Varnish development via that route. This is where the Varnish Moral License comes into the picture: The Varnish Moral License, is a voluntary license payment, directly to the author of Varnish, which helps pay for the development of Varnish. Buying a Varnish Moral License is 100% voluntary, if you do not make money from your website, there is no reason why you should pay for a license to use Varnish on it. If however, Varnish helps your website generate a profit, you should consider getting a Varnish Moral Licence. In all cases, it is entirely up to you (and your morals) if you should get a license or not. That is why I called it a Moral License. Please buy one. More details and FAQ at: http://phk.freebsd.dk/VML/ Poul-Henning Kamp -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: bad national characters in synthetic
Any sugestions? File a bugreport. Use ...; syntax until I have time to look at 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread pools
In message 294d5daa0908171755y44f5c132o587f3c818849...@mail.gmail.com, Mark M oseley writes: I've seen various things in the wiki and threads on this list talking about thread pools. In general, the advice is typically conservative, i.e. don't use more than the default 2 thread pools unless you have to. I've also seen the occasional comment suggesting one run as many thread pools as there are cores/cpus. I think the point here is don't make 1000 or even 100 pools. One pool per core should be all you need to practically eliminate thread contention, but to truly realize this, we would have to pin pools on cores and other nasty and often backfiring optimizations. Having a few too many pools probably does not hurt too much, but may increase the thread create/kill ratio a bit. Also, the wiki mentions that it's mainly appropriate when you run into locks tying things up. Is that mainly a case of high LRU turnover or are there other scenarios where locking is an issue? What are the symptoms of locking becoming an issue with the current configuration and what fields in varnishstat should I be looking at? POSIX unfortunately does not offer any standard tools for analysing lock behaviour, so we have had to make some pretty crude ones ourselves. The main sign of lock issues is that the number of context switches increase drastically, you OS can probably give you a view of that number. If you want to go deeper, we have a flag in diag_bitmaps that enables shmlogging of lock contentions (or even all lock operations), together with varnishtop suitably filtered, that gives a good idea which locks we have trouble with. but I worry about wasting any CPU% on those 8 core 1950s [...] Varnish is all about wasting CPU%, normally we barely touch the CPUs, man systems running with 80-90% idle CPUs. Have you played a bit with varnihshist ? I suspect that may be the most sensitive, if crude, indicator of overall performance we can offer. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish, long lived cache and purge on change
In message 4a8bb076.50...@gmail.com, Rob S writes: phk and other deep Varnish developers, Do you think it'd ever be viable to have a sort of process that goes through the tail of the purge queue and applies the purges then deletes them from the queue? If so, how much work would it be to implement? Right now we do not know which objects hold onto a ban, only the number of objects that do. Do implement it, we would need to put a linked list in each ban and wire the referencing objects onto it. My only worry is that it adds a linked list to the objcore structure taking it from 88 to 104 bytes. I seem to recall that the locking is benign. Probably the more interesting question is how aggressive you want it to be: if it is too militant, it will cause a lot of needless disk activity. -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish, long lived cache and purge on change
In message 2837.1250697...@critter.freebsd.dk, Poul-Henning Kamp writes: In message 4a8bb076.50...@gmail.com, Rob S writes: Just to follow up to myself after trying to hack up a solution in -trunk: I seem to recall that the locking is benign. Make that Mostly benign :-) Probably the more interesting question is how aggressive you want it to be: if it is too militant, it will cause a lot of needless disk activity. There was actually a far more interesting question, or rather issue: The lurker thread does not have a HTTP request. That means that we can not evaluate a ban test like req.url ~ foo: we simply don't have a req.url to compare with. So provided you only have obj.* tests in your bans, it is possible, for req.* tests it is a no go... The obvious workaround is evident, store the req.* fields you need in obscure obj.* headers (possibly stripping them in vcl_deliver). With that caveat, give r4206 a shot if you dare... -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: abnormally high load?
In message a25ff4db-b85a-49c0-8665-0356ae556...@slide.com, Ken Brownfield wri tes: Unless you're doing recursion or using large declared structures in inline C, [...] We do use limited recursion, for instance in the case of ESI where included objects result in reentrance of cache_center.c And yes, wouldn't it have been nice if POSIX had included a way to see how many pages the kernel know you use ? -- 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-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
