Question from Dec. 2009: still using cache when fetching content
Hi. I've just subscribed, and have been reading through the e-mail archives for varnish-misc. In Dec. 2009, Jean-Christophe Petit asked (with subject still using cache when fetching content): - Is it possible to make Varnish sending the cache content at the same time it is fetching from the backend ? It will be more efficient for slow dynamic content ;) For example, I have a php page taking up to 5sec to run. If Varnish was able to get it while still sending the old cache page, it would be really great. No more unlucky visitor hitting it to update the cache.. - There were a couple of replies, but I just wanted to flesh out the use case: I think the scenario would be: (1) There is a page that takes a very long time to render (say, 90 seconds) (2) It is cached, perhaps to expire after an hour (3) In normal usage, everyone gets the cached page and is very happy (4) An administrator would like to refresh that page in the cache BEFORE the hour is up; but give any user the earlier cached page (6) The admin would like a mechanism: Please refresh now with this request, but until the request is finished, serve whatever is in the cache. This is different from grace, 'cos no one (except the admin) is incurring the wait; and also the admin is asking for a refresh before the cached page has expired. Is this a feature that can be simulated in Varnish? Or a feature that might be added at some time? What we're concerned about is Google's timing of page download. If we set a cache period to, say, an hour, and Google incurs the first hit after cache expiry, then it (Google) has to wait for the finished page. In grace mode, requests after the Google hit would get the earlier cached page; but, still, Google has measured the page as taking, say, 60 seconds to download. In the model above, Google would get the cached page; it would just be stale. Thoughts? John ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question from Dec. 2009: still using cache when fetching content
I think Chris Davies has straightened me out, and that the scenario I describe *is* covered by grace -- that the first hit would also get stale (as well as others in the grace period), which is exactly what I want. On Fri, Jan 8, 2010 at 4:20 PM, John Norman j...@7fff.com wrote: Hi. I've just subscribed, and have been reading through the e-mail archives for varnish-misc. In Dec. 2009, Jean-Christophe Petit asked (with subject still using cache when fetching content): - Is it possible to make Varnish sending the cache content at the same time it is fetching from the backend ? It will be more efficient for slow dynamic content ;) For example, I have a php page taking up to 5sec to run. If Varnish was able to get it while still sending the old cache page, it would be really great. No more unlucky visitor hitting it to update the cache.. - There were a couple of replies, but I just wanted to flesh out the use case: I think the scenario would be: (1) There is a page that takes a very long time to render (say, 90 seconds) (2) It is cached, perhaps to expire after an hour (3) In normal usage, everyone gets the cached page and is very happy (4) An administrator would like to refresh that page in the cache BEFORE the hour is up; but give any user the earlier cached page (6) The admin would like a mechanism: Please refresh now with this request, but until the request is finished, serve whatever is in the cache. This is different from grace, 'cos no one (except the admin) is incurring the wait; and also the admin is asking for a refresh before the cached page has expired. Is this a feature that can be simulated in Varnish? Or a feature that might be added at some time? What we're concerned about is Google's timing of page download. If we set a cache period to, say, an hour, and Google incurs the first hit after cache expiry, then it (Google) has to wait for the finished page. In grace mode, requests after the Google hit would get the earlier cached page; but, still, Google has measured the page as taking, say, 60 seconds to download. In the model above, Google would get the cached page; it would just be stale. Thoughts? John ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about Cache Purge
On Thu, Jul 09, 2009 at 02:17:35PM -0500, Brian Pan wrote: Hi all, I have a newbie question regarding 'purging the cache.' When I run the following command to purge the root domain of my website, varnishadm -T localhost:80 purge.url ^/$ Are you sure the admin interface is at port 80? That sounds very unlikely. How do you start varnishd? Varnish can listen to _two_ ports, one is typically port 80, where normal HTTP data is served, the other is an administrative interface, which is what you want to specify with -T. -- Kristian Lyngstøl Redpill Linpro AS Tlf: +47 21544179 Mob: +47 99014497 pgp48o51KyH9R.pgp Description: PGP signature ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Question about Cache Purge
Hi all,
I have a newbie question regarding 'purging the cache.' When I run the
following command to purge the root domain of my website,
varnishadm -T localhost:80 purge.url ^/$
I get this error:
An error occured in receiving status.
Based on examples, I've setup my VCL as follows:
//
acl purge {
localhost;
my local ip address;
}
sub vcl_recv {
# Allow wildcard purging
if (req.request == PURGE){
if (!client.ip ~ purge) {
error 405 Not allowed.;
}
purge_url(req.url); }
...
//***
Any help would be greatly appreciated.
Thanks,
Brian
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
]] Poul-Henning Kamp | In message 5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com, Ken Brownfield wri | tes: | | Would a stack overflow take out the whole child, or just that thread? | | The kernel would try to extend the stack and provided you are not on | a 32 bit system, it shouldn't ever have a problem with that. On the other hand, the gain from decreasing the stack size would just be a bit less book-keeping for the kernel, unless you have overcommit turned off (which I don't think anybody actually uses), right? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
Overcommit defaults off; sane use cases for overcommit are few and far between, IMHO. With overcommit on, the performance implications might be more of a wash... but then you have two problems. Even though the stack remains mostly unused, it would still have to be swapped out under memory pressure, and thread creation and reclamation would cause more swap thrash. Used or not, the performance pain is the same. Plus I'd rather not allocate/waste 8GB of RAM for 1,000 varnish threads at idle, which represents two orders of magnitude more than it needs. A 1MB limit holds up fine for me, though 256KB or even 128KB should be fine as well, since Varnish tends to sit at around 86KB under Linux/ x86_64. Maybe Varnish could have its own stacksize parameter, rather than using the ulimit value? Out-of-box scalability would be much better, and this is how MySQL handles it, FWIW. -- Ken. On Jun 30, 2009, at 5:11 PM, Tollef Fog Heen wrote: ]] Poul-Henning Kamp | In message 5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com, Ken Brownfield wri | tes: | | Would a stack overflow take out the whole child, or just that thread? | | The kernel would try to extend the stack and provided you are not on | a 32 bit system, it shouldn't ever have a problem with that. On the other hand, the gain from decreasing the stack size would just be a bit less book-keeping for the kernel, unless you have overcommit turned off (which I don't think anybody actually uses), right? -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Thread memory allocation question
When looking at /proc/map info for varnish threads, I'm seeing the following allocations in numbers that essentially match the child count: 40111000 8192K rw---[ anon ] And this at almost double the child count: 7f4d5790 1024K rw---[ anon ] For example, for 64 worker threads, I see 69 of the 8192K allocations, and 121 of the 1024K allocations. For 32 worker threads I see 37 and 82, respectively. I noticed some pretty intense memory usage when I had a backend issue and the thread count increased into the hundreds. Obviously the threads will need memory as they scale, but are these large allocations intentional, and are they tunable (beyond the relatively small workspaces?) Many thanks, -- Ken. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
]] Ken Brownfield | When looking at /proc/map info for varnish threads, I'm seeing the | following allocations in numbers that essentially match the child count: | | 40111000 8192K rw---[ anon ] Looks like the default stack size. | And this at almost double the child count: | | 7f4d5790 1024K rw---[ anon ] Unsure what this is. | I noticed some pretty intense memory usage when I had a backend issue | and the thread count increased into the hundreds. Obviously the | threads will need memory as they scale, but are these large | allocations intentional, and are they tunable (beyond the relatively | small workspaces?) You should be able to tune it using ulimit -s. If you turn it too low, things will break, though. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote: | 40111000 8192K rw---[ anon ] Looks like the default stack size. Ah, of course. Good find, thanks. I'm thinking it might be nice to have a thread track its stack history and emit its approximate largest size when it's reaped (and the workspaces too I suppose). Would a stack overflow take out the whole child, or just that thread? The 1024K blocks roughly add up to the SMA outstanding bytes, so I'm assuming these are jemalloc block allocations, and not related to thread count: lib/jemalloc/malloc.c: #define CHUNK_2POW_DEFAULT 20 Thanks! -- Ken. On Jun 19, 2009, at 7:15 AM, Tollef Fog Heen wrote: ]] Ken Brownfield | When looking at /proc/map info for varnish threads, I'm seeing the | following allocations in numbers that essentially match the child count: | | 40111000 8192K rw---[ anon ] Looks like the default stack size. | And this at almost double the child count: | | 7f4d5790 1024K rw---[ anon ] Unsure what this is. | I noticed some pretty intense memory usage when I had a backend issue | and the thread count increased into the hundreds. Obviously the | threads will need memory as they scale, but are these large | allocations intentional, and are they tunable (beyond the relatively | small workspaces?) You should be able to tune it using ulimit -s. If you turn it too low, things will break, though. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Thread memory allocation question
In message 5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com, Ken Brownfield wri tes: Would a stack overflow take out the whole child, or just that thread? The kernel would try to extend the stack and provided you are not on a 32 bit system, it shouldn't ever have a problem with that. -- 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: Newbie question
]] Monah Baki | Here is part of the logs, how can I tell it's working? It doesn't seem to be caching, most likely because the backend sets a cookie (which means we, by default, don't cache). -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
a question
Hi, Can anyone explain to me those varnishlog entries mean ? 0 ExpPick - 1369849794 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1369849794 -10 They always come in this order. Thanks J ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: a question
Shahar Fleischman sha...@mindu.co.il writes: Can anyone explain to me those varnishlog entries mean ? 0 ExpPick - 1369849794 ttl 0 VCL_call - timeout 0 VCL_return - discard 0 ExpKill - 1369849794 -10 Object 1369849794 was selected as a candidate for expiry on the basis of its ttl; vcl_timeout was called and returned discard; the object was then destroyed. DES -- Dag-Erling Smørgrav - d...@des.no ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
2 varnish server work together config question
Hi all, Up to now, i'm been running standalone varnish on 2 servers (for redundoncy). I've been asked to have those 2 varnish work together : if there is miss on server1, server1 asks server2 (in case server2 has the object in cache), before asking the backend Do any of you have any comments/thoughts about this ? (it does make sense..i think) This is doable using Directors in vcl (a failover algorithm would be optimal, rather than round-robin or random) Any other solutions ? Olivier ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Configuration question about a domain list for a http.req.host comparaison
Tollef Fog Heen a écrit : ]] Damien Desmarets | I have 1 question for you. I haven't found the response in the | documentation/wiki. I think you have a big job to wrtie a good | documentation ... the current is really poor ! If you want to help out with writing docs or suggest weak points, you are more than welcome. Yes of course, but to begin I need a good documentation to have solids foundations! And after this, be sure i will post modification/add in your wiki documentation. | Is it possible to do this in VCL origin configuration? Not at the moment, no. What I would suggest is you write a small script in your favourite language that generates the VCL for you. Yes sure, and modify the init.d script ... or I can try to add this particularity inside libvcl directly. I'm going to see the difficulty to implement this. Thank for the support, Damien Desmarets ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Configuration question about a domain list for a http.req.host comparaison
]] Damien Desmarets | I have 1 question for you. I haven't found the response in the | documentation/wiki. I think you have a big job to wrtie a good | documentation ... the current is really poor ! If you want to help out with writing docs or suggest weak points, you are more than welcome. | Is it possible to do this in VCL origin configuration? Not at the moment, no. What I would suggest is you write a small script in your favourite language that generates the VCL for you. -- Tollef Fog Heen Redpill Linpro -- Changing the game! t: +47 21 54 41 73 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Configuration question about a domain list for a http.req.host comparaison
Hello,
I have 1 question for you. I haven't found the response in the
documentation/wiki. I think you have a big job to wrtie a good
documentation ... the current is really poor !
So the question.
I have a list of differents domains:
azeazeaze.com
eruigeiogr.com
zezeirjiorf.com
...
My configuration file is actually like this:
if (req.http.host ~
^(azeazeaze.com|eruigeiogr.com|zezeirjiorf.com|...)$) {
set req.backend = principal_delivery;
} elsif (req.http.host ~
^(aazeazeazeaze.com|azeiazjeaioze.com|azejoazjeaiozejoaz.com|...)$) {
set req.backend = pictures_delivery;
} else {
error 403 Not supported
}
The regex comparison is very big with maybe 100 domains. It's not clear
inside my file, and difficult to made change.
Is it possible to include those domains in a list and match this list to
the req.http.host. Like this maybe:
#define DOMAINS_PRINCIPAL_LIST domains_principal_list.txt
#define DOMAINS_PICTURES_LIST domains_pictures_list.txt
if (req.http.host ~ DOMAINS_PINCIPAL_LIST) {
set req.backend = principal_delivery;
} elsif (req.http.host ~ DOMAINS_PICTURES_LIST) {
set req.backend = pictures_delivery;
} else {
error 403 Not supported
}
I know the constant don't contain regex valid content but it's a
pseudo-code to show you the idea.
And my file domains_principal_list.txt contains for exemple:
azeazeaze.com
eruigeiogr.com
zezeirjiorf.com
Is it possible to do this in VCL origin configuration?
Thank for your help.
Regards,
Damien Desmarets
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: question about configure warning
Michael S. Fischer mich...@dynamine.net writes: What are these non-Linux-specific issues to which the document refers? The lack of a completion indicator + various implementation bugs. The only OS I know of that has a usable implementation is FreeBSD 8. DES -- Dag-Erling Smørgrav - d...@des.no ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
question about configure warning
Hi all I'm setting up an amd64 box (that is intel xeon x86_64) with ubuntu 8.04 and varnish 2.0.2, and configure gives me a warning about sendfile configure: WARNING: won't look for sendfile() on x86_64-unknown- linux-gnu Does this mean it won't be using sendfile() on this system? roy -- Roy Sigurd Karlsbakk (+47) 98013356 r...@karlsbakk.net -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er en elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: question about configure warning
Roy Sigurd Karlsbakk wrote: Does this mean it won't be using sendfile() on this system? If I recall correctly, it won't be using sendfile() on *almost all* systems (except certain versions of BSD?). From the porting pages: The build system will automatically detect the availability of epoll() and build the corresponding cache_acceptor. It will also automatically detect the availability of sendfile(), though its use is discouraged (and disabled by default) due to a variety of non-Linux-specific issues. (http://varnish.projects.linpro.no/wiki/Porting/Linux/2.6) best wishes, Marcus -- Marcus Smith Information Officer The Council for British Archaeology ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: question about configure warning
On Jan 6, 2009, at 7:42 AM, Marcus Smith wrote: The build system will automatically detect the availability of epoll() and build the corresponding cache_acceptor. It will also automatically detect the availability of sendfile(), though its use is discouraged (and disabled by default) due to a variety of non-Linux-specific issues. (http://varnish.projects.linpro.no/wiki/Porting/Linux/2.6) What are these non-Linux-specific issues to which the document refers? --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Varnishreplay question
Hi, I've been playing with Varnish for a couple of months now: impressive, really ! I would like to replay Apache logs. Is there a way to run varnishreplay -r ncsa-file ? If no, could that be consider as a future enhancement ? Thx by advance, Serge ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Question about purge_url purge_hash
Hi all,
I configured the Varnish 1.1.2-r2635 to allow purging from backoffice
web servers. The first version of this concept is very easy, just send
PURGE request for specific URL to Varnish servers.
Configuraiton,
VCL_RECV
if (req.request == PURGE) {
if (client.ip ~ backoffice) {
lookup;
}
}
VCL_HIT
if (req.request == PURGE) {
set obj.ttl = 0s;
error 200 Purged;
}
This above configuration is working fine but the application owner would
like to purge some URL that contains multiple paging in only one PURGE
request. The example is
http://myhost.com/path/to/index.php?id=123page=1
http://myhost.com/path/to/index.php?id=123page=2
http://myhost.com/path/to/index.php?id=123page=3
Sometimes, the maximum page can be more than 1000. So, we think about
purge_url(req.http) but it always return MISS when we input the URL with
REGEX.
What did we test the VCL configuration
1. use WFETCH to get content from varnish with the following request
headers,
GET /path/to/file.gif HTTP/1.0\r\n
Host: myhost.com\r\n
Accept-Encoding: gzip\r\n
2. use WFETCH to purge content from varnish with the following request
headers,
PURGE /path/to/file.gif HTTP/1.0\r\n
Host: myhost.com\r\n
Accept-Encoding: gzip\r\n
We can purged the object in this step
3. We tried,
PURGE \.gif$ HTTP/1.0\r\n
Host: myhost.com\r\n
Accept-Encoding: gzip\r\n
But this one can not be purged which we require this kind of purging
style (allow REGEX)
Could anyone provide the valid use of purge_url or purge_hash in both
vcl_recv and vcl_hit? and how can we input the REGEX url into purging
request?
Thank you.
Phuwadon D.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... If I want to have Debian, is it AMD64 version that I should go for? (OT) / E Poul-Henning Kamp skrev: In message [EMAIL PROTECTED], Erik Torlen writes: I still have the same problem :( The threads are created up to 238 where they are stopped, even if I set threads_max = 1000 and threads_pools = 2 (or 3). I also tested the tips and decreased the stack sixe to 512 and increased overflow_max to 1% . Any idea what could be wrong? Are you running on a 32bit or 64bit system ? On a 32bit system you may simply be running out of address-space... ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
In message [EMAIL PROTECTED], Erik Torlen writes: Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... If I want to have Debian, is it AMD64 version that I should go for? (OT) 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 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: Question about threads
Erik Torlen skrev: Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... Maybe the init script should issue a warning that a 32bit arch is only usable as a test enviroment. Per. signature.asc Description: OpenPGP digital signature ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
In message [EMAIL PROTECTED], Per Buer writes: Maybe the init script should issue a warning that a 32bit arch is only usable as a test enviroment. Well, Varnish is generally usable in 32bit, provided you have very small content, so I'm hessitant to rule it entirely out, but yes, we clearly need to push the 64bit angle. -- 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 list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
RE: Re: Question about threads
Thanks for the tips, I will test this and come back with the result. / E Original Message --- On Wed, 18 Jun 2008 13:24:52 -0700 Michael S. Fischer [EMAIL PROTECTED] wrote: On Wed, Jun 18, 2008 at 4:51 AM, Rafael Umann [EMAIL PROTECTED] wrote: If it is a 32bits system, probably the problem is that your stack size is 10Mb. So 238 * 10mb = ~2gb I decreased my stack size to 512Kb. Using 1gb storage files i can now open almost 1900 threads using all the 2gb that 32bits can alloc. So, my Varnish makes 2 hits/second serving clients! What is your request:connection ratio? Best regards, --Michael Unfortunately now i dont have servers doing 2 hits/second, and thats why i dont have stats for you. I have 6 servers runing this service now, each one doing 5500 hits/sec with 10% CPU usage, and this infrastructure scales to 2 hits/sec each server. For test purpose only i let just 2 servers with all the traffic, so i saw this limit i told you. In this 2 hits/sec im seeing two bottle necks: 1. The 32bits arch (cant open threads and the storage file is too small), so im moving into 64bits. 2. The cpu usage of the listener process with 2 hits/sec is getting to 100% in one CPU (we also made a patch to improve CPU usage, and it is avaliable in this last trunk version.. without this patch varnish was doing 8000 hits/sec). But anyway, i spoke to Poul, and he told me that the listener process will be changed soon (i really hope so, because i would love to use more than 30% of my cpu!). Anyway, varnish is doing a great job for me!!! Some stats taken now with 5500 hits/sec: # netstat -nap|grep :80 |grep SYN_REC |wc -l 166 # netstat -nap|grep :80 |grep ESTAB |wc -l 17139 # netstat -nap|grep :80 |grep FIN |wc -l 1454 # netstat -nap|grep :80 |grep TIME_W |wc -l 7766 # varnishstat Hitrate ratio: 10 13 13 Hitrate avg: 0.9990 0.9990 0.9990 36189916 476.66 250.71 Client connections accepted 404804204 5494.13 2804.30 Client requests received 391586079 5335.24 2712.74 Cache hits 10975643 157.8976.03 Cache hits for pass 1125709 1.00 7.80 Cache misses 12101360 158.8983.83 Backend connections success 0 0.00 0.00 Backend connections failures 0 0.00 0.00 Backend connections reuses 11139673 141.9077.17 Backend connections recycles 350-1.00 0.00 Backend connections unused 13447 .. N struct srcaddr 11353 .. N active struct srcaddr 30351 .. N struct sess_mem 17391 .. N struct sess 47069 .. N struct object 47080 .. N struct objecthead 97813 .. N struct smf 4185 .. N small free smf 5 .. N large free smf 0 .. N struct vbe_conn 556 .. N worker threads 556 0.00 0.00 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 556 0.00 0.00 N overflowed work requests 0 0.00 0.00 N dropped work requests 0 .. N expired objects 1079159 .. N LRU nuked objects 0 .. N LRU saved objects 0 .. N objects on deathrow 48 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile 135051222 1812.72 935.58 Objects sent with write 36189893 494.65 250.71 Total Sessions 404810596 5491.13 2804.35 Total Requests 0 0.00 0.00 Total pipe 0 0.00 0.00 Total pass 12101371 158.8983.83 Total fetch 93389657948 1269372.98646962.32 Total header bytes 418107385660 5962840.69 2896463.38 Total body bytes 541249189.9437.50 Session Closed 0 0.00 0.00 Session Pipeline 1623343 0.0011.25 Session Read Ahead 398293975 5409.19 2759.20 Session herd 15780035398212996.82109317.12 SHM records 516154306 6307.55 3575.69 SHM writes 266181533.9818.44 SHM MTX contention 23279696 242.83 161.27 allocator requests 93623 .. outstanding allocations 910299136 .. bytes allocated []s, -- Rafael Umann [EMAIL PROTECTED] Suporte
Re: Question about threads
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: 1. The 32bits arch (cant open threads and the storage file is too small), so im moving into 64bits. Yes, 32bit is generally not big enough to Varnish for non-trivial workloads. 2. The cpu usage of the listener process with 2 hits/sec is getting to 100% in one CPU. You may want to try to update to a -trunk version and play a bit with the session_linger parameter, every time you get a tick in the Session Linger counter, that's one request that took a shortcut. I have an idea for a more comprehensive shortcut for new sessions but that will have to wait until after 2.0. -- 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 list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Little question about the releases of Varnish
* Oliver Oli | are there any debian buildpackage scripts available? Yes, you get them in the debian/ directory if you do a subversion checkout. -- Tollef Fog Heen / Linpro ASt: 21 54 41 73 UNIX is user friendly, it's just picky about who its friends are ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
how about your storage file size? []s, On Mon, 23 Jun 2008 21:20:59 +0200 Erik Torlen [EMAIL PROTECTED] wrote: I still have the same problem :( The threads are created up to 238 where they are stopped, even if I set threads_max = 1000 and threads_pools = 2 (or 3). I also tested the tips and decreased the stack sixe to 512 and increased overflow_max to 1% . Any idea what could be wrong? / E [EMAIL PROTECTED] skrev: Thanks for the tips, I will test this and come back with the result. / E E-mail verificado pelo Terra Anti-Spam. Para classificar como spam ou não spam, visite http://mail.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCY1ODAyNDQ3I3Blcm0hdGVycmEmMSwxMjE0MjQ4ODYwLjkzNTUyMC4yNTIxOS5nYW5hbm9xdWUudGVycmEuY29tLDE3MTA= Verifique periodicamente a pasta Spam para garantir que apenas mensagens indesejadas sejam classificadas como Spam. Esta mensagem foi verificada pelo E-mail Protegido Terra. Atualizado em 23/06/2008 -- Rafael Umann [EMAIL PROTECTED] Suporte Engenharia 1 Terra Networks Brasil S/A Tel: 55 (51) 3284-4344 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
In message [EMAIL PROTECTED], Erik Torlen writes: I still have the same problem :( The threads are created up to 238 where they are stopped, even if I set threads_max = 1000 and threads_pools = 2 (or 3). I also tested the tips and decreased the stack sixe to 512 and increased overflow_max to 1% . Any idea what could be wrong? Are you running on a 32bit or 64bit system ? On a 32bit system you may simply be running out of address-space... -- 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 list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Little question about the releases of Varnish
are there any debian buildpackage scripts available? On Sat, Jun 21, 2008 at 11:59 AM, Poul-Henning Kamp [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Damien Sarazin writes: My question is : should i continue to work with the 1.1.2 release or is the 1.2 version stable enough so i can use this last one ? Actually, we are heading into the 2.0 release cycle, so you should grab a -trunk copy from SVN and look at that. The first 2.0 release preview will be rolled real soon now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Little question about the releases of Varnish
In message [EMAIL PROTECTED], Damien Sarazin writes: My question is : should i continue to work with the 1.1.2 release or is the 1.2 version stable enough so i can use this last one ? Actually, we are heading into the 2.0 release cycle, so you should grab a -trunk copy from SVN and look at that. The first 2.0 release preview will be rolled real soon now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
On Wed, 18 Jun 2008 13:24:52 -0700 Michael S. Fischer [EMAIL PROTECTED] wrote: On Wed, Jun 18, 2008 at 4:51 AM, Rafael Umann [EMAIL PROTECTED] wrote: If it is a 32bits system, probably the problem is that your stack size is 10Mb. So 238 * 10mb = ~2gb I decreased my stack size to 512Kb. Using 1gb storage files i can now open almost 1900 threads using all the 2gb that 32bits can alloc. So, my Varnish makes 2 hits/second serving clients! What is your request:connection ratio? Best regards, --Michael Unfortunately now i dont have servers doing 2 hits/second, and thats why i dont have stats for you. I have 6 servers runing this service now, each one doing 5500 hits/sec with 10% CPU usage, and this infrastructure scales to 2 hits/sec each server. For test purpose only i let just 2 servers with all the traffic, so i saw this limit i told you. In this 2 hits/sec im seeing two bottle necks: 1. The 32bits arch (cant open threads and the storage file is too small), so im moving into 64bits. 2. The cpu usage of the listener process with 2 hits/sec is getting to 100% in one CPU (we also made a patch to improve CPU usage, and it is avaliable in this last trunk version.. without this patch varnish was doing 8000 hits/sec). But anyway, i spoke to Poul, and he told me that the listener process will be changed soon (i really hope so, because i would love to use more than 30% of my cpu!). Anyway, varnish is doing a great job for me!!! Some stats taken now with 5500 hits/sec: # netstat -nap|grep :80 |grep SYN_REC |wc -l 166 # netstat -nap|grep :80 |grep ESTAB |wc -l 17139 # netstat -nap|grep :80 |grep FIN |wc -l 1454 # netstat -nap|grep :80 |grep TIME_W |wc -l 7766 # varnishstat Hitrate ratio: 10 13 13 Hitrate avg: 0.9990 0.9990 0.9990 36189916 476.66 250.71 Client connections accepted 404804204 5494.13 2804.30 Client requests received 391586079 5335.24 2712.74 Cache hits 10975643 157.8976.03 Cache hits for pass 1125709 1.00 7.80 Cache misses 12101360 158.8983.83 Backend connections success 0 0.00 0.00 Backend connections failures 0 0.00 0.00 Backend connections reuses 11139673 141.9077.17 Backend connections recycles 350-1.00 0.00 Backend connections unused 13447 .. N struct srcaddr 11353 .. N active struct srcaddr 30351 .. N struct sess_mem 17391 .. N struct sess 47069 .. N struct object 47080 .. N struct objecthead 97813 .. N struct smf 4185 .. N small free smf 5 .. N large free smf 0 .. N struct vbe_conn 556 .. N worker threads 556 0.00 0.00 N worker threads created 0 0.00 0.00 N worker threads not created 0 0.00 0.00 N worker threads limited 0 0.00 0.00 N queued work requests 556 0.00 0.00 N overflowed work requests 0 0.00 0.00 N dropped work requests 0 .. N expired objects 1079159 .. N LRU nuked objects 0 .. N LRU saved objects 0 .. N objects on deathrow 48 0.00 0.00 HTTP header overflows 0 0.00 0.00 Objects sent with sendfile 135051222 1812.72 935.58 Objects sent with write 36189893 494.65 250.71 Total Sessions 404810596 5491.13 2804.35 Total Requests 0 0.00 0.00 Total pipe 0 0.00 0.00 Total pass 12101371 158.8983.83 Total fetch 93389657948 1269372.98646962.32 Total header bytes 418107385660 5962840.69 2896463.38 Total body bytes 541249189.9437.50 Session Closed 0 0.00 0.00 Session Pipeline 1623343 0.0011.25 Session Read Ahead 398293975 5409.19 2759.20 Session herd 15780035398212996.82109317.12 SHM records 516154306 6307.55 3575.69 SHM writes 266181533.9818.44 SHM MTX contention 23279696 242.83 161.27 allocator requests 93623 .. outstanding allocations 910299136 .. bytes allocated []s, -- Rafael Umann [EMAIL PROTECTED] Suporte Engenharia 1 Terra Networks Brasil S/A Tel: +55 (51) 3284-4344 ___
Re: Question about threads
On Thu, Jun 19, 2008 at 5:37 AM, Rafael Umann [EMAIL PROTECTED] wrote: What is your request:connection ratio? Unfortunately now i dont have servers doing 2 hits/second, and thats why i dont have stats for you. Actually, it's right there in your varnishstat output: 36189916 476.66 250.71 Client connections accepted 404804204 5494.13 2804.30 Client requests received Your request:connection ratio is 10:1! This is a very good situation to be in. varnish doesn't have to spawn nearly as many threads as it would if the ratio were lower, as is common at many other sites. I have 6 servers runing this service now, each one doing 5500 hits/sec with 10% CPU usage, and this infrastructure scales to 2 hits/sec each server. It's probably inaccurate to assume that things will scale linearly :) Best regards, --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
On Thu, 19 Jun 2008 08:05:21 -0700 Michael S. Fischer [EMAIL PROTECTED] wrote: On Thu, Jun 19, 2008 at 5:37 AM, Rafael Umann [EMAIL PROTECTED] wrote: What is your request:connection ratio? Unfortunately now i dont have servers doing 2 hits/second, and thats why i dont have stats for you. Actually, it's right there in your varnishstat output: 36189916 476.66 250.71 Client connections accepted 404804204 5494.13 2804.30 Client requests received Your request:connection ratio is 10:1! This is a very good situation to be in. varnish doesn't have to spawn nearly as many threads as it would if the ratio were lower, as is common at many other sites. OK, what i meant is that i dont have the stats for the amount of hits/second that i told u. Anyway, with this amount of traffic, with this timeouts that i set, it will probablly be the same. I have 6 servers runing this service now, each one doing 5500 hits/sec with 10% CPU usage, and this infrastructure scales to 2 hits/sec each server. It's probably inaccurate to assume that things will scale linearly :) Its not with Varnish :) actually i was surprised with this, but it scales almost linearly to the 2 hits/sec (ok, ok, with a litle bit of response time decrease), but it dont go any further. Best regards, --Michael E-mail verificado pelo Terra Anti-Spam. Para classificar como spam ou não spam, visite http://mail.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCY1ODAyNDQ3I3Blcm0hdGVycmEmMSwxMjEzODg3OTIzLjk1ODU0MC4xNjgyMC5nYW5hbm9xdWUudGVycmEuY29tLDU0Mzc= Verifique periodicamente a pasta Spam para garantir que apenas mensagens indesejadas sejam classificadas como Spam. Esta mensagem foi verificada pelo E-mail Protegido Terra. Atualizado em 19/06/2008 -- Rafael Umann [EMAIL PROTECTED] Suporte Engenharia 1 Terra Networks Brasil S/A Tel: 55 (51) 3284-4344 ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
On Wed, Jun 18, 2008 at 4:51 AM, Rafael Umann [EMAIL PROTECTED] wrote: If it is a 32bits system, probably the problem is that your stack size is 10Mb. So 238 * 10mb = ~2gb I decreased my stack size to 512Kb. Using 1gb storage files i can now open almost 1900 threads using all the 2gb that 32bits can alloc. So, my Varnish makes 2 hits/second serving clients! What is your request:connection ratio? Best regards, --Michael ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Question about threads
I recently made a loadtest against through varnish. First I received a very high response time and found out that varnish was maxing the maximum nr of threads. I updated thread_min = 5 and thread_max = 300 and recevied much better resp. times. Then I increased the nr of concurrent users and made another loadtest. The strange thing here was that I received high resp. times but the threads stopped at 238. The N worker threads not created increased rapidly. I increased the threads again and changed listen_depth to 2048. Here is all the numbers: 238 0.00 0.22 N worker threads created 1318 4.98 1.21 N worker threads not created 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory default_ttl120 [seconds] thread_pools 2 [pools] thread_pool_max400 [threads] thread_pool_min10 [threads] thread_pool_timeout120 [seconds] thread_pool_purge_delay1000 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_add_delay 10 [milliseconds] thread_pool_fail_delay 200 [milliseconds] overflow_max 100 [%] rush_exponent 3 [requests per request] sess_workspace 8192 [bytes] obj_workspace 8192 [bytes] sess_timeout 5 [seconds] pipe_timeout 60 [seconds] send_timeout 600 [seconds] auto_restart on [bool] fetch_chunksize128 [kilobytes] vcl_trace off [bool] listen_address 0.0.0.0:80 listen_depth 2048 [connections] srcaddr_hash 1049 [buckets] srcaddr_ttl30 [seconds] backend_http11 off [bool] client_http11 off [bool] cli_timeout5 [seconds] ping_interval 3 [seconds] lru_interval 2 [seconds] cc_command exec cc -fpic -shared -Wl,-x -o %o %s max_restarts 4 [restarts] max_esi_includes 5 [restarts] cache_vbe_connsoff [bool] connect_timeout400 [ms] cli_buffer 8192 [bytes] diag_bitmap0x0 [bitmap] Why do I get Create worker thread failed 12 Cannot allocate memory when I had 1900MB free RAM and 65GB free Disk on the server? Any ideas? If N worker threads not created is increasing, is that a bad sign? Thanks Duja ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
Raising the number of threads will not significantly improve Varnish concurrency in most cases. I did a test a few months ago using 4 CPUs on RHEL 4.6 with very high request concurrency and a very low request-per-connection ratio (i.e., 1:1, no keepalives) and found that the magic number is about 16 threads/CPU. You should raise overflow_max to a very high value (1% worked just fine for us). Under optimal operating conditions you should not see the threads not created value increasing like this. Best regards, --Michael On Tue, Jun 17, 2008 at 3:37 AM, [EMAIL PROTECTED] wrote: I recently made a loadtest against through varnish. First I received a very high response time and found out that varnish was maxing the maximum nr of threads. I updated thread_min = 5 and thread_max = 300 and recevied much better resp. times. Then I increased the nr of concurrent users and made another loadtest. The strange thing here was that I received high resp. times but the threads stopped at 238. The N worker threads not created increased rapidly. I increased the threads again and changed listen_depth to 2048. Here is all the numbers: 238 0.00 0.22 N worker threads created 1318 4.98 1.21 N worker threads not created 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory 0 Debug- Create worker thread failed 12 Cannot allocate memory default_ttl120 [seconds] thread_pools 2 [pools] thread_pool_max400 [threads] thread_pool_min10 [threads] thread_pool_timeout120 [seconds] thread_pool_purge_delay1000 [milliseconds] thread_pool_add_threshold 2 [requests] thread_pool_add_delay 10 [milliseconds] thread_pool_fail_delay 200 [milliseconds] overflow_max 100 [%] rush_exponent 3 [requests per request] sess_workspace 8192 [bytes] obj_workspace 8192 [bytes] sess_timeout 5 [seconds] pipe_timeout 60 [seconds] send_timeout 600 [seconds] auto_restart on [bool] fetch_chunksize128 [kilobytes] vcl_trace off [bool] listen_address 0.0.0.0:80 listen_depth 2048 [connections] srcaddr_hash 1049 [buckets] srcaddr_ttl30 [seconds] backend_http11 off [bool] client_http11 off [bool] cli_timeout5 [seconds] ping_interval 3 [seconds] lru_interval 2 [seconds] cc_command exec cc -fpic -shared -Wl,-x -o %o %s max_restarts 4 [restarts] max_esi_includes 5 [restarts] cache_vbe_connsoff [bool] connect_timeout400 [ms] cli_buffer 8192 [bytes] diag_bitmap0x0 [bitmap] Why do I get Create worker thread failed 12 Cannot allocate memory when I had 1900MB free RAM and 65GB free Disk on the server? Any ideas? If N worker threads not created is increasing, is that a bad sign? Thanks Duja ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Conditional caching question
In message [EMAIL PROTECTED], David Pratt writes: Hi. Sorry for not getting back sooner. The use case I have is have backend determine when frequency reaches a threshold and set ttl dynamically based on the rate. [...] And Varnish is a perfect frontend for that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Conditional caching question
Hi. Sorry for not getting back sooner. The use case I have is have backend determine when frequency reaches a threshold and set ttl dynamically based on the rate. My goal is to tune cache using rates and ttl values to ensure only most requested makes it into the cache as opposed to adding 'bulk'. I am simply experimenting at this stage but believe it can result in a sort of 'smart caching' to maximize the benefit of the cache for content in demand while minimizing the overall cache resource to deliver the resources. I am sure that somewhere here is an algorithm for that can provide some decent cache regulation for utilization and size. Its all a bit of a balancing act with the responsible for the backend as well I realize. Many thanks. Regards David Barry Abrahamson wrote: On Jun 2, 2008, at 8:41 AM, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], David Pratt writes: Hi. In most cases, I want a request to be passed to a backend where it will be handled by server. If frequency is high, however; I want to add the object to varnish cache and have varnish handle it. I am not worried about a mechanism to keeping track of frequency of requests. Question is what is available to me to add an object/path to the varnish cache if it was originally passed? I wouldn't say that your way of using varnish is backwards relative to the design objectives, but you do come close, since we assumed caching by default, and pass as exception, rather than the other way around. We do this on WordPress.com to avoid filling our caches with infrequently requested data. The way we handle it is when an object reaches a certain req/sec threshold, we send a header from the backend and then have varnish configured to only insert objects into the cache which contain this custom header. Based on phk's reply, I guess we are using varnish in a somewhat backwards manner as well, since we assume pass as the detault, insert as the exception. This used to work in 1.0.3. I have started to look into upgrading to trunk, and it doesn't seem to work so well anymore. It looks like the first time the URL is requested, if it is passed because it hasn't reached that threshold and the header hasn't been set, all subsequent requests are automatically pass ed. These show up as Cache hits for pass in varnishstat. Any way around this? -- Barry Abrahamson | Systems Wrangler | Automattic Blog: http://barry.wordpress.com ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Conditional caching question
In message [EMAIL PROTECTED], Barry Abraham son writes: On Jun 2, 2008, at 8:41 AM, Poul-Henning Kamp wrote: We do this on WordPress.com to avoid filling our caches with infrequently requested data. The way we handle it is when an object reaches a certain req/sec threshold, we send a header from the backend and then have varnish configured to only insert objects into the cache which contain this custom header. Based on phk's reply, I guess we are using varnish in a somewhat backwards manner as well, since we assume pass as the detault, insert as the exception. Not at all, the backwards aspect was if Varnish was supposed to be able to figure out when to start caching an object. Having the backend tell Varnish what to cache and how long is exactly how Varnish was designed to work. This used to work in 1.0.3. I have started to look into upgrading to trunk, and it doesn't seem to work so well anymore. It looks like the first time the URL is requested, if it is passed because it hasn't reached that threshold and the header hasn't been set, all subsequent requests are automatically pass ed. These show up as Cache hits for pass in varnishstat. Any way around this? When you do _not_ detect the magic header, set the TTL lower, that controls how long time the this should be passed cache object lives. If that doesn't work, it's 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. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Conditional caching question
Sorry wanted to clarify that I wanted varnish checked first before going to backend. If object is frequently requested, add to cache. David Pratt wrote: Hi. In most cases, I want a request to be passed to a backend where it will be handled by server. If frequency is high, however; I want to add the object to varnish cache and have varnish handle it. I am not worried about a mechanism to keeping track of frequency of requests. Question is what is available to me to add an object/path to the varnish cache if it was originally passed? Many thanks. Regards, David ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Conditional caching question
Hi. In most cases, I want a request to be passed to a backend where it will be handled by server. If frequency is high, however; I want to add the object to varnish cache and have varnish handle it. I am not worried about a mechanism to keeping track of frequency of requests. Question is what is available to me to add an object/path to the varnish cache if it was originally passed? Many thanks. Regards, David ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about Cache Size
james wrote: Hey everyone, In trying to diagnose why the varnish child dies at seemingly random times, I started varnish with -d -d and waited for a crash. This is what I got in the output: Child said (2, 16094): Assert error in STV_alloc(), stevedore.c line 70: Condition((st) != NULL) not true. errno = 107 (Transport endpoint is not connected) Cache child died pid=16094 status=0x6 Clean child Child cleaned start child pid 18886 Child said (2, 18886): Child starts managed to mmap 565284864 bytes of 565284864 Ready CLI ready This issue is not effecting me anymore after moving to a 64bit system. Alas, I am experiencing another issue using varnish-1.2. After purging from the cache (using url.purge *.css), the child will die and the management process goes to 100% cpu. From running in debug mode: storage_file: filename: /var/cache/varnishd//varnish.BIT37f (unlinked) size 10240 MegaBytes. Using old SHMFILE rolling(1)... rolling(2)... start start child pid 20178 200 0 Child said (2, 20178): Child starts managed to mmap 10737418240 bytes of 10737418240 Ready CLI ready Cache child died pid=20178 status=0xb Clean child Child cleaned start child pid 20199 Child said (2, 20199): Child starts managed to mmap 10737418240 bytes of 10737418240 Ready CLI ready Is there anything else I should to to help track down the issue? Is it advisable to go to 1.1.2? -- james ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Question about Cache Size
Hey everyone, In trying to diagnose why the varnish child dies at seemingly random times, I started varnish with -d -d and waited for a crash. This is what I got in the output: Child said (2, 16094): Assert error in STV_alloc(), stevedore.c line 70: Condition((st) != NULL) not true. errno = 107 (Transport endpoint is not connected) Cache child died pid=16094 status=0x6 Clean child Child cleaned start child pid 18886 Child said (2, 18886): Child starts managed to mmap 565284864 bytes of 565284864 Ready CLI ready Any idea what this might be an indication of? Also, when starting varnish from the command line (and not an init.d script), I noticed this output which I haven't noticed before: [EMAIL PROTECTED] ~]# /usr/local/sbin/varnishd -a ipaddr:8000 -T ipaddr:8080 -s file,/var/cache/varnish/,10G -p group=nobody -p thread_pool_max=1500 -p thread_pools=5 -p listen_depth=512 -p client_http11=on -p backend_http11=on -p default_ttl=36000 -P /var/run/varnishd.pid -f /etc/varnish.conf WARNING: storage file size reduced to 1342177280 due to system limitations WARNING: storage file size reduced to 599837900 (80% of available disk space) file /var/cache/varnish//varnish.z8brik (unlinked) size 599834624 bytes (146444 fs-blocks, 146444 pages) Using old SHMFILE However, 80% of my available disk space is not 599834624 bytes ( 572 Mbytes ). FilesystemSize Used Avail Use% Mounted on /dev/sda3 131G 16G 109G 13% / /dev/sda1 99M 15M 79M 16% /boot tmpfs 1.8G 0 1.8G 0% /dev/shm Any idea if these things are related? Currently running varnishd-1.2 Thanks! -- james ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about Pass
James Quacinella [EMAIL PROTECTED] writes: From the man page: vcl_pass: Called upon entering pass mode. In this mode, the request is passed on to the backend, and the backend's response is passed on to the client, but is not entered into the cache. Subsequent requests submitted over the same client connection are handled normally. So when running varnishstat, what does 'Cache hits for pass' mean? Sicne the above says that pass mode does not enter anything in the cache, but it can still use the cache? It means we found a record in the cache that indicates that a particular object should be handled in pass mode. This can happen if vcl_fetch() ended with pass, e.g. if the backend sent a cookie. DES -- Dag-Erling Smørgrav Senior Software Developer Linpro AS - www.linpro.no ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
