for an object, so vcl_timeout{} can get
a shot at compressing it.
But lets concentrate on the traffic part for now, vcl_timeout{}
needs a bit more time with the thinking cap.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
actually be more stable then?
Possibly, if your environment triggers the bugs that have been fixed
since the last release.
I should warn though, that SVN will go into active development shortly, so
you will have to pay attention to when you grab a copy.
--
Poul-Henning Kamp | UNIX since Zilog
In message [EMAIL PROTECTED], cripy
writes:
Hey Poul,
Thanks for the prompt response and help. However, I can't seem to get
this to work properly I am receiving the following error upon varnishd
startup:
Easy does it, I said it was a plan I had, not that I had done it yet.
--
Poul-Henning
, you're running into a bug in the pass implementation which
have since been fixed.
Try using pipe mode for authenticated requests instead, by putting
this in your vcl_recv function:
if (req.http.Authenticate || req.http.Cookie) {
pipe;
}
--
Poul-Henning Kamp
{
if (req.http.authorization) {
Should have been: req.http.authenticate
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
in a portable way is unfortunately the
same as implementing all of SNMP, there are no agreed on portable
API's for implementing SNMP. (Another POSIX failure there).
Thirdly, somebody would have to sponsor the work.
So I would say the answer to your question is: unlikely.
--
Poul-Henning Kamp
in Accept-Language your site supports
Does your backend include a proper Vary: header when it selects on
language ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
Correct me if I am wrong.
Actually, we just added a facility to do this:
vcl_hash {
req.hash += req.http.cookie;
}
It will (not yet) do the right thing if there are multiple cookie
header lines, but that is in the works.
--
Poul-Henning Kamp | UNIX
in vcl_miss{}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish
In message [EMAIL PROTECTED], =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=
writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
I have implemented a very efficient and simple Vary: processing
in varnish(-trunk) now.
[...]
And report back whether it works for you or not...
Works for me for deflate
In message [EMAIL PROTECTED], =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=
writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
Dag-Erling Sm=C3=B8rgrav [EMAIL PROTECTED] writes:
Works for me for deflate. Very useful for tinderbox.des.no, as the
typical compression ratio for tinderbox logs is 15:1
what I get from varnishstat. So is this a bug in varnishstat?
You're probably running out of the 32bit counter, we need to expand
some of those to 64 bits...
Can I get you to open a ticket in the varnish trac system ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
that the backend has stopped responding and start servicing
again the moment it detects that the backend is up?
At some point we will be able to, but not right now.
Sorry, if i have asked too many questions at one go.
You're welcome :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
In message [EMAIL PROTECTED], Anup Shukla writes:
Poul-Henning Kamp wrote:
I have put the cache file (or whatever its called as) under /cache/varnish
the parameters are -s
file,/cache/varnish/varnish_storage.bin,2G
Disk space should not be a problem as there is plenty
In message [EMAIL PROTECTED], Denis Ahrens writes
:
I have varnish head running and everything now looks good.
How recent is that copy ? I (belive I) fixed that bug
this week.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
attitude, I suggest you stick with Squid.
This is of course pretty harsh on the squid project, but you will
almost certainly not be able to contribute positively to the Varnish
project with that attitude.
Killfile, meet Manuel, Manuel, bye!
Poul-Henning
--
Poul-Henning Kamp | UNIX since
-http2-ws);
LOCK(vbemtx);
TAILQ_INSERT_HEAD(vbe_head, vc, list);
VSL_stats-backend_unused++;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
don't agree what time it is.
Could you check that ?
If you want to fill in some debugging look for res_do_304 in
cache_response.c
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
and how
fast and efficient we can detect it.
Ideas for how to express it in VCL are very welcome.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
to your active traffic.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
?
That would be a bug.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
Sorry for not looking at this earlier.
It was a bug that caused all requests, also piped ones, to be
rewritten to GET on the way to the backend.
Fixed in -trunk a minute ago.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
I've seen the automatic restart of the worker process fail here
during my testing, and I suspect you hit the same thing.
I have it on my list of things to investigate RSN.
Do you have any corefiles from varnishd by any chance ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
) not true.
errno = 2 (No such file or directory)
Abort trap
Can you check the man pages for dlclose() on your mac, and see if they
explain what it means when dlclose() fails this way ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
-d -d [your other options]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
);
___
varnish-commit mailing list
[EMAIL PROTECTED]
http://projects.linpro.no/mailman/listinfo/varnish-commit
--- End of Forwarded Message
From:Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Varnish can
In message [EMAIL PROTECTED], Denis Ahrens writes
:
Hi
here a logoutput from r1667 with default VCL:
Can I get you to check your clock relative to the backend ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
This should be fixed now.
Poul-Henning
In message [EMAIL PROTECTED], Denis Ahrens writes
:
On 12.07.2007, at 00:30, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Denis
Ahrens writes
:
Hi
here a logoutput from r1667 with default VCL:
Can I get you to check your clock
We have very little experience with performance tuning yet, as very
few people need to do any, Varnish is very frugal with hardware
resources.
Make sure your cache file is big enough, making it too big won't cost
you anything, so don't worry about it.
--
Poul-Henning Kamp | UNIX since
In message [EMAIL PROTECTED], Kamil
Radziszewski writes:
Can somebody help me with translation squid config file on varnish config ?
There is no simple way to do that.
You need to know what your squid does, then you need to implement
that in Varnish.
--
Poul-Henning Kamp | UNIX since
(anything else would be a configuration
error).
If you want to respect cache-control, you can implement it in
vcl_recv()
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
(
req.http.cookie,
.*LOCALIZER_LANGUAGE=\(..)\.*,
$1);
}
}
(If this work, please take a moment to add it to our FAQ!)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
of \
.*LOCALIZER_LANGUAGE=%22(..)%22.*
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= writes:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
shouldn't
vcl_hash {
req.hash +=3D req.http.cookie[LOCALIZER_LANGUAGE];
}
work, or haven't you implemented subscripting yet?
Not implemented yet.
--
Poul-Henning Kamp
(..)%22.*,
$1);
lookup;
}
[...]
}
sub vcl_hash {
set req.hash += req.http.mylang;
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
the transaction with the new url.
Not yet implemented however.
We have also talked about being able to have local content on the
varnish server, likely in the form of a .tar file, but this is also
yet to be implemented.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
:
sp-wrk-used = TIM_real();
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
Are there anything suspicious in your backends log when this happens ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
In message [EMAIL PROTECTED], Monty Ree writes:
Thanks for your help..
Can you give us temporary vcl or urgent patch which drop the GET, HEAD or
purge request which is not including Host header?
This is what you need:
http://varnish.projects.linpro.no/changeset/1930
--
Poul-Henning
{
set req.hash += req.http.cookie;
}
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
make this stuff more
flexible, but right now it is not on the todo list.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
behind.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc
In message [EMAIL PROTECTED], Cale
b Anthony writes:
Hello,
It doesn't appear that VCL supports case insensitive regular
expressions. Is this true?
Yes because I didn't think of that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
In message [EMAIL PROTECTED], Ricardo N
ewbery writes:
On Sep 19, 2007, at 10:35 AM, Poul-Henning Kamp wrote:
In message
[EMAIL PROTECTED], Cale
b Anthony writes:
Hello,
It doesn't appear that VCL supports case insensitive regular
expressions. Is this true?
Yes because I didn't think
on about 8 different cache servers).
As far as I can see, you have just cached more stuff than your RAM will
take and now the VM system moves stuff in and out of the paging area.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
of ESI:include because the included document can also contain
an ESI:include, and so on.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
be fixed in 2049
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
page is cached separately from the navbar, and on every request the
navbar is merged into the meat of the page just prior to delivery?
I'm working on it right now, it's called ESI includes and allow
you to do exactly that kind of thing.
See:
http://www.w3.org/TR/esi-lang
--
Poul-Henning
to impove somehow.
Under no circumstances should more than a few pools ( 5) be created.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
? If the attacker can move a source
file onto the box, he could just as well have moved the compiled
binary onto the box.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
ESI:includes should be ready for some testing in -trunk now, please
see:
http://varnish.projects.linpro.no/wiki/ESIfeatures
for documentation and how to get started.
Bug reports comments welcome as always...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
the compiled VCL and the varnishd binary.
It shouldn't be too much work to implement I think.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
,
this session will then have to go to the backend.
The idea here, is that when an object is not in the cache, we
should not send hordes of clients to the backend after it, if
the first one can do the job alone.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
control and he
therefore has other means of instruction (notably VCL).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
floating around which defines a Surrogate-Control
along the lines of Cache-Control but it seems to have little
backing and even less use.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
identification, but each match
can have multiple different objects, depending on the Vary header
and ttl.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
need for prefetch to work.
Also, how are purges done when variations exist? I'm guessing all
variations get purged. Is this correct?
Correct.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
as having
sendfile(2) issues today, so I would advice all of you to
disable sendfile to avoid the various problems we've seen.
The easiest way is to specify
-p sendfile_threshold=-1
to varnishd, or by using the CLI:
param.set sendfile_threshold -1
--
Poul-Henning Kamp | UNIX
sendfile enabled at all means that
you run a pretty old[1] version of varnish, so there are a number
of other bugs you may hit, but at least the one where sendfile
sends wrong data to the user should be gone.
Poul-Henning
[1] For such a young project obviously :-)
--
Poul-Henning Kamp | UNIX
shortcoming
(in addition to lacking the ability to send a header)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Lin
Jui-Nan Eric writes:
I am trying to replace squid with varnishd for reverse proxy. But I
found varnishd 1.1.2 sometimes responses 5xx, while varnishd 1.2 works
correctly.
Examine your varnishlog output to see why varnish gives 503.
--
Poul-Henning Kamp
. In that
case all the shmlog tailing programs can get confused.
How much traffic does your server take ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
() from /usr/lib/libthr.so.2
#12 0xb8489fec in ?? ()
Got this one during the night.
Was there any errno information available ? I belive the assert
message would have printed it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
-for: to lightttpd which it should
use in the logfile. You need to check the lighttpd config how to enable that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing list
tricky, and possibly a restart is a better way ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing
of this automatically as long as the Vary
header was set correctly. Is this not the case?
Correct.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
place to pick up something, nothing prevents
you from making that a backend of this varnish and doing
a pass on the request.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
localhost:82 localhost:83
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
not up to date on the various Linux kernels performance. You
can find some benchmarking material from Kris Kennaway, who's keeping
an eye on FreeBSD's scalability and often compares to various
Linux kernels here:
http://people.freebsd.org/~kris/scaling/
--
Poul-Henning Kamp | UNIX
we avoid.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish
In message [EMAIL PROTECTED], Mich
ael S. Fischer writes:
On Mon, Mar 17, 2008 at 8:57 AM, Poul-Henning Kamp [EMAIL PROTECTED] wrote:
No, we were talking about how long an idle backend connection is kept
open (or at least I was).
Yes I know :-)
And we don't do anything to close those
nearly cry when they realize that is possible :-)
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
and hit the
backend right away, even if other clients are already hitting the
backend for that object.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
is missing.
HTTP/1.1 200 Content-type: image/jpeg
But I agree, varnish shouldn't do this.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc mailing
___
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
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
that header from req.foobar to obj.foobar
and you should be all set.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
~ ^/test/) {
pass;
}
?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
the created the cached object.
What I want know is which backend was used in the director. Is that possible?
Hmm, not presently I'm afraid.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
have read/write access
to the storage file owned by root.
The file is opened before the cache process drops to nobody, and in
UNIX the access check is performed at open time and not at read/write
time.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
In message [EMAIL PROTECTED], Ricardo N
ewbery writes:
Assuming that nobody is an available user on your system, then is
the -u user option for varnishd superfluous?
Yes.
You can confirm the uid nobody is used with the ps(1) command.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
prospose
above, under the general assumption that if he were, varnish would
be the least of his troubles.
Can we be a bit serious here ?
Thanks.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
years.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
this should be SIZE_MAX.
Could you fix this please?
Sorry, I forgot to submit this change, done now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
In message [EMAIL PROTECTED], Per Andreas Buer writes:
Poul-Henning Kamp skrev:
* Open new network connections (no problem unless you use MAC or a
uid-matching firewall)
No, it accepts them only.
Does the privilegded prosess talk to the origin servers?
No.
--
Poul-Henning Kamp
didn't say which varnish version you are using, but we have fixed
a number of memory leaks in -trunk recently.
You should probably reduce the varnish storage file size to the
amount of RAM you are willing to spend on Varnish when you run
on the same machine as your backend.
--
Poul-Henning Kamp
you need to use hash.purge
CLI command and the hash string, by default is built from URL first
and host last, so the command to purge
http://foo.bar.com/index.html
would be:
hash.purge index.html#foo.bar.com#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
In message [EMAIL PROTECTED]
m, Pavel Pragin writes:
Hello,
Can you please help me put it the right order. I will be very great
full.
Put the purge stuff first.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
the / document.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
varnish-misc
any immediate effect, the objects are only thrown out
as we encounter them during our normal business.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
In message [EMAIL PROTECTED]
m, Pavel Pragin writes:
Will this have same effect:
varnishadm -T 127.0.0.1:6082 url.purge .
yes
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
operations with variables.
Sounds cool :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Max Clark writes:
How does Varnish handle the connections to the Origin? Is it possible
to have Varnish serve requests if the Origin is down?
Varnish does not contact the backend if the object it has in the cache is
good to be served.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Paul Nasrat writes:
Would it be possible to have a wiki editing bit set on my trac account
- pnasrat so I can update some of the information (eg Degraded-Grace
mode) and add some docs.
Done
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
Accept-encoding ?
Depends how you do the purge.
If you use the url.purge or hash.purge VCL primitives all matching
objects will be purged.
If you use the set obj.ttl = 0s way of purging, only the single
object you found in the cache will get purged.
--
Poul-Henning Kamp | UNIX since Zilog
the incoming domain name and just using the
path as the cache key. Example:
Which version of varnish ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
in VCL, but doing the
revalidation with the backend is not possible until it gets implemented.
If this is not possible, would you accept a patch to make this possible?
As above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
1 - 100 of 336 matches
Mail list logo
