From ajian521 at gmail.com  Mon Mar  2 07:23:29 2009
From: ajian521 at gmail.com (Ajian)
Date: Mon, 2 Mar 2009 15:23:29 +0800
Subject: How to purge the cache by HTTP
Message-ID: <9ab009b80903012323o21850425g18d3206845336a02@mail.gmail.com>

     The problem is about how to purge the cache by the http.
    When my hash is the fellow ,I can solve it

   sub vcl_hash {
   set req.hash += req.url;
   hash;
}

   I have write a php file to purge the cache

  <?php
       function purge($ip, $domain, $url)
       {
       $errstr = '';
       $errno = '';
       $fp = fsockopen ($ip, 80, $errno, $errstr, 2);
       if (!$fp)
       {
       return false;
       }
       else
       {
       $out = "PURGE $url HTTP/1.1\r\n";
       $out .= "Host:$domain\r\n";
       $out .= "Connection: close\r\n\r\n";
       fputs ($fp, $out);
       $out = fgets($fp , 4096);
       echo $out;
       fclose ($fp);
       return true;
       }
       }

       $domain = $_GET['a'];
       $imgurl = $_GET['b'];

       $squid = array(
       '221.238.196.199',
       '221.238.196.200',
       );

       foreach($squid as $ip)
       {
       if(!empty($ip))
       {
       purge($ip, $domain, $imgurl);
       echo "clear is over";
       }
       }

 ?>

But, I change the hash, use the similar way but can't clear it ,output
"HTTP/1.1 404 Not in cache "

sub vcl_hash {
   set req.hash += req.url;
    if (req.http.Accept-Encoding) {
       set req.hash += req.http.Accept-Encoding;
   }
   hash;
}


I have try use

$out = "PURGE $url HTTP/1.1\r\n";
       $out .= "Host:$domain\r\n";
       $out .= "Accept-Encoding:gzip,deflate\r\n";
       $out .= "Connection: close\r\n\r\n";
       fputs ($fp, $out);

and $out .= "Accept-Encoding:gzip\r\n";

$out .= "Accept-Encoding:deflate\r\n";

Without success.

who can tell me how to purge the hash cache ,how to write the php ,I need
through remote empty cache ,thanks.

I hope you can understand what I mean, my English is pool.


Ajian
????????????????????????????????????????????????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090302/f90ef0bd/attachment.html>

From fredrik.nygren at gotamedia.se  Tue Mar  3 20:46:21 2009
From: fredrik.nygren at gotamedia.se (Fredrik Nygren)
Date: Tue, 3 Mar 2009 21:46:21 +0100
Subject: Redirect 503 errors with req.restarts and vcl_error
Message-ID: <F0F3F00D-530A-48FB-B4FC-2523510ECA4D@gotamedia.se>

Hi,
I have a backend server (with Tomcat). It happens that my backend  
server responds with a 503 message when is not available. In these  
cases, I want to redirect my visitors to another backend server that  
has a static HTML error page. But for some reason, my visitors sees  
Varnish default 503 message (Guru Meditation blabla ...) instead  
geting a redirect to the static backend. Advice please?

I use Varnish varnish-2.0.3-1.

Here is my VCL file:

backend barren {
	.host = "10.0.0.1";
	.port = "8090";
}

sub vcl_recv{
	if(req.http.host ~ "varnish\.domain\.se$"){
    		if(req.restarts == 0){
    			set req.http.host = "varnish.domain.se";
    			set req.backend = barren;
    		}else{
    			error 750 "domain.se";	
    		}
	}
}

sub vcl_error{
	if(obj.status == 750){
        	if(obj.response ~ "domain\.se"){
            		set obj.http.Location = "http://www2.domain.se/whooops/index.html 
";
		}
		set obj.status = 302;
        	deliver;
	}
}

sub vcl_fetch {
	if(obj.status != 200){
		restart;
	}
}

Regards
<fredrik />







From ross at trademe.co.nz  Wed Mar  4 05:16:10 2009
From: ross at trademe.co.nz (Ross Brown)
Date: Wed, 4 Mar 2009 18:16:10 +1300
Subject: Varnish hangs / requests time out
Message-ID: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>

Hi all

We are hoping to use Varnish for serving image content on our reasonably busy auction site here in New Zealand, but are having an interesting problem during testing.

We are using latest Varnish (2.0.3) on Ubuntu 8.10 server (64-bit) and have built two servers for testing - both are located in the same datacentre and situated behind an F5 hardware load balancer. We want to keep all images cached in RAM and are using Varnish with jemalloc to achieve this. For the most part, Varnish is working well for us and performance is great.

However, we have seen both our Varnish servers lock up at precisely the same time and stop processing incoming HTTP requests until Varnishd is manually restarted. This has happened twice and seems to occur at random - the last time was after 5 days of uptime and a significant amount of processed traffic (<1TB).

When this problem happens, the backend is still reachable and happily serving images. It is not a particularly busy period for us (600 requests/sec/Varnish server - approx 350Mbps outbound each - we got up to nearly 3 times that level without incident previously) but for some reason unknown to us, the servers just suddenly stop processing requests and worker processes increase dramatically. 

After the lockup happened last time, I tried firing up varnishlog and hitting the server directly - my requests were not showing up at all. The *only* entries in the varnish log were related to worker processes being killed over time - no PINGs, PONGs, load balancer healthchecks or anything related to 'normal' varnish activity. It's as if varnishd has completely locked up, but we can't understand what causes both our varnish servers to exhibit this behaviour at exactly the same time, nor why varnish does not detect it and attempt a restart. After a restart, varnish is fine and behaves itself.

There is nothing to indicate an error with the backend, nor anything in syslog to indicate a Varnish problem. Pointers of any kind would be appreciated :)

Best regards

Ross Brown
Trade Me
www.trademe.co.nz

*** Startup Options (as per hints in wiki for caching millions of objects):
-a 0.0.0.0:80 -f /usr/local/etc/default.net.vcl -T 0.0.0.0:8021 -t 86400 -h classic,1200007 -p thread_pool_max=4000 -p thread_pools=4 -p listen_depth=4096 -p lru_interval=3600 -p obj_workspace=4096 -s malloc,10G

*** Running VCL:
backend default { 
        .host = "10.10.10.10";
        .port = "80";   
} 

sub vcl_recv {
        # Don't cache objects requested with query string in URI.
        # Needed for newsletter headers (openrate) and health checks.
        if (req.url ~ "\?.*") {         
                pass;
        }

        # Force lookup if the request is a no-cache request from the client.
        if (req.http.Cache-Control ~ "no-cache") {
                unset req.http.Cache-Control;
                lookup;
        }

        # By default, Varnish will not serve requests that come with a cookie from its cache.
        unset req.http.cookie;
        unset req.http.authenticate;

        # No action here, continue into default vcl_recv{}
}


***Stats
      458887  Client connections accepted
   170714631  Client requests received
   133012763  Cache hits
        3715  Cache hits for pass
    27646213  Cache misses
    37700868  Backend connections success
           0  Backend connections not attempted
           0  Backend connections too many
          40  Backend connections failures
    37512808  Backend connections reuses
    37514682  Backend connections recycles
           0  Backend connections unused
        1339  N struct srcaddr
          16  N active struct srcaddr
         756  N struct sess_mem
          12  N struct sess
      761152  N struct object
      761243  N struct objecthead
           0  N struct smf
           0  N small free smf
           0  N large free smf
         322  N struct vbe_conn
         345  N struct bereq
          20  N worker threads
        2331  N worker threads created
           0  N worker threads not created
           0  N worker threads limited
           0  N queued work requests
       35249  N overflowed work requests
           0  N dropped work requests
           1  N backends
          44  N expired objects
    26886639  N LRU nuked objects
           0  N LRU saved objects
    15847787  N LRU moved objects
           0  N objects on deathrow
           3  HTTP header overflows
           0  Objects sent with sendfile
   164595318  Objects sent with write
           0  Objects overflowing workspace
      458886  Total Sessions
   170715215  Total Requests
         306  Total pipe
    10054413  Total pass
    37700586  Total fetch
 49458782160  Total header bytes
1151144727614  Total body bytes
       89464  Session Closed
           0  Session Pipeline
           0  Session Read Ahead
           0  Session Linger
   170622902  Session herd
  7875546129  SHM records
   380705819  SHM writes
         138  SHM flushes due to overflow
      763205  SHM MTX contention
        2889  SHM cycles through buffer
           0  allocator requests
           0  outstanding allocations
           0  bytes allocated
           0  bytes free
   101839895  SMA allocator requests
     1519005  SMA outstanding allocations
 10736616112  SMA outstanding bytes
562900737623  SMA bytes allocated
552164121511  SMA bytes free
          56  SMS allocator requests
           0  SMS outstanding allocations
           0  SMS outstanding bytes
       25712  SMS bytes allocated
       25712  SMS bytes freed
    37700490  Backend requests made
           3  N vcl total
           3  N vcl available
           0  N vcl discarded
           1  N total active purges
           1  N new purges added
           0  N old purges deleted
           0  N objects tested
           0  N regexps tested against
           0  N duplicate purges removed
           0  HCB Lookups without lock
           0  HCB Lookups with lock
           0  HCB Inserts
           0  Objects ESI parsed (unlock)
           0  ESI parse errors (unlock)





From plfgoa at gmail.com  Thu Mar  5 10:44:59 2009
From: plfgoa at gmail.com (Paras Fadte)
Date: Thu, 5 Mar 2009 16:14:59 +0530
Subject: Varnish hangs / requests time out
In-Reply-To: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
References: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
Message-ID: <75cf5800903050244w77bd8e16m94da986edf25eec5@mail.gmail.com>

I too have encountered varnish hanging many times .

On Wed, Mar 4, 2009 at 10:46 AM, Ross Brown <ross at trademe.co.nz> wrote:
> Hi all
>
> We are hoping to use Varnish for serving image content on our reasonably busy auction site here in New Zealand, but are having an interesting problem during testing.
>
> We are using latest Varnish (2.0.3) on Ubuntu 8.10 server (64-bit) and have built two servers for testing - both are located in the same datacentre and situated behind an F5 hardware load balancer. We want to keep all images cached in RAM and are using Varnish with jemalloc to achieve this. For the most part, Varnish is working well for us and performance is great.
>
> However, we have seen both our Varnish servers lock up at precisely the same time and stop processing incoming HTTP requests until Varnishd is manually restarted. This has happened twice and seems to occur at random - the last time was after 5 days of uptime and a significant amount of processed traffic (<1TB).
>
> When this problem happens, the backend is still reachable and happily serving images. It is not a particularly busy period for us (600 requests/sec/Varnish server - approx 350Mbps outbound each - we got up to nearly 3 times that level without incident previously) but for some reason unknown to us, the servers just suddenly stop processing requests and worker processes increase dramatically.
>
> After the lockup happened last time, I tried firing up varnishlog and hitting the server directly - my requests were not showing up at all. The *only* entries in the varnish log were related to worker processes being killed over time - no PINGs, PONGs, load balancer healthchecks or anything related to 'normal' varnish activity. It's as if varnishd has completely locked up, but we can't understand what causes both our varnish servers to exhibit this behaviour at exactly the same time, nor why varnish does not detect it and attempt a restart. After a restart, varnish is fine and behaves itself.
>
> There is nothing to indicate an error with the backend, nor anything in syslog to indicate a Varnish problem. Pointers of any kind would be appreciated :)
>
> Best regards
>
> Ross Brown
> Trade Me
> www.trademe.co.nz
>
> *** Startup Options (as per hints in wiki for caching millions of objects):
> -a 0.0.0.0:80 -f /usr/local/etc/default.net.vcl -T 0.0.0.0:8021 -t 86400 -h classic,1200007 -p thread_pool_max=4000 -p thread_pools=4 -p listen_depth=4096 -p lru_interval=3600 -p obj_workspace=4096 -s malloc,10G
>
> *** Running VCL:
> backend default {
> ? ? ? ?.host = "10.10.10.10";
> ? ? ? ?.port = "80";
> }
>
> sub vcl_recv {
> ? ? ? ?# Don't cache objects requested with query string in URI.
> ? ? ? ?# Needed for newsletter headers (openrate) and health checks.
> ? ? ? ?if (req.url ~ "\?.*") {
> ? ? ? ? ? ? ? ?pass;
> ? ? ? ?}
>
> ? ? ? ?# Force lookup if the request is a no-cache request from the client.
> ? ? ? ?if (req.http.Cache-Control ~ "no-cache") {
> ? ? ? ? ? ? ? ?unset req.http.Cache-Control;
> ? ? ? ? ? ? ? ?lookup;
> ? ? ? ?}
>
> ? ? ? ?# By default, Varnish will not serve requests that come with a cookie from its cache.
> ? ? ? ?unset req.http.cookie;
> ? ? ? ?unset req.http.authenticate;
>
> ? ? ? ?# No action here, continue into default vcl_recv{}
> }
>
>
> ***Stats
> ? ? ?458887 ?Client connections accepted
> ? 170714631 ?Client requests received
> ? 133012763 ?Cache hits
> ? ? ? ?3715 ?Cache hits for pass
> ? ?27646213 ?Cache misses
> ? ?37700868 ?Backend connections success
> ? ? ? ? ? 0 ?Backend connections not attempted
> ? ? ? ? ? 0 ?Backend connections too many
> ? ? ? ? ?40 ?Backend connections failures
> ? ?37512808 ?Backend connections reuses
> ? ?37514682 ?Backend connections recycles
> ? ? ? ? ? 0 ?Backend connections unused
> ? ? ? ?1339 ?N struct srcaddr
> ? ? ? ? ?16 ?N active struct srcaddr
> ? ? ? ? 756 ?N struct sess_mem
> ? ? ? ? ?12 ?N struct sess
> ? ? ?761152 ?N struct object
> ? ? ?761243 ?N struct objecthead
> ? ? ? ? ? 0 ?N struct smf
> ? ? ? ? ? 0 ?N small free smf
> ? ? ? ? ? 0 ?N large free smf
> ? ? ? ? 322 ?N struct vbe_conn
> ? ? ? ? 345 ?N struct bereq
> ? ? ? ? ?20 ?N worker threads
> ? ? ? ?2331 ?N worker threads created
> ? ? ? ? ? 0 ?N worker threads not created
> ? ? ? ? ? 0 ?N worker threads limited
> ? ? ? ? ? 0 ?N queued work requests
> ? ? ? 35249 ?N overflowed work requests
> ? ? ? ? ? 0 ?N dropped work requests
> ? ? ? ? ? 1 ?N backends
> ? ? ? ? ?44 ?N expired objects
> ? ?26886639 ?N LRU nuked objects
> ? ? ? ? ? 0 ?N LRU saved objects
> ? ?15847787 ?N LRU moved objects
> ? ? ? ? ? 0 ?N objects on deathrow
> ? ? ? ? ? 3 ?HTTP header overflows
> ? ? ? ? ? 0 ?Objects sent with sendfile
> ? 164595318 ?Objects sent with write
> ? ? ? ? ? 0 ?Objects overflowing workspace
> ? ? ?458886 ?Total Sessions
> ? 170715215 ?Total Requests
> ? ? ? ? 306 ?Total pipe
> ? ?10054413 ?Total pass
> ? ?37700586 ?Total fetch
> ?49458782160 ?Total header bytes
> 1151144727614 ?Total body bytes
> ? ? ? 89464 ?Session Closed
> ? ? ? ? ? 0 ?Session Pipeline
> ? ? ? ? ? 0 ?Session Read Ahead
> ? ? ? ? ? 0 ?Session Linger
> ? 170622902 ?Session herd
> ?7875546129 ?SHM records
> ? 380705819 ?SHM writes
> ? ? ? ? 138 ?SHM flushes due to overflow
> ? ? ?763205 ?SHM MTX contention
> ? ? ? ?2889 ?SHM cycles through buffer
> ? ? ? ? ? 0 ?allocator requests
> ? ? ? ? ? 0 ?outstanding allocations
> ? ? ? ? ? 0 ?bytes allocated
> ? ? ? ? ? 0 ?bytes free
> ? 101839895 ?SMA allocator requests
> ? ? 1519005 ?SMA outstanding allocations
> ?10736616112 ?SMA outstanding bytes
> 562900737623 ?SMA bytes allocated
> 552164121511 ?SMA bytes free
> ? ? ? ? ?56 ?SMS allocator requests
> ? ? ? ? ? 0 ?SMS outstanding allocations
> ? ? ? ? ? 0 ?SMS outstanding bytes
> ? ? ? 25712 ?SMS bytes allocated
> ? ? ? 25712 ?SMS bytes freed
> ? ?37700490 ?Backend requests made
> ? ? ? ? ? 3 ?N vcl total
> ? ? ? ? ? 3 ?N vcl available
> ? ? ? ? ? 0 ?N vcl discarded
> ? ? ? ? ? 1 ?N total active purges
> ? ? ? ? ? 1 ?N new purges added
> ? ? ? ? ? 0 ?N old purges deleted
> ? ? ? ? ? 0 ?N objects tested
> ? ? ? ? ? 0 ?N regexps tested against
> ? ? ? ? ? 0 ?N duplicate purges removed
> ? ? ? ? ? 0 ?HCB Lookups without lock
> ? ? ? ? ? 0 ?HCB Lookups with lock
> ? ? ? ? ? 0 ?HCB Inserts
> ? ? ? ? ? 0 ?Objects ESI parsed (unlock)
> ? ? ? ? ? 0 ?ESI parse errors (unlock)
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From b.perwenis at gmail.com  Thu Mar  5 11:40:51 2009
From: b.perwenis at gmail.com (Bartek Perwenis)
Date: Thu, 5 Mar 2009 12:40:51 +0100
Subject: Varnish hangs / requests time out
In-Reply-To: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
References: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
Message-ID: <7f97c4a0903050340q681a0d3bv54e89b834722d77b@mail.gmail.com>

Same here. I have encounter this problem after migrating from linux+2.0.1 to
solaris+2.0.2.

With 2.0.2 it happens randomly. Sometimes varnish runs flawlessly for days,
and sometimes locks up couple of times in a short period of time.

Maybe you should try 2.0.1 on one of your test servers and compare how they
behave?

Best regards,
Bartek

2009/3/4 Ross Brown <ross at trademe.co.nz>

> Hi all
>
> We are hoping to use Varnish for serving image content on our reasonably
> busy auction site here in New Zealand, but are having an interesting problem
> during testing.
>
> We are using latest Varnish (2.0.3) on Ubuntu 8.10 server (64-bit) and have
> built two servers for testing - both are located in the same datacentre and
> situated behind an F5 hardware load balancer. We want to keep all images
> cached in RAM and are using Varnish with jemalloc to achieve this. For the
> most part, Varnish is working well for us and performance is great.
>
> However, we have seen both our Varnish servers lock up at precisely the
> same time and stop processing incoming HTTP requests until Varnishd is
> manually restarted. This has happened twice and seems to occur at random -
> the last time was after 5 days of uptime and a significant amount of
> processed traffic (<1TB).
>
> When this problem happens, the backend is still reachable and happily
> serving images. It is not a particularly busy period for us (600
> requests/sec/Varnish server - approx 350Mbps outbound each - we got up to
> nearly 3 times that level without incident previously) but for some reason
> unknown to us, the servers just suddenly stop processing requests and worker
> processes increase dramatically.
>
> After the lockup happened last time, I tried firing up varnishlog and
> hitting the server directly - my requests were not showing up at all. The
> *only* entries in the varnish log were related to worker processes being
> killed over time - no PINGs, PONGs, load balancer healthchecks or anything
> related to 'normal' varnish activity. It's as if varnishd has completely
> locked up, but we can't understand what causes both our varnish servers to
> exhibit this behaviour at exactly the same time, nor why varnish does not
> detect it and attempt a restart. After a restart, varnish is fine and
> behaves itself.
>
> There is nothing to indicate an error with the backend, nor anything in
> syslog to indicate a Varnish problem. Pointers of any kind would be
> appreciated :)
>
> Best regards
>
> Ross Brown
> Trade Me
> www.trademe.co.nz
>
> *** Startup Options (as per hints in wiki for caching millions of objects):
> -a 0.0.0.0:80 -f /usr/local/etc/default.net.vcl -T 0.0.0.0:8021 -t 86400
> -h classic,1200007 -p thread_pool_max=4000 -p thread_pools=4 -p
> listen_depth=4096 -p lru_interval=3600 -p obj_workspace=4096 -s malloc,10G
>
> *** Running VCL:
> backend default {
>        .host = "10.10.10.10";
>        .port = "80";
> }
>
> sub vcl_recv {
>        # Don't cache objects requested with query string in URI.
>        # Needed for newsletter headers (openrate) and health checks.
>        if (req.url ~ "\?.*") {
>                pass;
>        }
>
>        # Force lookup if the request is a no-cache request from the client.
>        if (req.http.Cache-Control ~ "no-cache") {
>                unset req.http.Cache-Control;
>                lookup;
>        }
>
>        # By default, Varnish will not serve requests that come with a
> cookie from its cache.
>        unset req.http.cookie;
>        unset req.http.authenticate;
>
>        # No action here, continue into default vcl_recv{}
> }
>
>
> ***Stats
>      458887  Client connections accepted
>   170714631  Client requests received
>   133012763  Cache hits
>        3715  Cache hits for pass
>    27646213  Cache misses
>    37700868  Backend connections success
>           0  Backend connections not attempted
>           0  Backend connections too many
>          40  Backend connections failures
>    37512808  Backend connections reuses
>    37514682  Backend connections recycles
>           0  Backend connections unused
>        1339  N struct srcaddr
>          16  N active struct srcaddr
>         756  N struct sess_mem
>          12  N struct sess
>      761152  N struct object
>      761243  N struct objecthead
>           0  N struct smf
>           0  N small free smf
>           0  N large free smf
>         322  N struct vbe_conn
>         345  N struct bereq
>          20  N worker threads
>        2331  N worker threads created
>           0  N worker threads not created
>           0  N worker threads limited
>           0  N queued work requests
>       35249  N overflowed work requests
>           0  N dropped work requests
>           1  N backends
>          44  N expired objects
>    26886639  N LRU nuked objects
>           0  N LRU saved objects
>    15847787  N LRU moved objects
>           0  N objects on deathrow
>           3  HTTP header overflows
>           0  Objects sent with sendfile
>   164595318  Objects sent with write
>           0  Objects overflowing workspace
>      458886  Total Sessions
>   170715215  Total Requests
>         306  Total pipe
>    10054413  Total pass
>    37700586  Total fetch
>  49458782160  Total header bytes
> 1151144727614  Total body bytes
>       89464  Session Closed
>           0  Session Pipeline
>           0  Session Read Ahead
>           0  Session Linger
>   170622902  Session herd
>  7875546129  SHM records
>   380705819  SHM writes
>         138  SHM flushes due to overflow
>      763205  SHM MTX contention
>        2889  SHM cycles through buffer
>           0  allocator requests
>           0  outstanding allocations
>           0  bytes allocated
>           0  bytes free
>   101839895  SMA allocator requests
>     1519005  SMA outstanding allocations
>  10736616112  SMA outstanding bytes
> 562900737623  SMA bytes allocated
> 552164121511  SMA bytes free
>          56  SMS allocator requests
>           0  SMS outstanding allocations
>           0  SMS outstanding bytes
>       25712  SMS bytes allocated
>       25712  SMS bytes freed
>    37700490  Backend requests made
>           3  N vcl total
>           3  N vcl available
>           0  N vcl discarded
>           1  N total active purges
>           1  N new purges added
>           0  N old purges deleted
>           0  N objects tested
>           0  N regexps tested against
>           0  N duplicate purges removed
>           0  HCB Lookups without lock
>           0  HCB Lookups with lock
>           0  HCB Inserts
>           0  Objects ESI parsed (unlock)
>           0  ESI parse errors (unlock)
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090305/b82809ed/attachment.html>

From kristian at redpill-linpro.com  Thu Mar  5 12:30:23 2009
From: kristian at redpill-linpro.com (Kristian Lyngstol)
Date: Thu, 5 Mar 2009 13:30:23 +0100
Subject: Varnish hangs / requests time out
In-Reply-To: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
References: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
Message-ID: <20090305123023.GE11634@kjeks.linpro.no>

On Wed, Mar 04, 2009 at 06:16:10PM +1300, Ross Brown wrote:
> When this problem happens, the backend is still reachable and happily
> serving images. It is not a particularly busy period for us (600
> requests/sec/Varnish server - approx 350Mbps outbound each - we got up to
> nearly 3 times that level without incident previously) but for some
> reason unknown to us, the servers just suddenly stop processing requests
> and worker processes increase dramatically. 
> 
> After the lockup happened last time, I tried firing up varnishlog and
> hitting the server directly - my requests were not showing up at all. The
> *only* entries in the varnish log were related to worker processes being
> killed over time - no PINGs, PONGs, load balancer healthchecks or
> anything related to 'normal' varnish activity. It's as if varnishd has
> completely locked up, but we can't understand what causes both our
> varnish servers to exhibit this behaviour at exactly the same time, nor
> why varnish does not detect it and attempt a restart. After a restart,
> varnish is fine and behaves itself.
> 
> There is nothing to indicate an error with the backend, nor anything in
> syslog to indicate a Varnish problem. Pointers of any kind would be
> appreciated :)

Have you checked dmesg? Do you have any estimate of how simultaneous these
freezes are? (seconds, minutes or tens of minutes apart for instance?).

Your hit rate is quite low (78%ish) and it doesn't seem like you have grace
enabled, which I strongly recommend. If dmesg doesn't reveal any troubles,
I'd start by setting up grace (req.grace = 30s; and obj.grace = 30s; will get
you far) and focusing on getting that hit rate up. If all you're serving is
images, chances are that you should be able to top 99% which would make
Varnish considerably more resilient to hiccoughs from backends.

You also have a few backend failures which could easily trigger Bad Things
with no grace and a low hit rate.

You should also consider starting with -p cli_timeout=20 or similar, as the
default can be far too aggressive on a busy site. Any entries in the syslog
or varnishlog entries related to this would be  helpful for further
debugging.

-- 
Kristian Lyngst?l
Redpill Linpro AS
Tlf: +47 21544179
Mob: +47 99014497
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090305/97d64226/attachment.bin>

From ross at trademe.co.nz  Fri Mar  6 02:17:34 2009
From: ross at trademe.co.nz (Ross Brown)
Date: Fri, 6 Mar 2009 15:17:34 +1300
Subject: Varnish hangs / requests time out
In-Reply-To: <20090305123023.GE11634@kjeks.linpro.no>
References: <1FF67D7369ED1A45832180C7C1109BCA0D355B2922@tmmail0.trademe.local>
	<20090305123023.GE11634@kjeks.linpro.no>
Message-ID: <1FF67D7369ED1A45832180C7C1109BCA0D355B29D1@tmmail0.trademe.local>


> Have you checked dmesg? Do you have any estimate of how simultaneous these freezes are? (seconds, minutes or tens of minutes apart for instance?).

There was nothing in dmesg to indicate any sort of problem at the time of the incident. We weren't actively watching over them when the failures happened - but the Syslog messages from the load balancer say both failures occurred less than one second apart.

> Your hit rate is quite low (78%ish) and it doesn't seem like you have grace enabled, which I strongly recommend. 
> If dmesg doesn't reveal any troubles, I'd start by setting up grace (req.grace = 30s; and obj.grace = 30s; will 
> get you far) and focusing on getting that hit rate up. If all you're serving is images, chances are that you should 
> be able to top 99% which would make Varnish considerably more resilient to hiccoughs from backends.

OK I have added those grace settings. I'd be surprised if we ever get near 99% though, since images are being added to the backend all the time and the set of live images changes over time as auctions expire.

> You should also consider starting with -p cli_timeout=20 or similar, as the default can be far too aggressive on a busy site. 

Since making the changes above, we have noticed that the number of worker threads has already peaked at 264 and been quite choppy (when viewing the data in Cacti) - previously the peak was 133 and a lot smoother. I'd have imagined the cli_timeout change would have made things smoother?

We're also running one of the servers in debug mode to catch any error messages. Will report back what we get if we see the freeze again.

Thanks for the suggestions.

Ross


From ottolski at web.de  Sat Mar  7 17:52:04 2009
From: ottolski at web.de (Sascha Ottolski)
Date: Sat, 7 Mar 2009 18:52:04 +0100
Subject: strange restart, taking 15 minutes
Message-ID: <200903071852.04548.ottolski@web.de>

Hi,

I've just seen a strange restart that heppened this morning, after only 
about 25 h runtime; apparantly, there was a problem, but the parent 
process needed serveral kill attempts and more than 15 minutes to 
finally restart it's child:

# grep varnish /var/log/syslog
Mar  7 08:52:42 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:52:48 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:52:53 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:52:58 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:03 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:08 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:13 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:18 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:23 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:28 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:34 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:38 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:43 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:48 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:53 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:53:58 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:03 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:08 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:13 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:18 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:23 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:28 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:37 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:38 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:43 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:48 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:53 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:54:58 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:56:18 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:00 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:06 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:11 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:16 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:21 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:26 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:31 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:36 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:41 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:46 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:54 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:58:56 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:01 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:06 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:11 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:16 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:21 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:26 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:31 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:36 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:41 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:47 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:51 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 08:59:56 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:01 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:06 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:17 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:17 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:22 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:27 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:00:32 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:03:26 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:06:16 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:06:19 localhost varnishd[652]: Child (653) not responding to 
ping, killing it.
Mar  7 09:06:19 localhost varnishd[652]: Child (653) died signal=3
Mar  7 09:06:19 localhost varnishd[652]: Child cleanup complete
Mar  7 09:06:20 localhost varnishd[652]: child (13213) Started
Mar  7 09:06:20 localhost varnishd[652]: Child (13213) said Closed fds: 
4 5 6 7 11 12 14 15
Mar  7 09:06:20 localhost varnishd[652]: Child (13213) said Child starts
Mar  7 09:06:20 localhost varnishd[652]: Child (13213) said managed to 
mmap 483183820800 bytes of 483183820800
Mar  7 09:06:20 localhost varnishd[652]: Child (13213) said Ready


never seen something like this before. and also strange, I restarted 4 
identically configured and loadbalanced varnishes at the same time, but 
only this one performed the shown restart a day later; the others are 
still running without issues.

this happened with trunk, r3576.


Cheers, Sascha


From ottolski at web.de  Mon Mar  9 09:18:01 2009
From: ottolski at web.de (Sascha Ottolski)
Date: Mon, 9 Mar 2009 10:18:01 +0100
Subject: strange restart, taking 15 minutes
In-Reply-To: <200903071852.04548.ottolski@web.de>
References: <200903071852.04548.ottolski@web.de>
Message-ID: <200903091018.02194.ottolski@web.de>

Am Samstag 07 M?rz 2009 18:52:04 schrieb Sascha Ottolski:
> I've just seen a strange restart that heppened this morning, after
> only about 25 h runtime;


please ignore the posting, it just came out that the server has a broken 
hdd.


Thanks for listening anyway,

Sascha


From rafael.umann at terra.com.br  Mon Mar  9 17:17:01 2009
From: rafael.umann at terra.com.br (Rafael Umann)
Date: Mon, 09 Mar 2009 14:17:01 -0300
Subject: Threads in use
Message-ID: <49B54F0D.1030806@terra.com.br>

Hi,

Today we have a lot of useful informations on varnishstat, but there is 
nothing showing how many threads of those created are really doing 
something. The problem is how to know when to increase the number of 
threads, or how to notice that the number of threads in use are almost 100%.

So, is there a way to see how many threads are working, or is it 
possible to implement on varnishstat?

BR,

[]s,
Rafael


From pablo at sbnation.com  Tue Mar 10 00:20:31 2009
From: pablo at sbnation.com (Pablo Mercado)
Date: Mon, 9 Mar 2009 20:20:31 -0400
Subject: Varnish hangs / requests time out
Message-ID: <D45809E6-B33F-4081-A34F-6C2C40793D2D@sbnation.com>

Hello,

Would you be able to elaborate on the following?

"You also have a few backend failures which could easily trigger Bad  
Things
with no grace and a low hit rate."

Thanks!

Pablo Mercado


From list at zaide.org  Tue Mar 10 08:56:15 2009
From: list at zaide.org (Damien Desmarets)
Date: Tue, 10 Mar 2009 09:56:15 +0100
Subject: Threads in use
In-Reply-To: <49B54F0D.1030806@terra.com.br>
References: <49B54F0D.1030806@terra.com.br>
Message-ID: <49B62B2F.6050100@zaide.org>

Hello,
For me this is already implemented in varnishstat.

# varnishstat -1 |grep thr
n_wrk                      45          .   N worker threads

No? For me it's 45 working threads.

Regards,
Damien Desmarets

Rafael Umann a ?crit :
> Hi,
>
> Today we have a lot of useful informations on varnishstat, but there is 
> nothing showing how many threads of those created are really doing 
> something. The problem is how to know when to increase the number of 
> threads, or how to notice that the number of threads in use are almost 100%.
>
> So, is there a way to see how many threads are working, or is it 
> possible to implement on varnishstat?
>
> BR,
>
> []s,
> Rafael
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>   



From rafael.umann at terra.com.br  Tue Mar 10 11:54:27 2009
From: rafael.umann at terra.com.br (Rafael Umann)
Date: Tue, 10 Mar 2009 08:54:27 -0300
Subject: Threads in use
In-Reply-To: <49B62B2F.6050100@zaide.org>
References: <49B54F0D.1030806@terra.com.br> <49B62B2F.6050100@zaide.org>
Message-ID: <49B654F3.2030401@terra.com.br>


This number shows how many threads are created, but not how many of them 
are actually busy.

This number might work for who open new threads on demand, but i'm 
opening all during startup.

[]s,

Damien Desmarets wrote:
> Hello,
> For me this is already implemented in varnishstat.
> 
> # varnishstat -1 |grep thr
> n_wrk                      45          .   N worker threads
> 
> No? For me it's 45 working threads.
> 
> Regards,
> Damien Desmarets
> 
> Rafael Umann a ?crit :
>> Hi,
>>
>> Today we have a lot of useful informations on varnishstat, but there is 
>> nothing showing how many threads of those created are really doing 
>> something. The problem is how to know when to increase the number of 
>> threads, or how to notice that the number of threads in use are almost 100%.
>>
>> So, is there a way to see how many threads are working, or is it 
>> possible to implement on varnishstat?
>>
>> BR,
>>
>> []s,
>> Rafael
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>   
> 
> 
> E-mail verificado pelo Terra Anti-Spam.
> Para classificar esta mensagem como spam ou n??o spam, visite
> http://mail.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCY1ODAyNDQ3I3Blcm0hdGVycmEmMSwxMjM2Njc1Mzg4LjIzODg2NC4zMjcxMC5iZXR1bmUudGVycmEuY29tLDIzMjc=
> 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 10/03/2009


From alex at path101.com  Wed Mar 11 07:28:24 2009
From: alex at path101.com (Alex Lines)
Date: Wed, 11 Mar 2009 03:28:24 -0400
Subject: is 2.0.2 not as efficient as 1.1.2 was?
In-Reply-To: <4D484E2D-0553-43D8-84D3-1020E0784E7D@automattic.com>
References: <64131.1233773623@critter.freebsd.dk>
	<4D484E2D-0553-43D8-84D3-1020E0784E7D@automattic.com>
Message-ID: <c24c4c9e0903110028l5f8b35b1ncf594a66c64ea179@mail.gmail.com>

Barry, Demitrious - did you ever find a solution here?

On Tue, Feb 10, 2009 at 1:22 PM, Barry Abrahamson <barry at automattic.com> wrote:
>
> On Feb 4, 2009, at 1:53 PM, Poul-Henning Kamp wrote:
>
>> In message <37EADDE4-A23A-4204-B04A-46D47D348D7A at automattic.com>,
>> Barry Abraham
>> son writes:
>>
>>>> This week we upgraded to 2.0.2 and are using varnish's back end &
>>>> director configuration for the same work. ?What we are seeing is
>>>> that
>>>> 2.0.2 holds about 60% of the objects in the same amount of cache
>>>> space
>>>> as 1.1.2 did (we tried tcmalloc, jemalloc, and mmap.)
>>
>> Your description does not make it obvious to me what is causing this
>> but one candidate could be the stored hash-string, in particular if
>> your URLS are long.
>>
>> The new purge code (likely included in 2.0.3, but already available
>> in -trunk) dispenses with the need to store the hash-string so theory
>> could be tested.
>
> Upgraded to trunk, didn't help.
>
> --
> Barry Abrahamson | Systems Wrangler | Automattic
> Blog: http://barry.wordpress.com
>
>
>
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>


From barry at automattic.com  Fri Mar 13 05:42:52 2009
From: barry at automattic.com (Barry Abrahamson)
Date: Fri, 13 Mar 2009 00:42:52 -0500
Subject: is 2.0.2 not as efficient as 1.1.2 was?
In-Reply-To: <c24c4c9e0903110028l5f8b35b1ncf594a66c64ea179@mail.gmail.com>
References: <64131.1233773623@critter.freebsd.dk>
	<4D484E2D-0553-43D8-84D3-1020E0784E7D@automattic.com>
	<c24c4c9e0903110028l5f8b35b1ncf594a66c64ea179@mail.gmail.com>
Message-ID: <55AAA3CB-577F-4802-BFC3-837B04FE63E9@automattic.com>


On Mar 11, 2009, at 2:28 AM, Alex Lines wrote:

> Barry, Demitrious - did you ever find a solution here?

Nope.  For now, we are just using more hardware to hide the problem :(

--
Barry Abrahamson | Systems Wrangler | Automattic
Blog: http://barry.wordpress.com





From lapo at lapo.it  Fri Mar 13 10:15:50 2009
From: lapo at lapo.it (Lapo Luchini)
Date: Fri, 13 Mar 2009 11:15:50 +0100
Subject: purge_hash and regular expressions
Message-ID: <gpdbov$a5n$1@ger.gmane.org>

Hi there.
I think purge_hash is quite nice, but to be easier to use from VCL code
it would be nice to have a function to "regexp-ize" a constant string,
as I feel a bit conscious about matching too much or too little in using
a normal string as a regular expression, e.g.

'/index.html' also matches '/indexhhtml' (ok, this is just paranoia)
'/index.html?id=1' DOES NOT match itself.

This seems an heavy limit on VCL-driver usage of purge_hash? but maybe
there's a workaround available already that I didn't notice?

be good,

-- 
Lapo Luchini - http://lapo.it/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 896 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090313/de63a132/attachment.bin>

From phk at phk.freebsd.dk  Fri Mar 13 10:17:55 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 13 Mar 2009 10:17:55 +0000
Subject: purge_hash and regular expressions 
In-Reply-To: Your message of "Fri, 13 Mar 2009 11:15:50 +0100."
	<gpdbov$a5n$1@ger.gmane.org> 
Message-ID: <23726.1236939475@critter.freebsd.dk>

In message <gpdbov$a5n$1 at ger.gmane.org>, Lapo Luchini writes:

>Hi there.
>I think purge_hash is quite nice, but to be easier to use from VCL code
>it would be nice to have a function to "regexp-ize" a constant string,

In the new purge stuff, you can use comparisons in addition to regexp
matching:

	purge  req.url == "index.html" && req.http.host ~ "foo.com"

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From roy at karlsbakk.net  Fri Mar 13 10:19:49 2009
From: roy at karlsbakk.net (Roy Sigurd Karlsbakk)
Date: Fri, 13 Mar 2009 11:19:49 +0100
Subject: purge_hash and regular expressions
In-Reply-To: <gpdbov$a5n$1@ger.gmane.org>
References: <gpdbov$a5n$1@ger.gmane.org>
Message-ID: <DEB3DB17-8E1B-4058-BA82-D8B660D1758C@karlsbakk.net>

On 13. mars. 2009, at 11.15, Lapo Luchini wrote:

> '/index.html' also matches '/indexhhtml' (ok, this is just paranoia)
> '/index.html?id=1' DOES NOT match itself.


Try '/index\.html\?id=1'. '?' means 'zero or one of preceeding  
character', so '/index.html?id=1' will match '/index.htmid=1' and '/ 
index.htmlid=1'.

roy
--
Roy Sigurd Karlsbakk
(+47) 98013356
roy at 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.



From patrik at gmail.com  Fri Mar 13 14:36:03 2009
From: patrik at gmail.com (patrik)
Date: Fri, 13 Mar 2009 15:36:03 +0100
Subject: Panic message: Assert error in http_StatusMessage()
Message-ID: <6776ce420903130736p7bc15f68y31d7ed4ccc493138@mail.gmail.com>

Hi,

After upgrading from varnish-1.1.2-6 to varnish-2.0.3-1.el5 (rpms on
RHEL 5.1) we see child processes dying every few seconds, with "Panic
message: Assert error in http_StatusMessage()". See examples below.
Most requests are correctly served to the client but maybe one in
twenty results in a panic.

Are we right in assuming that "status >= 100 && status <= 999) not
true" means that the the backend (Jetty through Pound) returns
something unexpected?

Also, probably not related, but a bit strange - for some reason the
varnish entries in the messages log are all one hour off.

Mar 12 11:31:22 lens varnishd[6440]: Child (6441) said managed to mmap
1073741824 bytes of 1073741824
Mar 12 11:31:22 lens varnishd[6440]: Child (6441) said Ready
Mar 12 12:31:34 lens pound: (b78c8b90) error final flush to 127.0.0.1:
Connection reset by peer
Mar 12 12:31:34 lens pound: (b7f21b90) error copy response body:
Connection reset by peer
Mar 12 11:31:35 lens varnishd[6440]: Child (6441) died signal=6
Mar 12 11:31:35 lens varnishd[6440]: Child (6441) Panic message:
Assert error in http_StatusMessage(), cache_http.c line 111:
Condition(status >= 100 && status <= 999) not true.  thread =
(cache-worker)sp = 0x4d9c4004 {   fd = 259, id = 259, xid = 54781249,
 client = 66.249.72.76:52354,   step = STP_FETCH,   handling = fetch,
 err_code = 200, err_reason = (null),   ws = 0x4d9c404c {      id =
"sess",     {s,f,r,e} = {0x4d9c4534,,+384,(nil),+16384},   },
worker = 0x64bf90c4 {     },     vcl = {       srcname = {
"input",         "Default",       },     },   obj = 0x9045b000 {
refcnt = 1, xid = 54781249,     ws = 0x9045b018 {        id = "obj",
    {s,f,r,e} = {0x9045b1ec,,0x9045b1ec,(nil),+7700},     },     http
= {       ws = 0x9045b018 {          id = "obj",         {s,f,r,e} =
{0x9045b1ec,,0x9045b1ec,(nil),+7700},       },     },     len = 0,
store = {     },   }, },
Mar 12 12:31:35 lens pound: (b78c8b90) error copy response body:
Connection reset by peer
Mar 12 11:31:35 lens varnishd[6440]: child (6614) Started
Mar 12 11:31:35 lens varnishd[6440]: Child (6614) said Closed fds: 4 5
6 10 11 13 14
Mar 12 11:31:35 lens varnishd[6440]: Child (6614) said Child starts
Mar 12 11:31:35 lens varnishd[6440]: Child (6614) said managed to mmap
1073741824 bytes of 1073741824
Mar 12 11:31:35 lens varnishd[6440]: Child (6614) said Ready
Mar 12 11:31:43 lens varnishd[6440]: Child (6614) died signal=6
Mar 12 11:31:43 lens varnishd[6440]: Child (6614) Panic message:
Assert error in http_StatusMessage(), cache_http.c line 111:
Condition(status >= 100 && status <= 999) not true.  thread =
(cache-worker)sp = 0x68274004 {   fd = 240, id = 240, xid =
1612998532,   client = 87.9.113.139:1951,   step = STP_FETCH,
handling = pass,   err_code = 200, err_reason = (null),   ws =
0x6827404c {      id = "sess",     {s,f,r,e} =
{0x68274534,,+958,(nil),+16384},   },     worker = 0x6a7ff0c4 {     },
    vcl = {       srcname = {         "input",         "Default",
 },     },   obj = 0x904ad000 {     refcnt = 1, xid = 1612998532,
ws = 0x904ad018 {        id = "obj",       {s,f,r,e} =
{0x904ad1ec,,0x904ad1ec,(nil),+7700},     },     http = {       ws =
0x904ad018 {          id = "obj",         {s,f,r,e} =
{0x904ad1ec,,0x904ad1ec,(nil),+7700},       },     },     len = 0,
store = {     },   }, },
Mar 12 12:31:43 lens pound: (b76c0b90) error final flush to 127.0.0.1:
Connection reset by peer
Mar 12 11:31:43 lens varnishd[6440]: child (6705) Started
Mar 12 11:31:43 lens varnishd[6440]: Child (6705) said Closed fds: 4 5
6 10 11 13 14
Mar 12 11:31:43 lens varnishd[6440]: Child (6705) said Child starts
Mar 12 11:31:43 lens varnishd[6440]: Child (6705) said managed to mmap
1073741824 bytes of 1073741824
Mar 12 11:31:43 lens varnishd[6440]: Child (6705) said Ready
Mar 12 11:31:45 lens varnishd[6440]: Child (6705) died signal=6
Mar 12 11:31:45 lens varnishd[6440]: Child (6705) Panic message:
Assert error in http_StatusMessage(), cache_http.c line 111:
Condition(status >= 100 && status <= 999) not true.  thread =
(cache-worker)sp = 0x6eb6c004 {   fd = 28, id = 28, xid = 1111961222,
 client = 220.101.18.164:3006,   step = STP_FETCH,   handling = fetch,
  err_code = 200, err_reason = (null),   ws = 0x6eb6c04c {      id =
"sess",     {s,f,r,e} = {0x6eb6c534,,+844,(nil),+16384},   },
worker = 0x692ff0c4 {     },     vcl = {       srcname = {
"input",         "Default",       },     },   obj = 0x901de000 {
refcnt = 1, xid = 1111961222,     ws = 0x901de018 {        id = "obj",
      {s,f,r,e} = {0x901de1ec,,0x901de1ec,(nil),+7700},     },
http = {       ws = 0x901de018 {          id = "obj",
{s,f,r,e} = {0x901de1ec,,0x901de1ec,(nil),+7700},       },     },
len = 0,     store = {     },   }, },
Mar 12 11:31:45 lens varnishd[6440]: child (6733) Started
Mar 12 12:31:45 lens pound: (b722eb90) error final flush to 127.0.0.1:
Connection reset by peer
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) said Closed fds: 4 5
6 10 11 13 14
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) said Child starts
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) said managed to mmap
1073741824 bytes of 1073741824
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) said Ready
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) died signal=6
Mar 12 11:31:45 lens varnishd[6440]: Child (6733) Panic message:
Assert error in http_StatusMessage(), cache_http.c line 111:
Condition(status >= 100 && status <= 999) not true.  thread =
(cache-worker)sp = 0x6eb25004 {   fd = 20, id = 20, xid = 324143333,
client = 87.9.113.139:1980,   step = STP_FETCH,   handling = pass,
ws = 0x6eb2504c {      id = "sess",     {s,f,r,e} =
{0x6eb25534,,+882,(nil),+16384},   },     worker = 0x6ccfc0c4 {     },
    vcl = {       srcname = {         "input",         "Default",
 },     },   obj = 0x90103000 {     refcnt = 1, xid = 324143333,
ws = 0x90103018 {        id = "obj",       {s,f,r,e} =
{0x901031ec,,0x901031ec,(nil),+7700},     },     http = {       ws =
0x90103018 {          id = "obj",         {s,f,r,e} =
{0x901031ec,,0x901031ec,(nil),+7700},       },     },     len = 0,
store = {     },   }, },
Mar 12 11:31:45 lens varnishd[6440]: child (6749) Started
Mar 12 12:31:45 lens pound: (b722eb90) error final flush to 127.0.0.1:
Connection reset by peer
Mar 12 11:31:45 lens varnishd[6440]: Child (6749) said Closed fds: 4 5
6 10 11 13 14
Mar 12 11:31:45 lens varnishd[6440]: Child (6749) said Child starts
Mar 12 11:31:45 lens varnishd[6440]: Child (6749) said managed to mmap
1073741824 bytes of 1073741824
Mar 12 11:31:45 lens varnishd[6440]: Child (6749) said Ready

Any help would be greatly appreciated.

Thanks,

Patrik


From iiminar at gmail.com  Sat Mar 14 08:10:52 2009
From: iiminar at gmail.com (Igor Minar)
Date: Sat, 14 Mar 2009 01:10:52 -0700
Subject: Intermittent latency issues on Solaris 10
Message-ID: <9984206E-C7FA-4FB7-8910-16503CB06D9E@gmail.com>

Hi Folks!

I'm trying set up a Varnish instance on Solaris 10 and I'm facing some  
weird issue there. I was wondering if anyone could give me some  
insight into what's going on.

After applying a few patches (I submited all of them to Trac), I was  
able compile Varnish 2.0.2 and 2.0.3 with Sun Studio compiler. Varnish  
starts and is able to handle requests, but from time to time, I see  
multi-second latency when executing requests. As if varnish "hung" for  
a few seconds. This latency occurs for cache hits and is not caused by  
the backed app.

Interesting thing is that I don't see this issue on OpenSolaris 2008.11.

Here is to visualize what I see:
correct behavior on opensolaris: http://skitch.com/me3x/bf7j2/varnish-on-opensolaris
incorrect behavior on solaris10: http://skitch.com/me3x/bf7kr/varnish-on-solaris10

As you can see, on Solaris 10 there are at 3 requests that took more  
than 4 seconds to execute. I checked varnish logs and all of them were  
cache hits.

In the screenshots above, there was no other traffic hitting the  
server except for my single browser.

The problem is quite easily reproducible.

thanks,
Igor


From plfgoa at gmail.com  Mon Mar 16 04:10:05 2009
From: plfgoa at gmail.com (Paras Fadte)
Date: Mon, 16 Mar 2009 09:40:05 +0530
Subject: Child (6871) Panic message: Assert error
Message-ID: <75cf5800903152110r3d2a6e2dt8cd1262eb5831a08@mail.gmail.com>

Hi ,

Got the following error in /var/log/messages regarding varnish . Has
this been rectified ?

Child (6871) died signal=6
varnishd[6870]: Child (6871) Panic message: Assert error in vsl_hdr(),
shmlog.c line 85:   Condition(id < 0x10000) not true.  thread
= (cache-worker)sp = 0x2aababf8c008 {   fd = 26689, id = 26689, xid =
742938330,   client = 81.52.249.100:25132,   step = STP_FETCH,
handling = fetch,   ws
 = 0x2aababf8c078 {      id = "sess",     {s,f,r,e} =
{0x2aababf8c808,,+1354,(nil),+16384},   },     worker = 0x2aac84f19c60
{     },     vcl = {       srcna
me = {         "input",         "Default",       },     },   obj =
0x2aaab6398000 {     refcnt = 1, xid = 742938330,     ws =
0x2aaab6398028 {        id = "o
bj",       {s,f,r,e} = {0x2aaab6398358,,0x2aaab6398358,(nil),+7336},
  },     http = {       ws = 0x2aaab6398028 {          id = "obj",
    {s,f,r,e} =
 {0x2aaab6398358,,0x2aaab6398358,(nil),+7336},       },     },     len
= 0,     store = {     },   }, },


Thank you.

-Paras


From plfgoa at gmail.com  Mon Mar 16 11:50:26 2009
From: plfgoa at gmail.com (Paras Fadte)
Date: Mon, 16 Mar 2009 17:20:26 +0530
Subject: Fwd: Panic message : Varnish restart
In-Reply-To: <5562.1231673155@critter.freebsd.dk>
References: <75cf5800901090422g7c28e7car4583ad1abdeeb103@mail.gmail.com>
	<5562.1231673155@critter.freebsd.dk>
Message-ID: <75cf5800903160450s3b26047bo76704ca1a0801de6@mail.gmail.com>

Hi Poul,


Got the following error in /var/log/messages regarding varnish . Has
this been rectified ?

Child (6871) died signal=6
varnishd[6870]: Child (6871) Panic message: Assert error in vsl_hdr(),
shmlog.c line 85:   Condition(id < 0x10000) not true.  thread
= (cache-worker)sp = 0x2aababf8c008 {   fd = 26689, id = 26689, xid =
742938330,   client = 81.52.249.100:25132,   step = STP_FETCH,
handling = fetch,   ws
 = 0x2aababf8c078 {      id = "sess",     {s,f,r,e} =
{0x2aababf8c808,,+1354,(nil),+16384},   },     worker = 0x2aac84f19c60
{     },     vcl = {       srcna
me = {         "input",         "Default",       },     },   obj =
0x2aaab6398000 {     refcnt = 1, xid = 742938330,     ws =
0x2aaab6398028 {        id = "o
bj",       {s,f,r,e} = {0x2aaab6398358,,0x2aaab6398358,(nil),+7336},
 },     http = {       ws = 0x2aaab6398028 {          id = "obj",
   {s,f,r,e} =
 {0x2aaab6398358,,0x2aaab6398358,(nil),+7336},       },     },     len
= 0,     store = {     },   }, },


Thank you.

-Paras


On Sun, Jan 11, 2009 at 4:55 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <75cf5800901090422g7c28e7car4583ad1abdeeb103 at mail.gmail.com>, "Paras
> ?Fadte" writes:
>
>>Can anybody please respond to the following ?query of mine ?
>
> I belive I fixed that yesterday in r3500 (ticket #387).
>
> Sorry about the delay.
>
> Poul-Henning
>
>
>>Thank you.
>>
>>-Paras
>>
>>---------- Forwarded message ----------
>>From: Paras Fadte <plfgoa at gmail.com>
>>Date: Fri, Jan 2, 2009 at 10:07 AM
>>Subject: Panic message : Varnish restart
>>To: "varnish-misc at projects.linpro.no" <varnish-misc at projects.linpro.no>
>>
>>
>>Hi,
>>
>>I got a message like following in /var/log/messages and child
>>restarted. what could be the issue ?
>>
>>varnishd[28876]: Child (31253) Panic message: Missing errorhandling
>>code in fetch_chunked(), cache_fetch.c line 113: ? Condition(be >
>> bp) not true. ?thread = (cache-worker)sp = 0x2aabd2970008 { ? fd =
>>302, id = 302, xid = 1800279969,
>>
>>Varnish Version is :
>>
>>varnishd (varnish-trunk)
>>Copyright (c) 2006-2008 Linpro AS / Verdens Gang AS
>>
>>Thanks in advance.
>>
>>-Paras
>>_______________________________________________
>>varnish-misc mailing list
>>varnish-misc at projects.linpro.no
>>http://projects.linpro.no/mailman/listinfo/varnish-misc
>>
>
> --
> Poul-Henning Kamp ? ? ? | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG ? ? ? ? | TCP/IP since RFC 956
> FreeBSD committer ? ? ? | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>


From iiminar at gmail.com  Tue Mar 17 17:26:13 2009
From: iiminar at gmail.com (Igor Minar)
Date: Tue, 17 Mar 2009 10:26:13 -0700
Subject: Intermittent latency issues on Solaris10 
Message-ID: <B5920F03-9817-4FC2-B5EA-ADBA917D5002@gmail.com>

Hi Folks!

I'm trying set up a Varnish instance on Solaris 10 and I'm facing some  
weird issue there. I was wondering if anyone could give me some  
insight into what's going on.

After applying a few patches (I submited all of them to Trac), I was  
able compile Varnish 2.0.2 and 2.0.3 with Sun Studio compiler. Varnish  
starts and is able to handle requests, but from time to time, I see  
multi-second latency when executing requests. As if varnish "hung" for  
a few seconds. This latency occurs for cache hits and is not caused by  
the backed app.

Interesting thing is that I don't see this issue on OpenSolaris  
2008.11 (varnish was compiled on both OSes with the latest Sun Studio  
compiler).

Here is to visualize what I see:
correct behavior on opensolaris: http://skitch.com/me3x/bf7j2/varnish-on-opensolaris
incorrect behavior on solaris10: http://skitch.com/me3x/bf7kr/varnish-on-solaris10

As you can see, on Solaris 10 there are at 3 requests that took more  
than 4 seconds to execute. I checked varnish logs and all of them were  
cache hits.

In the screenshots above, there was no other traffic hitting the  
server except for my single browser.

The problem is quite easily reproducible.

thanks,
Igor


From AbuSyed.Islam at cheapflights.com  Wed Mar 18 17:33:04 2009
From: AbuSyed.Islam at cheapflights.com (Abu Syed Islam)
Date: Wed, 18 Mar 2009 17:33:04 -0000
Subject: Caching ScriptResource.axd files-
In-Reply-To: <FB74E431522B2444838713348ED81F071CE16B@cfmail02.uk.cheapflights.com>
References: <FB74E431522B2444838713348ED81F071CE16B@cfmail02.uk.cheapflights.com>
Message-ID: <FB74E431522B2444838713348ED81F071CE16C@cfmail02.uk.cheapflights.com>

Hi All,

I am very new to Varnish and like to know how I could cache
ScriptResource.axd files? The browsers making several call to this file
per http page. But each call to ScriptResource.axd file generates
different query strings-

Like: ScriptResource.axd
d=XK_Bkbs8_NZPWZgZj5p-E66dhu5_crplipI-3JSp3ypKD5zxqJZIuJttrrN2mdwMC98HXo
cBBSradjJHct0Bm75GrRcj99Jxcc0XA1Ij-IEOPacf39IwOQWJ9iPuZC6IMUsUfpfRgxhD8W
MzMBgBpZvs6J_dedRV5Nm-2Idv0Lw1&t=351e0edd

Please help.

Thanks.

-Syed

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System. CFOUT
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090318/f1b6006a/attachment.html>

From harald at webmeisterei.com  Fri Mar 20 09:29:41 2009
From: harald at webmeisterei.com (Harald Friessnegger)
Date: Fri, 20 Mar 2009 10:29:41 +0100
Subject: make varnish don't start a subprocess
Message-ID: <200903201029.41499.harald@webmeisterei.com>

hi there

when i start varnishd i'll find two varnishd processes running afterwards:

? # top
? ...
? Mem: ? 1548288k total, ?1540624k used, ? ? 7664k free, ? ? 2172k buffers
? Swap: ?1048568k total, ? 767628k used, ? 280940k free, ? 171980k cached
? 13271 nobody ? ?15 ? 0 1864m 771m ?90m S ? ?0 51.0 ? 0:14.43 varnishd
? 13263 zope ? ? ?15 ? 0 ?635m 454m 3500 S ? ?0 30.1 ?47:59.16 python2.4
? 13265 root ? ? ?15 ? 0 98192 ?81m ?80m S ? ?0 ?5.4 ? 0:00.04 varnishd
? 13262 root ? ? ?16 ? 0 ?109m ?12m 2772 S ? ?0 ?0.8 ? 0:50.06 python2.4
? ...


is there a way to run varnish as a single process?


background:
i'd like to control the memory-usage of processes and restart them if they 
grow above a certain limit using http://supervisord.org/.

the varnishd started by supervisor just needs 5% memory and gets restarted if 
it grows above a certain limit. the subprocess eats up my RAM and can't be 
conrolled by supervisor.

full problem description can be seen in the supervisor-users mailinglist 
archive:
http://lists.supervisord.org/pipermail/supervisor-users/2009-March/000313.html

people at supervisor mailing list pointed me to varnish-misc.


thanks for your help!
  fRiSi









-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com


From des at des.no  Fri Mar 20 18:14:30 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri, 20 Mar 2009 19:14:30 +0100
Subject: make varnish don't start a subprocess
In-Reply-To: <200903201029.41499.harald@webmeisterei.com> (Harald
	Friessnegger's message of "Fri, 20 Mar 2009 10:29:41 +0100")
References: <200903201029.41499.harald@webmeisterei.com>
Message-ID: <86vdq42ha1.fsf@ds4.des.no>

Harald Friessnegger <harald at webmeisterei.com> writes:
> when i start varnishd i'll find two varnishd processes running
> afterwards:

Yes.

> is there a way to run varnish as a single process?

No.

> the varnishd started by supervisor just needs 5% memory and gets
> restarted if it grows above a certain limit. the subprocess eats up my
> RAM and can't be conrolled by supervisor.

The parent will restart it if you kill it (but doing so will flush the
cache).  However, varnishd doesn't "eat memory", unless there is a bug.
You should read varnishd(1) and figure out how to select the storage
backend and how to limit the size of the cache.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From tnguyen at bleacherreport.com  Sun Mar 22 09:01:37 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Sun, 22 Mar 2009 02:01:37 -0700
Subject: varnishlog output column meaning
Message-ID: <ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com>

Hey guys,

In the the varnishlog output

https://gist.github.com/8b163cc29fbd5e3141f6

Where can I find out more info on what the columns mean,
So what does the 7 vs 10 mean in the first column?
What does the b vs c mean in the second column?

 7 VCL_return   c pass
10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000
 7 Backend      c 10 default default
10 TxRequest    b HEAD

Thanks in advance for any responses,
Tung


From phk at phk.freebsd.dk  Sun Mar 22 09:08:55 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 22 Mar 2009 09:08:55 +0000
Subject: varnishlog output column meaning 
In-Reply-To: Your message of "Sun, 22 Mar 2009 02:01:37 MST."
	<ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com> 
Message-ID: <49467.1237712935@critter.freebsd.dk>

In message <ca6364050903220201t1f50f65btd5b4904f5703f735 at mail.gmail.com>, Tung 
Nguyen writes:
>Hey guys,
>
>In the the varnishlog output
>
>https://gist.github.com/8b163cc29fbd5e3141f6
>
>Where can I find out more info on what the columns mean,
>So what does the 7 vs 10 mean in the first column?
>What does the b vs c mean in the second column?

The first column is a magic number for each transaction.

This is what allows you collect all the messages that
belong to the same transaction.

For the time being, it is also the file descriptor number
of the socket, but this is not guaranteed to always be the
case.

The 'b' means "backend transaction, and 'c' client side
transaction.

> 7 VCL_return   c pass
>10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000
> 7 Backend      c 10 default default
>10 TxRequest    b HEAD

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


From tnguyen at bleacherreport.com  Sun Mar 22 11:11:40 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Sun, 22 Mar 2009 04:11:40 -0700
Subject: varnishlog output column meaning
In-Reply-To: <49467.1237712935@critter.freebsd.dk>
References: <ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com>
	<49467.1237712935@critter.freebsd.dk>
Message-ID: <ca6364050903220411y3134e297hf51dbfbb17cc2257@mail.gmail.com>

Ic, Poul-Henning thank you!
Hey guys,

Im still trying to get a handle how to debug these vcl rules best here..

https://gist.github.com/ca5ef043fdfb89a5b143

Ive got some simple tests set up, mainly based on
http://overstimulate.com/articles/varnish-getting-started

With app #1 caching happens fine, but with app #2 with the same very general
vcl rules, I cant seem to get caching to work :(.

There's a few questions at the end of the gist:
1. Why isnt app #2 picking up the cache?  I think maybe the rails app
returns a slighly
different header that could be causing a problem but I dont see anything
different in the
varnishlog output :(.
2. Is there a way to check what is in the cache from the "telnet localhost
6082" or anything
else, if I have the key, "/articles;feed?tag_id=16" in this case.  Maybe
thats whats going on,
the data isnt being written into the cache...
3. I also tried adding some C code (commented out) to maybe puts some output
out or writing to
a file (maybe through a system call could work too) to see which part of the
vcl chain Im
hitting.  Whats a good way of doing that?  This would be great to know how
to do so I can
check the vcl rules.


Thanks again and any responses are appreciated.
Tung


On Sun, Mar 22, 2009 at 2:08 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:

> In message <ca6364050903220201t1f50f65btd5b4904f5703f735 at mail.gmail.com>,
> Tung
> Nguyen writes:
> >Hey guys,
> >
> >In the the varnishlog output
> >
> >https://gist.github.com/8b163cc29fbd5e3141f6
> >
> >Where can I find out more info on what the columns mean,
> >So what does the 7 vs 10 mean in the first column?
> >What does the b vs c mean in the second column?
>
> The first column is a magic number for each transaction.
>
> This is what allows you collect all the messages that
> belong to the same transaction.
>
> For the time being, it is also the file descriptor number
> of the socket, but this is not guaranteed to always be the
> case.
>
> The 'b' means "backend transaction, and 'c' client side
> transaction.
>
> > 7 VCL_return   c pass
> >10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000
> > 7 Backend      c 10 default default
> >10 TxRequest    b HEAD
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>



-- 
Tung Nguyen, Lead Developer
Bleacher Report, The Open Source Sports Network
(510) 928-0475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090322/1f98f675/attachment.html>

From tnguyen at bleacherreport.com  Sun Mar 22 21:22:14 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Sun, 22 Mar 2009 14:22:14 -0700
Subject: varnishlog output column meaning
In-Reply-To: <ca6364050903220411y3134e297hf51dbfbb17cc2257@mail.gmail.com>
References: <ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com>
	<49467.1237712935@critter.freebsd.dk>
	<ca6364050903220411y3134e297hf51dbfbb17cc2257@mail.gmail.com>
Message-ID: <ca6364050903221422j63898e85pd42353083e145f69@mail.gmail.com>

Hey guys,

Adding this, to the simple.vcl config enabled caching in the app #2.

sub vcl_fetch {
  unset obj.http.set-cookie;  # NEED TO DELETE COOKIE ON THE FETCH ALSO?
  unset obj.http.expires;
  set obj.ttl = 1m;
}


https://gist.github.com/ca5ef043fdfb89a5b143


Why do I need to delete the cookie on the vcl_fetch so varnish will actually
cache..?

Thanks in advanced again,
Tung


On Sun, Mar 22, 2009 at 4:11 AM, Tung Nguyen <tnguyen at bleacherreport.com>wrote:

> Ic, Poul-Henning thank you!
> Hey guys,
>
> Im still trying to get a handle how to debug these vcl rules best here..
>
> https://gist.github.com/ca5ef043fdfb89a5b143
>
> Ive got some simple tests set up, mainly based on
> http://overstimulate.com/articles/varnish-getting-started
>
> With app #1 caching happens fine, but with app #2 with the same very
> general vcl rules, I cant seem to get caching to work :(.
>
> There's a few questions at the end of the gist:
> 1. Why isnt app #2 picking up the cache?  I think maybe the rails app
> returns a slighly
> different header that could be causing a problem but I dont see anything
> different in the
> varnishlog output :(.
> 2. Is there a way to check what is in the cache from the "telnet localhost
> 6082" or anything
> else, if I have the key, "/articles;feed?tag_id=16" in this case.  Maybe
> thats whats going on,
> the data isnt being written into the cache...
> 3. I also tried adding some C code (commented out) to maybe puts some
> output out or writing to
> a file (maybe through a system call could work too) to see which part of
> the vcl chain Im
> hitting.  Whats a good way of doing that?  This would be great to know how
> to do so I can
> check the vcl rules.
>
>
> Thanks again and any responses are appreciated.
> Tung
>
>
> On Sun, Mar 22, 2009 at 2:08 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:
>
>> In message <ca6364050903220201t1f50f65btd5b4904f5703f735 at mail.gmail.com>,
>> Tung
>> Nguyen writes:
>> >Hey guys,
>> >
>> >In the the varnishlog output
>> >
>> >https://gist.github.com/8b163cc29fbd5e3141f6
>> >
>> >Where can I find out more info on what the columns mean,
>> >So what does the 7 vs 10 mean in the first column?
>> >What does the b vs c mean in the second column?
>>
>> The first column is a magic number for each transaction.
>>
>> This is what allows you collect all the messages that
>> belong to the same transaction.
>>
>> For the time being, it is also the file descriptor number
>> of the socket, but this is not guaranteed to always be the
>> case.
>>
>> The 'b' means "backend transaction, and 'c' client side
>> transaction.
>>
>> > 7 VCL_return   c pass
>> >10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000
>> > 7 Backend      c 10 default default
>> >10 TxRequest    b HEAD
>>
>> --
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> phk at FreeBSD.ORG         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by
>> incompetence.
>>
>
>
>
> --
> Tung Nguyen, Lead Developer
> Bleacher Report, The Open Source Sports Network
> (510) 928-0475
>



-- 
Tung Nguyen, Lead Developer
Bleacher Report, The Open Source Sports Network
(510) 928-0475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090322/1279c012/attachment.html>

From tnguyen at bleacherreport.com  Sun Mar 22 21:41:56 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Sun, 22 Mar 2009 14:41:56 -0700
Subject: varnishlog output column meaning
In-Reply-To: <ca6364050903221422j63898e85pd42353083e145f69@mail.gmail.com>
References: <ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com>
	<49467.1237712935@critter.freebsd.dk>
	<ca6364050903220411y3134e297hf51dbfbb17cc2257@mail.gmail.com>
	<ca6364050903221422j63898e85pd42353083e145f69@mail.gmail.com>
Message-ID: <ca6364050903221441q2cba7e7bhf9badcbb21c9f20c@mail.gmail.com>

I take that back, I needed to add all of these to vcl_fetch to get the rails
app to cache via varnish..

sub vcl_fetch {
  unset obj.http.set-cookie;
  unset obj.http.expires;
  set obj.ttl = 1m;
  deliver;
}

Tung


On Sun, Mar 22, 2009 at 2:22 PM, Tung Nguyen <tnguyen at bleacherreport.com>wrote:

> Hey guys,
>
> Adding this, to the simple.vcl config enabled caching in the app #2.
>
> sub vcl_fetch {
>   unset obj.http.set-cookie;  # NEED TO DELETE COOKIE ON THE FETCH ALSO?
>   unset obj.http.expires;
>   set obj.ttl = 1m;
> }
>
>
> https://gist.github.com/ca5ef043fdfb89a5b143
>
>
> Why do I need to delete the cookie on the vcl_fetch so varnish will
> actually cache..?
>
> Thanks in advanced again,
> Tung
>
>
> On Sun, Mar 22, 2009 at 4:11 AM, Tung Nguyen <tnguyen at bleacherreport.com>wrote:
>
>> Ic, Poul-Henning thank you!
>> Hey guys,
>>
>> Im still trying to get a handle how to debug these vcl rules best here..
>>
>> https://gist.github.com/ca5ef043fdfb89a5b143
>>
>> Ive got some simple tests set up, mainly based on
>> http://overstimulate.com/articles/varnish-getting-started
>>
>> With app #1 caching happens fine, but with app #2 with the same very
>> general vcl rules, I cant seem to get caching to work :(.
>>
>> There's a few questions at the end of the gist:
>> 1. Why isnt app #2 picking up the cache?  I think maybe the rails app
>> returns a slighly
>> different header that could be causing a problem but I dont see anything
>> different in the
>> varnishlog output :(.
>> 2. Is there a way to check what is in the cache from the "telnet localhost
>> 6082" or anything
>> else, if I have the key, "/articles;feed?tag_id=16" in this case.  Maybe
>> thats whats going on,
>> the data isnt being written into the cache...
>> 3. I also tried adding some C code (commented out) to maybe puts some
>> output out or writing to
>> a file (maybe through a system call could work too) to see which part of
>> the vcl chain Im
>> hitting.  Whats a good way of doing that?  This would be great to know how
>> to do so I can
>> check the vcl rules.
>>
>>
>> Thanks again and any responses are appreciated.
>> Tung
>>
>>
>> On Sun, Mar 22, 2009 at 2:08 AM, Poul-Henning Kamp <phk at phk.freebsd.dk>wrote:
>>
>>> In message <ca6364050903220201t1f50f65btd5b4904f5703f735 at mail.gmail.com>,
>>> Tung
>>> Nguyen writes:
>>> >Hey guys,
>>> >
>>> >In the the varnishlog output
>>> >
>>> >https://gist.github.com/8b163cc29fbd5e3141f6
>>> >
>>> >Where can I find out more info on what the columns mean,
>>> >So what does the 7 vs 10 mean in the first column?
>>> >What does the b vs c mean in the second column?
>>>
>>> The first column is a magic number for each transaction.
>>>
>>> This is what allows you collect all the messages that
>>> belong to the same transaction.
>>>
>>> For the time being, it is also the file descriptor number
>>> of the socket, but this is not guaranteed to always be the
>>> case.
>>>
>>> The 'b' means "backend transaction, and 'c' client side
>>> transaction.
>>>
>>> > 7 VCL_return   c pass
>>> >10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000
>>> > 7 Backend      c 10 default default
>>> >10 TxRequest    b HEAD
>>>
>>> --
>>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> phk at FreeBSD.ORG         | TCP/IP since RFC 956
>>> FreeBSD committer       | BSD since 4.3-tahoe
>>> Never attribute to malice what can adequately be explained by
>>> incompetence.
>>>
>>
>>
>>
>> --
>> Tung Nguyen, Lead Developer
>> Bleacher Report, The Open Source Sports Network
>> (510) 928-0475
>>
>
>
>
> --
> Tung Nguyen, Lead Developer
> Bleacher Report, The Open Source Sports Network
> (510) 928-0475
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090322/3116f6dd/attachment.html>

From olau at iola.dk  Mon Mar 23 11:18:39 2009
From: olau at iola.dk (Ole Laursen)
Date: Mon, 23 Mar 2009 11:18:39 +0000 (UTC)
Subject: Default behaviour with regards to Cache-Control
References: <loom.20090212T102450-275@post.gmane.org>
	<1528.1234438499@critter.freebsd.dk>
	<loom.20090212T133522-958@post.gmane.org>
Message-ID: <loom.20090323T111421-662@post.gmane.org>

Ole Laursen <olau at ...> writes:

> > Well, if people in general think our defaults should be that way, we
> > can change them, our defaults are whatever the consensus can agree on.
> 
> Cool! That'd make one particular webserver owner's job a bit easier, and I
> suspect many others too. :)

I've opened an issue now:

  http://varnish.projects.linpro.no/ticket/477

It probably sounds obvious now, but it was really difficult to track down why my
web app didn't work as expected since the problem only manifested itself
occasionally (took more than 6 months before I finally figured it out). I really
didn't expect it.


Ole



From sfoutrel at bcstechno.com  Mon Mar 23 11:32:22 2009
From: sfoutrel at bcstechno.com (=?iso-8859-1?Q?S=E9bastien_FOUTREL?=)
Date: Mon, 23 Mar 2009 12:32:22 +0100
Subject: Purge and cache content mist.
Message-ID: <D71E8F2EEEAFB64BB0336A4D09E512F7B037DD@hermes.BCSTECHNO.local>

Hello,

I read a lot of things in the list and varnish sites but some things stay fuzzy to me.

Is there a way to find if something is in the cache, have a map of cached content or some script that give one ?

Is it possible to do recursive purge in a way or another ?

I'd like to purge "www.example.org/that-part/" is to possible to simply purge all objects under that url ?

Thank you.

--
S?bastien FOUTREL





From harald at webmeisterei.com  Mon Mar 23 13:14:23 2009
From: harald at webmeisterei.com (Harald Friessnegger)
Date: Mon, 23 Mar 2009 14:14:23 +0100
Subject: Purge and cache content mist.
In-Reply-To: <D71E8F2EEEAFB64BB0336A4D09E512F7B037DD@hermes.BCSTECHNO.local>
References: <D71E8F2EEEAFB64BB0336A4D09E512F7B037DD@hermes.BCSTECHNO.local>
Message-ID: <200903231414.24022.harald@webmeisterei.com>

hi sebastien


Am Montag, 23. M?rz 2009 12:32:22 schrieb S?bastien FOUTREL:
> Hello,
>
> I read a lot of things in the list and varnish sites but some things stay
> fuzzy to me.
>
> Is there a way to find if something is in the cache, have a map of cached
> content or some script that give one ?

i don't know of a list output. what i do is to use varnishlog or turn on debug 
headers:


open varnishlog, request a resource and see at the X-Varnish-Action Header


requesting a resource the first time that gets cached will give you

TxHeader     c X-Varnish-Action: FETCH (insert)

requesting it again will log

TxHeader     c X-Varnish-Action: HIT (deliver - from cache)



personally i'm using some combination with grep that gives me the headers i'm 
interested in:


For debugging all requests to a certain url (eg /test/test/image_mini) and see 
important headers::

varnishlog -c -o  RxURL '^/test/test/image_mini$' | grep -E "RxRequest|RxURL|
Host:|TxStatus|TxResponse|X-Varnish-Action"



>
> Is it possible to do recursive purge in a way or another ?
>
> I'd like to purge "www.example.org/that-part/" is to possible to simply
> purge all objects under that url ?


run varnish with the -T option (eg "-T localhost:6182")

connet via telnet:

telnet localhost 6182

and call something like

url.purge /that-part/.*


to see whether to use www.example.org/that-part or just /that-part or any 
other fancy url (you might have a webserver rewrite urls for doing 
virtualhosting) you can use varnishlog again:

varnishlog -c -i RxURL



hope that helps
  fRiSi


>
> Thank you.
>
> --
> S?bastien FOUTREL
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc



-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com


From lukas.loesche at bertelsmann.de  Mon Mar 23 13:14:31 2009
From: lukas.loesche at bertelsmann.de (Loesche, Lukas, scoyo)
Date: Mon, 23 Mar 2009 14:14:31 +0100
Subject: Purge and cache content mist.
In-Reply-To: <C5ED41EF.FE99%lukas.loesche@bertelsmann.de>
Message-ID: <C5ED49C7.FEA0%lukas.loesche@bertelsmann.de>


> From: S?bastien FOUTREL <sfoutrel at bcstechno.com>
...
> Is there a way to find if something is in the cache, have a map of cached
> content or some script that give one ?

http://varnish.projects.linpro.no/wiki/FAQ#CanIseewhatVarnishholdsinthecache

> Is it possible to do recursive purge in a way or another ?

http://varnish.projects.linpro.no/wiki/FAQ#HowcanIforcearefreshonaobjectcach
edbyvarnish


Cheers,
-- Lukas



From sfoutrel at bcstechno.com  Mon Mar 23 14:10:01 2009
From: sfoutrel at bcstechno.com (=?iso-8859-1?Q?S=E9bastien_FOUTREL?=)
Date: Mon, 23 Mar 2009 15:10:01 +0100
Subject: Purge and cache content mist.
In-Reply-To: <200903231414.24022.harald@webmeisterei.com>
References: <D71E8F2EEEAFB64BB0336A4D09E512F7B037DD@hermes.BCSTECHNO.local>
	<200903231414.24022.harald@webmeisterei.com>
Message-ID: <D71E8F2EEEAFB64BB0336A4D09E512F7B037E4@hermes.BCSTECHNO.local>

Thank you.

About the url.purge, should I understand that url.purge doesn't manage hosts
 so url.purge /that-part/.* will purge  http://onedomain.com/that-part/* and http://otherdomain.com/that-part/* ?
Can I use onedomaine\.com/that-part/.* to purge only '/that-part/' in that host :) ?


-----Message d'origine-----
De?: Harald Friessnegger [mailto:harald at webmeisterei.com] 
Envoy??: lundi 23 mars 2009 14:14
??: varnish-misc at projects.linpro.no
Cc?: S?bastien FOUTREL
Objet?: Re: Purge and cache content mist.

hi sebastien


Am Montag, 23. M?rz 2009 12:32:22 schrieb S?bastien FOUTREL:
> Hello,
>
> I read a lot of things in the list and varnish sites but some things stay
> fuzzy to me.
>
> Is there a way to find if something is in the cache, have a map of cached
> content or some script that give one ?

i don't know of a list output. what i do is to use varnishlog or turn on debug 
headers:


open varnishlog, request a resource and see at the X-Varnish-Action Header


requesting a resource the first time that gets cached will give you

TxHeader     c X-Varnish-Action: FETCH (insert)

requesting it again will log

TxHeader     c X-Varnish-Action: HIT (deliver - from cache)



personally i'm using some combination with grep that gives me the headers i'm 
interested in:


For debugging all requests to a certain url (eg /test/test/image_mini) and see 
important headers::

varnishlog -c -o  RxURL '^/test/test/image_mini$' | grep -E "RxRequest|RxURL|
Host:|TxStatus|TxResponse|X-Varnish-Action"



>
> Is it possible to do recursive purge in a way or another ?
>
> I'd like to purge "www.example.org/that-part/" is to possible to simply
> purge all objects under that url ?


run varnish with the -T option (eg "-T localhost:6182")

connet via telnet:

telnet localhost 6182

and call something like

url.purge /that-part/.*


to see whether to use www.example.org/that-part or just /that-part or any 
other fancy url (you might have a webserver rewrite urls for doing 
virtualhosting) you can use varnishlog again:

varnishlog -c -i RxURL



hope that helps
  fRiSi


>
> Thank you.
>
> --
> S?bastien FOUTREL
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc



-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com




From harald at webmeisterei.com  Mon Mar 23 14:26:37 2009
From: harald at webmeisterei.com (Harald Friessnegger)
Date: Mon, 23 Mar 2009 15:26:37 +0100
Subject: Purge and cache content mist.
In-Reply-To: <D71E8F2EEEAFB64BB0336A4D09E512F7B037E4@hermes.BCSTECHNO.local>
References: <D71E8F2EEEAFB64BB0336A4D09E512F7B037DD@hermes.BCSTECHNO.local>
	<200903231414.24022.harald@webmeisterei.com>
	<D71E8F2EEEAFB64BB0336A4D09E512F7B037E4@hermes.BCSTECHNO.local>
Message-ID: <200903231526.37982.harald@webmeisterei.com>

hi 

Am Montag, 23. M?rz 2009 15:10:01 schrieb S?bastien FOUTREL:
> Thank you.
>
> About the url.purge, should I understand that url.purge doesn't manage
> hosts so url.purge /that-part/.* will purge 
> http://onedomain.com/that-part/* and http://otherdomain.com/that-part/* ?
> Can I use onedomaine\.com/that-part/.* to purge only '/that-part/' in that
> host :) ?

on my setup i only have one host. i'm sure you can restrict that to one single 
host, but i don't know by heart.


if url.purge can't do that you can setup url purging
see the link below the faq question
http://varnish.projects.linpro.no/wiki/FAQ#HowcanIforcearefreshonaobjectcachedbyvarnish
http://varnish.projects.linpro.no/wiki/VCLExamplePurging

regards, harald

>
>
> -----Message d'origine-----
> De?: Harald Friessnegger [mailto:harald at webmeisterei.com]
> Envoy??: lundi 23 mars 2009 14:14
> ??: varnish-misc at projects.linpro.no
> Cc?: S?bastien FOUTREL
> Objet?: Re: Purge and cache content mist.
>
> hi sebastien
>
> Am Montag, 23. M?rz 2009 12:32:22 schrieb S?bastien FOUTREL:
> > Hello,
> >
> > I read a lot of things in the list and varnish sites but some things stay
> > fuzzy to me.
> >
> > Is there a way to find if something is in the cache, have a map of cached
> > content or some script that give one ?
>
> i don't know of a list output. what i do is to use varnishlog or turn on
> debug headers:
>
>
> open varnishlog, request a resource and see at the X-Varnish-Action Header
>
>
> requesting a resource the first time that gets cached will give you
>
> TxHeader     c X-Varnish-Action: FETCH (insert)
>
> requesting it again will log
>
> TxHeader     c X-Varnish-Action: HIT (deliver - from cache)
>
>
>
> personally i'm using some combination with grep that gives me the headers
> i'm interested in:
>
>
> For debugging all requests to a certain url (eg /test/test/image_mini) and
> see important headers::
>
> varnishlog -c -o  RxURL '^/test/test/image_mini$' | grep -E
> "RxRequest|RxURL| Host:|TxStatus|TxResponse|X-Varnish-Action"
>
> > Is it possible to do recursive purge in a way or another ?
> >
> > I'd like to purge "www.example.org/that-part/" is to possible to simply
> > purge all objects under that url ?
>
> run varnish with the -T option (eg "-T localhost:6182")
>
> connet via telnet:
>
> telnet localhost 6182
>
> and call something like
>
> url.purge /that-part/.*
>
>
> to see whether to use www.example.org/that-part or just /that-part or any
> other fancy url (you might have a webserver rewrite urls for doing
> virtualhosting) you can use varnishlog again:
>
> varnishlog -c -i RxURL
>
>
>
> hope that helps
>   fRiSi
>
> > Thank you.
> >
> > --
> > S?bastien FOUTREL
> >
> >
> >
> > _______________________________________________
> > varnish-misc mailing list
> > varnish-misc at projects.linpro.no
> > http://projects.linpro.no/mailman/listinfo/varnish-misc



-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com


From lukas.loesche at bertelsmann.de  Mon Mar 23 14:53:54 2009
From: lukas.loesche at bertelsmann.de (Loesche, Lukas, scoyo)
Date: Mon, 23 Mar 2009 15:53:54 +0100
Subject: Purge and cache content mist.
In-Reply-To: <200903231526.37982.harald@webmeisterei.com>
Message-ID: <C5ED6112.FEC0%lukas.loesche@bertelsmann.de>


 
> on my setup i only have one host. i'm sure you can restrict that to one single
> host, but i don't know by heart.

I don't think you can. At least I couldn't find any method to do host based
purging without using the PURGE HTTP Method.

> if url.purge can't do that you can setup url purging
> see the link below the faq question
> http://varnish.projects.linpro.no/wiki/FAQ#HowcanIforcearefreshonaobjectcached
> byvarnish
> http://varnish.projects.linpro.no/wiki/VCLExamplePurging

True, but if he's doing this he can't do Wildcard purging!

If there's any way to do wildcard purging on a specific hostname I'd be
interested in that too.

Something like for instance

PURGE /foo/bar/.* HTTP/1.1
Host: some.host.tld

But afaik this is not possible yet.


Thanks,
-- Lukas



From tnguyen at bleacherreport.com  Tue Mar 24 00:58:58 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Mon, 23 Mar 2009 17:58:58 -0700
Subject: varnishd runtime parameters
Message-ID: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>

Hi guys,
So, Im reading over an archive email thread about twitters configuration.

http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html

It looks like they had to adjust a lot of parameters... and Im not finding
all the parameters definitions in the varnishd man pages.  Im wondering if
for most cases running varnish with the defaults is fine?

Any caveats here which run time parameters should I focus on.

Like with the vcl, the main two hooks to pay attention to are vcl_recv and
vcl_fetch

Any advice is appreciated,
Thanks,
Tung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090323/caf3a510/attachment.html>

From kristian at redpill-linpro.com  Tue Mar 24 07:20:50 2009
From: kristian at redpill-linpro.com (Kristian Lyngstol)
Date: Tue, 24 Mar 2009 08:20:50 +0100
Subject: varnishd runtime parameters
In-Reply-To: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>
References: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>
Message-ID: <20090324072050.GA17483@kjeks.linpro.no>

On Mon, Mar 23, 2009 at 05:58:58PM -0700, Tung Nguyen wrote:
> Hi guys,
> So, Im reading over an archive email thread about twitters configuration.
> 
> http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html
> 
> It looks like they had to adjust a lot of parameters... and Im not finding
> all the parameters definitions in the varnishd man pages.  Im wondering if
> for most cases running varnish with the defaults is fine?
> 
> Any caveats here which run time parameters should I focus on.

You can mostly run it with the defaults, yes. This depends on what sort of
usage you have though.

One notable exception is that I strongly recommend that you bring
thread_pool_min up to a decent level (reflecting how many users you
actually have. Numbers in the hundreds is normal). You'll also want to
adjust the cache size to your system, but that goes without saying. 

If you expect extremely high load, you might have to increase cli_timeout
too. I've run tests where even setting it to 15 seconds is insufficient and
causes childs to be killed off. Though for most production sites, I'd guess
5 seconds could work and 10 seconds would definitely work.

-- 
Kristian Lyngst?l
Redpill Linpro AS
Tlf: +47 21544179
Mob: +47 99014497
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090324/1c2418c0/attachment.bin>

From harald at webmeisterei.com  Tue Mar 24 15:13:55 2009
From: harald at webmeisterei.com (Harald Friessnegger)
Date: Tue, 24 Mar 2009 16:13:55 +0100
Subject: make varnish don't start a subprocess
In-Reply-To: <86vdq42ha1.fsf@ds4.des.no>
References: <200903201029.41499.harald@webmeisterei.com>
	<86vdq42ha1.fsf@ds4.des.no>
Message-ID: <200903241613.55858.harald@webmeisterei.com>

hi des

Am Freitag, 20. M?rz 2009 19:14:30 schrieb Dag-Erling Sm?rgrav:
> > the varnishd started by supervisor just needs 5% memory and gets
> > restarted if it grows above a certain limit. the subprocess eats up my
> > RAM and can't be conrolled by supervisor.
>
> The parent will restart it if you kill it (but doing so will flush the
> cache).  However, varnishd doesn't "eat memory", unless there is a bug.
> You should read varnishd(1) and figure out how to select the storage
> backend and how to limit the size of the cache.
>
> DES

i'd be happy to make varnish stick to a certain memory limit.
maybe you've got some ideas how to make that happen?

is the file backend i'm using too small?
what other factors could make the varnish process use such a lot of RAM


i try to provide as much information as possible, please let me know if you 
need further details:

atm we're using filestorage with a limit of 500M.

whilst the file itself is exactly 500 megabyte in size, varnish
uses 1115M memory - 44% of the total available 2,5GB RAM (1,5GB RAM, 1GB 
disk-swap) after 5 days of uptime. see `figure 1` below.


these are the arguments we're starting varnish with:

#!/bin/sh
exec /home/zope/parts/varnish-build/sbin/varnishd \
    -f "/home/zope/etc/varnish.vcl" \
    -P "/home/zope/parts/varnish/varnish.pid" \
    -a localhost:6181 \
    -T localhost:6182 \
    -s file,"/home/zope/parts/varnish/storage",500M \
    -F \
    -t 0 "$@"


varnish version: varnish-2.0.2.tar.gz



figure 1: memory consumption of varnish and it's subprocess::

  Mem:   1548288k total,  1540604k used,     7684k free,      680k buffers
  Swap:  1048568k total,  1048568k used,        0k free,   156252k cached
  
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  4096 nobody    15   0 1921m 666m  81m S    0 44.1   0:42.44 varnishd
  13263 zope      15   0  908m 646m 1764 S    0 42.8 252:01.48 python2.4
  4090 root      15   0 98196  80m  80m S    0  5.3   0:00.12 varnishd


thanks for your help,
  fRiSi

-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com


From des at des.no  Tue Mar 24 16:10:56 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 24 Mar 2009 17:10:56 +0100
Subject: make varnish don't start a subprocess
In-Reply-To: <200903241613.55858.harald@webmeisterei.com> (Harald
	Friessnegger's message of "Tue, 24 Mar 2009 16:13:55 +0100")
References: <200903201029.41499.harald@webmeisterei.com>
	<86vdq42ha1.fsf@ds4.des.no>
	<200903241613.55858.harald@webmeisterei.com>
Message-ID: <86vdpylx4f.fsf@ds4.des.no>

Harald Friessnegger <harald at webmeisterei.com> writes:
> i'd be happy to make varnish stick to a certain memory limit.
> maybe you've got some ideas how to make that happen?
>
> is the file backend i'm using too small?

If you're using a storage file, varnishd will use a relatively small
amount of memory + address space roughly equal to the size of the file.

> whilst the file itself is exactly 500 megabyte in size, varnish
> uses 1115M memory - 44% of the total available 2,5GB RAM (1,5GB RAM, 1GB 
> disk-swap) after 5 days of uptime. see `figure 1` below.

It's not that simple.  The file is mapped into varnishd's address space,
so the VIRT number you get from top includes the size of the file (as
well as the size of the program itself and all libraries it uses).  RES
is how much of that is actually in RAM.  The OS may swap unused parts of
the cache to the storage file, but never to the swap partition.

You should probably look at /proc/$pid/map instead of using top, BTW.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From des at des.no  Tue Mar 24 16:32:48 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 24 Mar 2009 17:32:48 +0100
Subject: Purge and cache content mist.
In-Reply-To: <C5ED49C7.FEA0%lukas.loesche@bertelsmann.de> (Lukas Loesche's
	message of "Mon, 23 Mar 2009 14:14:31 +0100")
References: <C5ED49C7.FEA0%lukas.loesche@bertelsmann.de>
Message-ID: <86mybalw3z.fsf@ds4.des.no>

"Loesche, Lukas, scoyo" <lukas.loesche at bertelsmann.de> writes:
> S?bastien FOUTREL <sfoutrel at bcstechno.com>
> > Is there a way to find if something is in the cache, have a map of cached
> > content or some script that give one ?
> http://varnish.projects.linpro.no/wiki/FAQ#CanIseewhatVarnishholdsinthecache

That's not a very good answer, actually.  It almost sounds like "we
can't be bothered to implement it".  The real reason is that URLs are
not stored in the cache - hash strings are.  What's more, different URLs
may hash to the same object, so there would be no way to generate an
unambiguous list.

That being said, the FAQ is correct in that it would be a very expensive
operation - listing the contents of the cache on a large server could
very well stall it for seconds or, in the worst case, minutes.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From sfoutrel at bcstechno.com  Tue Mar 24 17:28:24 2009
From: sfoutrel at bcstechno.com (=?utf-8?B?U8OpYmFzdGllbiBGT1VUUkVM?=)
Date: Tue, 24 Mar 2009 18:28:24 +0100
Subject: Purge and cache content mist.
In-Reply-To: <86mybalw3z.fsf@ds4.des.no>
References: <C5ED49C7.FEA0%lukas.loesche@bertelsmann.de>
	<86mybalw3z.fsf@ds4.des.no>
Message-ID: <D71E8F2EEEAFB64BB0336A4D09E512F7B0382C@hermes.BCSTECHNO.local>

Thank You DES for your answer.
About the url.purge, do I purge an URL or an URI with it ?
Does url.purge firstdomain\.com/that-part/.* will do the job for all contents under /that-part/ of domain firstdomain.com ?

Cheers

-----Message d'origine-----
De?: varnish-misc-bounces at projects.linpro.no [mailto:varnish-misc-bounces at projects.linpro.no] De la part de Dag-Erling Sm?rgrav
Envoy??: mardi 24 mars 2009 17:33
??: Loesche, Lukas, scoyo
Cc?: varnish-misc at projects.linpro.no
Objet?: Re: Purge and cache content mist.

"Loesche, Lukas, scoyo" <lukas.loesche at bertelsmann.de> writes:
> S?bastien FOUTREL <sfoutrel at bcstechno.com>
> > Is there a way to find if something is in the cache, have a map of cached
> > content or some script that give one ?
> http://varnish.projects.linpro.no/wiki/FAQ#CanIseewhatVarnishholdsinthecache

That's not a very good answer, actually.  It almost sounds like "we
can't be bothered to implement it".  The real reason is that URLs are
not stored in the cache - hash strings are.  What's more, different URLs
may hash to the same object, so there would be no way to generate an
unambiguous list.

That being said, the FAQ is correct in that it would be a very expensive
operation - listing the contents of the cache on a large server could
very well stall it for seconds or, in the worst case, minutes.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no
_______________________________________________
varnish-misc mailing list
varnish-misc at projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc

From sergei.kononov at gmail.com  Wed Mar 25 12:40:37 2009
From: sergei.kononov at gmail.com (Sergei Kononov)
Date: Wed, 25 Mar 2009 15:40:37 +0300
Subject: Weird backend selection policy
Message-ID: <c0f4783e0903250540o2e46e37t5254108a41d9b575@mail.gmail.com>

Hi,

I noticed weird behavior of backend selection. Some request goes to
backend which is not suitable for them, as result I getting 404 or 500
errors, but I noticed that removing "lookup" in end of vcl_recv can
fix that problem, at least this problem does not occur so frequently
after that.

Here is my vcl_recv:

sub vcl_recv {
   set req.http.X-Cacheable = "true";
   set req.http.X-Forwarded-For=client.ip;
   set req.backend = default;

   if ( req.url ~ "^/api/.*" ) {
      set req.backend = b2;
      set req.url = regsub(req.url, "^/api/", "/")
      set req.http.X-Cacheable = "false";
      pipe;
   }

   if ( req.url ~ "^/rpc.*" ) {
      set req.backend = rpc;
      set req.http.X-Cacheable = "false";
      pipe;
   }

   if ( req.url ~ "^/flv/.*" || req.url ~ "^/images.(128|320)/.*" ) {
      set req.backend = media;
   }

   if ( req.url ~ "^/media.hq.flv/.*" ) {
      pipe;
   }

   if ( req.url ~ "^/emit/.*" ) {
      set req.backend = default;
      pipe;
   }

   if (req.http.Cache-Control ~ "no-cache") {
    pass;
   }

 #if comment out lookup keyword varnish start to handle requests wierdly
 #lookup
 }

And here is my vcl_fetch(not sure that it intended in this issue):
sub vcl_fetch {
 if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~
"no-cache" || obj.http.Cache-Control ~ "private") {
   pass;
 }

 if (! req.http.X-Cacheable ~ "true" ) {
   set obj.http.Cache-Control = "no-cache";
   set obj.http.Expires = "Tue, 01 Jan 2000 00:00:01 GMT";
   pass;
 }

 set obj.ttl = 3600s;

}

I suppose that there is some error in vlc_ subs, but they seems ok.

-- 
Sergei Kononov


From sergei.kononov at gmail.com  Wed Mar 25 13:19:46 2009
From: sergei.kononov at gmail.com (Sergei Kononov)
Date: Wed, 25 Mar 2009 16:19:46 +0300
Subject: Weird backend selection policy
In-Reply-To: <c0f4783e0903250540o2e46e37t5254108a41d9b575@mail.gmail.com>
References: <c0f4783e0903250540o2e46e37t5254108a41d9b575@mail.gmail.com>
Message-ID: <c0f4783e0903250619q4f356a39p5322cc36cd6b3318@mail.gmail.com>

Update: removing lookup does not fix this issue at all.

b2 - is a round-robin director with 8 backends specified
rpc - is simple backend, as media

The problem really look like that all the available backends is in
round-robin, request to rpc partially goes to b2 backends and vice
versa. The most strange happened with logs, requests which goes to
wrong backend can't be found neither in varnishncsa.log, nor
varnishlog.

Even running varnishlog -i RxURL,Backend (with out to terminal) does
not show any false backends routes, but clients sees 404 and 500 for
request.

Really, really strange behavior.

On Wed, Mar 25, 2009 at 3:40 PM, Sergei Kononov
<sergei.kononov at gmail.com> wrote:
> Hi,
>
> I noticed weird behavior of backend selection. Some request goes to
> backend which is not suitable for them, as result I getting 404 or 500
> errors, but I noticed that removing "lookup" in end of vcl_recv can
> fix that problem, at least this problem does not occur so frequently
> after that.
>
> Here is my vcl_recv:
>
> sub vcl_recv {
> ? set req.http.X-Cacheable = "true";
> ? set req.http.X-Forwarded-For=client.ip;
> ? set req.backend = default;
>
> ? if ( req.url ~ "^/api/.*" ) {
> ? ? ?set req.backend = b2;
> ? ? ?set req.url = regsub(req.url, "^/api/", "/")
> ? ? ?set req.http.X-Cacheable = "false";
> ? ? ?pipe;
> ? }
>
> ? if ( req.url ~ "^/rpc.*" ) {
> ? ? ?set req.backend = rpc;
> ? ? ?set req.http.X-Cacheable = "false";
> ? ? ?pipe;
> ? }
>
> ? if ( req.url ~ "^/flv/.*" || req.url ~ "^/images.(128|320)/.*" ) {
> ? ? ?set req.backend = media;
> ? }
>
> ? if ( req.url ~ "^/media.hq.flv/.*" ) {
> ? ? ?pipe;
> ? }
>
> ? if ( req.url ~ "^/emit/.*" ) {
> ? ? ?set req.backend = default;
> ? ? ?pipe;
> ? }
>
> ? if (req.http.Cache-Control ~ "no-cache") {
> ? ?pass;
> ? }
>
> ?#if comment out lookup keyword varnish start to handle requests wierdly
> ?#lookup
> ?}
>
> And here is my vcl_fetch(not sure that it intended in this issue):
> sub vcl_fetch {
> ?if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~
> "no-cache" || obj.http.Cache-Control ~ "private") {
> ? pass;
> ?}
>
> ?if (! req.http.X-Cacheable ~ "true" ) {
> ? set obj.http.Cache-Control = "no-cache";
> ? set obj.http.Expires = "Tue, 01 Jan 2000 00:00:01 GMT";
> ? pass;
> ?}
>
> ?set obj.ttl = 3600s;
>
> }
>
> I suppose that there is some error in vlc_ subs, but they seems ok.
>
> --
> Sergei Kononov
>



-- 
Sergei Kononov


From sergei.kononov at gmail.com  Wed Mar 25 16:14:45 2009
From: sergei.kononov at gmail.com (Sergei Kononov)
Date: Wed, 25 Mar 2009 19:14:45 +0300
Subject: Weird backend selection policy
In-Reply-To: <c0f4783e0903250619q4f356a39p5322cc36cd6b3318@mail.gmail.com>
References: <c0f4783e0903250540o2e46e37t5254108a41d9b575@mail.gmail.com>
	<c0f4783e0903250619q4f356a39p5322cc36cd6b3318@mail.gmail.com>
Message-ID: <c0f4783e0903250914p6df70909k31c0176ea7948f7@mail.gmail.com>

Update:

Well, I spent almost whole day to figure out why this problem happend.
As I mentioned earlier the most strange thing is missing log entries
for 404 in varnishlog (but they are seen in tcpdump). I tried few
modifications to vcl_recv and noticed that if remove "pipe" from:
if ( req.url ~ "^/api/.*" ) {
     set req.backend = b2;
     set req.url = regsub(req.url, "^/api/", "/")
     set req.http.X-Cacheable = "false";
     pipe; # ---> remove it
  }

Everything start to working fine. It's really strange behavior and
almost unpredictable. I suppose there is some bug in parsing of VCL or
something related to vcl anyway.

On Wed, Mar 25, 2009 at 4:19 PM, Sergei Kononov
<sergei.kononov at gmail.com> wrote:
> Update: removing lookup does not fix this issue at all.
>
> b2 - is a round-robin director with 8 backends specified
> rpc - is simple backend, as media
>
> The problem really look like that all the available backends is in
> round-robin, request to rpc partially goes to b2 backends and vice
> versa. The most strange happened with logs, requests which goes to
> wrong backend can't be found neither in varnishncsa.log, nor
> varnishlog.
>
> Even running varnishlog -i RxURL,Backend (with out to terminal) does
> not show any false backends routes, but clients sees 404 and 500 for
> request.
>
> Really, really strange behavior.
>
> On Wed, Mar 25, 2009 at 3:40 PM, Sergei Kononov
> <sergei.kononov at gmail.com> wrote:
>> Hi,
>>
>> I noticed weird behavior of backend selection. Some request goes to
>> backend which is not suitable for them, as result I getting 404 or 500
>> errors, but I noticed that removing "lookup" in end of vcl_recv can
>> fix that problem, at least this problem does not occur so frequently
>> after that.
>>
>> Here is my vcl_recv:
>>
>> sub vcl_recv {
>> ? set req.http.X-Cacheable = "true";
>> ? set req.http.X-Forwarded-For=client.ip;
>> ? set req.backend = default;
>>
>> ? if ( req.url ~ "^/api/.*" ) {
>> ? ? ?set req.backend = b2;
>> ? ? ?set req.url = regsub(req.url, "^/api/", "/")
>> ? ? ?set req.http.X-Cacheable = "false";
>> ? ? ?pipe;
>> ? }
>>
>> ? if ( req.url ~ "^/rpc.*" ) {
>> ? ? ?set req.backend = rpc;
>> ? ? ?set req.http.X-Cacheable = "false";
>> ? ? ?pipe;
>> ? }
>>
>> ? if ( req.url ~ "^/flv/.*" || req.url ~ "^/images.(128|320)/.*" ) {
>> ? ? ?set req.backend = media;
>> ? }
>>
>> ? if ( req.url ~ "^/media.hq.flv/.*" ) {
>> ? ? ?pipe;
>> ? }
>>
>> ? if ( req.url ~ "^/emit/.*" ) {
>> ? ? ?set req.backend = default;
>> ? ? ?pipe;
>> ? }
>>
>> ? if (req.http.Cache-Control ~ "no-cache") {
>> ? ?pass;
>> ? }
>>
>> ?#if comment out lookup keyword varnish start to handle requests wierdly
>> ?#lookup
>> ?}
>>
>> And here is my vcl_fetch(not sure that it intended in this issue):
>> sub vcl_fetch {
>> ?if (obj.http.Pragma ~ "no-cache" || obj.http.Cache-Control ~
>> "no-cache" || obj.http.Cache-Control ~ "private") {
>> ? pass;
>> ?}
>>
>> ?if (! req.http.X-Cacheable ~ "true" ) {
>> ? set obj.http.Cache-Control = "no-cache";
>> ? set obj.http.Expires = "Tue, 01 Jan 2000 00:00:01 GMT";
>> ? pass;
>> ?}
>>
>> ?set obj.ttl = 3600s;
>>
>> }
>>
>> I suppose that there is some error in vlc_ subs, but they seems ok.
>>
>> --
>> Sergei Kononov
>>
>
>
>
> --
> Sergei Kononov
>



-- 
Sergei Kononov


From tnguyen at bleacherreport.com  Wed Mar 25 17:37:52 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Wed, 25 Mar 2009 10:37:52 -0700
Subject: varnishd runtime parameters
In-Reply-To: <20090324072050.GA17483@kjeks.linpro.no>
References: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>
	<20090324072050.GA17483@kjeks.linpro.no>
Message-ID: <ca6364050903251037q421fa124lfe83c53c43461c5e@mail.gmail.com>

Kristian, thank you.

Im glad to hear that most defaults are good.

Yup, the default thread_pool_min = 1 seems kinda funny.  We'll set it to at
least 100.

I didnt even know about the cli_timeout and will set it to a base line of 10
seconds to test.

Im wondering how you are testing, Im using ab, apachebench, to see how
things behave with -c 10 -n 1000, on the varnished pages.





Here's more specific questions more run time parameters.  The general
question I have is what to look for during testing, should I be looking at
your varnishstat and are the most important things to look for in that
output.


Our varnish stack will look like this:

LB -> Varnish x 2 -> Nginx x 6 -> Mongrel x 60

Some questions about how best to decide how to configure them best to
configure the run time parameters.

-p obj_workspace=4096
Cant find obj_workspace in the man page but found it in the twitter email
post
http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html

Is obj_workspace how much space preallocated to be used for the obj that
gets returned from the backend?  So, if my nginx backend returns a web page
that is over 4MB than -p obj_workspace is not enough, would that crash
varnish, or log the error somewhere.

-p sess_workspace=262144
Same deal here with the man page and twitter post.
What is the sess_workspace?

http_workspace
How does sess_workspace and obj_workspace relate to http_workspace?
If we use obj_workspace=4096 and sess_workspace=262144, does the default
http_workspace=8192 make sense?


-p lru_interval=60
Shows up on the twitter post again, but no man notes yet.  Whats the default
for this?

-p sess_timeout=10 \
Default for this is 5.  If the requests from the backend takes longer than 5
seconds, what happens?  Sometimes we have really slow response from the
backend..

-p shm_workspace=32768 \
Is this the same as setting the command line flag -l shmlogsize.  The
default is 80MB.  So dont know twitter did both setting it to less..

-p thread_pools=4 \
-p thread_pool_min=100 \
thread_pool_max
The defaults are 1,1,1000 respectively.  Im wondering how best to determine
this or just leave as default.





######################################################################
# output of varnishstat, what is best to look at here?
######################################################################
0+07:11:24
                                          Hitrate ratio:        4        4
     4
Hitrate avg:        nan      nan      nan

         400         0.00         0.02 Client connections accepted
         400         0.00         0.02 Client requests received
           1         0.00         0.00 Cache hits
           5         0.00         0.00 Cache misses
         399         0.00         0.02 Backend connections success
         399         0.00         0.02 Backend connections failures
           1         0.00         0.00 Backend connections reuses
           5         0.00         0.00 Backend connections recycles
           6          .            .   N struct srcaddr
          21          .            .   N struct sess_mem
           1          .            .   N struct sess
           1          .            .   N struct object
           1          .            .   N struct objecthead
           3          .            .   N struct smf
           1          .            .   N small free smf
           1          .            .   N large free smf
           1          .            .   N struct vbe_conn
           2          .            .   N struct bereq
          10          .            .   N worker threads
          23         0.00         0.00 N worker threads created
          76         0.00         0.00 N overflowed work requests
           2          .            .   N backends
           5          .            .   N expired objects
           6         0.00         0.00 Objects sent with write
         400         0.00         0.02 Total Sessions
         400         0.00         0.02 Total Requests
         394         0.00         0.02 Total pipe
           5         0.00         0.00 Total fetch
      352131         0.00        13.60 Total header bytes
        1745         0.00         0.07 Total body bytes
         397         0.00         0.02 Session Closed
           3         0.00         0.00 Session herd
       33185         2.00         1.28 SHM records
       19306         2.00         0.75 SHM writes
          32         0.00         0.00 SHM MTX contention
          11         0.00         0.00 allocator requests
           1          .            .   outstanding allocations
        8192          .            .   bytes allocated
  6612459520          .            .   bytes free
           5         0.00         0.00 Backend requests made
           1         0.00         0.00 N vcl total
           1         0.00         0.00 N vcl available
           1          .            .   N total active purges
           1         0.00         0.00 N new purges added







Any response is appreciated.

Thanks,
Tung










On Tue, Mar 24, 2009 at 12:20 AM, Kristian Lyngstol <
kristian at redpill-linpro.com> wrote:

> On Mon, Mar 23, 2009 at 05:58:58PM -0700, Tung Nguyen wrote:
> > Hi guys,
> > So, Im reading over an archive email thread about twitters configuration.
> >
> >
> http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html
> >
> > It looks like they had to adjust a lot of parameters... and Im not
> finding
> > all the parameters definitions in the varnishd man pages.  Im wondering
> if
> > for most cases running varnish with the defaults is fine?
> >
> > Any caveats here which run time parameters should I focus on.
>
> You can mostly run it with the defaults, yes. This depends on what sort of
> usage you have though.
>
> One notable exception is that I strongly recommend that you bring
> thread_pool_min up to a decent level (reflecting how many users you
> actually have. Numbers in the hundreds is normal). You'll also want to
> adjust the cache size to your system, but that goes without saying.
>
> If you expect extremely high load, you might have to increase cli_timeout
> too. I've run tests where even setting it to 15 seconds is insufficient and
> causes childs to be killed off. Though for most production sites, I'd guess
> 5 seconds could work and 10 seconds would definitely work.
>
> --
> Kristian Lyngst?l
> Redpill Linpro AS
> Tlf: +47 21544179
> Mob: +47 99014497
>



-- 
Tung Nguyen, Lead Developer
Bleacher Report, The Open Source Sports Network
(510) 928-0475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090325/3ed3ebb6/attachment.html>

From tnguyen at bleacherreport.com  Wed Mar 25 18:49:10 2009
From: tnguyen at bleacherreport.com (Tung Nguyen)
Date: Wed, 25 Mar 2009 11:49:10 -0700
Subject: varnishd runtime parameters
In-Reply-To: <ca6364050903251037q421fa124lfe83c53c43461c5e@mail.gmail.com>
References: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>
	<20090324072050.GA17483@kjeks.linpro.no>
	<ca6364050903251037q421fa124lfe83c53c43461c5e@mail.gmail.com>
Message-ID: <ca6364050903251149n2499ad44y67eb0771d6fef250@mail.gmail.com>

Hi guys,

So sometimes are backend is really slow in returning a response.  So
slow that it looks like it
is causing varnish to timeout before the backend does and so varnish
seems to eventually give up
and returns a 503.

Ther are 4 curl requests
* the first 2 timeout and give a 503
* the 3rd one is a hit miss but gives a 200
* the 4th one is a cache hit and gives a 200

https://gist.github.com/0452c374ee21dbba138d

Here's the varnishlog filtered for client requests

http://gist.github.com/279254e0f2452814bf46

Here's varnishstat

https://gist.github.com/219534d51a503b546070

Here's are current startup run time parameters options right now:

https://gist.github.com/219534d51a503b546070

So, Im pretty certain what is happening is that our backend takes too
long and varnish times
out.  How can I set the time out higher... is it sess_timeout?

Thanks guys,
Tung


On Wed, Mar 25, 2009 at 10:37 AM, Tung Nguyen <tnguyen at bleacherreport.com>wrote:

> Kristian, thank you.
>
> Im glad to hear that most defaults are good.
>
> Yup, the default thread_pool_min = 1 seems kinda funny.  We'll set it to at
> least 100.
>
> I didnt even know about the cli_timeout and will set it to a base line of
> 10 seconds to test.
>
> Im wondering how you are testing, Im using ab, apachebench, to see how
> things behave with -c 10 -n 1000, on the varnished pages.
>
>
>
>
>
> Here's more specific questions more run time parameters.  The general
> question I have is what to look for during testing, should I be looking at
> your varnishstat and are the most important things to look for in that
> output.
>
>
> Our varnish stack will look like this:
>
> LB -> Varnish x 2 -> Nginx x 6 -> Mongrel x 60
>
> Some questions about how best to decide how to configure them best to
> configure the run time parameters.
>
> -p obj_workspace=4096
> Cant find obj_workspace in the man page but found it in the twitter email
> post
> http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html
>
> Is obj_workspace how much space preallocated to be used for the obj that
> gets returned from the backend?  So, if my nginx backend returns a web page
> that is over 4MB than -p obj_workspace is not enough, would that crash
> varnish, or log the error somewhere.
>
> -p sess_workspace=262144
> Same deal here with the man page and twitter post.
> What is the sess_workspace?
>
> http_workspace
> How does sess_workspace and obj_workspace relate to http_workspace?
> If we use obj_workspace=4096 and sess_workspace=262144, does the default
> http_workspace=8192 make sense?
>
>
> -p lru_interval=60
> Shows up on the twitter post again, but no man notes yet.  Whats the
> default for this?
>
> -p sess_timeout=10 \
> Default for this is 5.  If the requests from the backend takes longer than
> 5 seconds, what happens?  Sometimes we have really slow response from the
> backend..
>
> -p shm_workspace=32768 \
> Is this the same as setting the command line flag -l shmlogsize.  The
> default is 80MB.  So dont know twitter did both setting it to less..
>
> -p thread_pools=4 \
> -p thread_pool_min=100 \
> thread_pool_max
> The defaults are 1,1,1000 respectively.  Im wondering how best to determine
> this or just leave as default.
>
>
>
>
>
> ######################################################################
> # output of varnishstat, what is best to look at here?
> ######################################################################
> 0+07:11:24
>                                             Hitrate ratio:        4        4
>        4
> Hitrate avg:        nan      nan      nan
>
>          400         0.00         0.02 Client connections accepted
>          400         0.00         0.02 Client requests received
>            1         0.00         0.00 Cache hits
>            5         0.00         0.00 Cache misses
>          399         0.00         0.02 Backend connections success
>          399         0.00         0.02 Backend connections failures
>            1         0.00         0.00 Backend connections reuses
>            5         0.00         0.00 Backend connections recycles
>            6          .            .   N struct srcaddr
>           21          .            .   N struct sess_mem
>            1          .            .   N struct sess
>            1          .            .   N struct object
>            1          .            .   N struct objecthead
>            3          .            .   N struct smf
>            1          .            .   N small free smf
>            1          .            .   N large free smf
>            1          .            .   N struct vbe_conn
>            2          .            .   N struct bereq
>           10          .            .   N worker threads
>           23         0.00         0.00 N worker threads created
>           76         0.00         0.00 N overflowed work requests
>            2          .            .   N backends
>            5          .            .   N expired objects
>            6         0.00         0.00 Objects sent with write
>          400         0.00         0.02 Total Sessions
>          400         0.00         0.02 Total Requests
>          394         0.00         0.02 Total pipe
>            5         0.00         0.00 Total fetch
>       352131         0.00        13.60 Total header bytes
>         1745         0.00         0.07 Total body bytes
>          397         0.00         0.02 Session Closed
>            3         0.00         0.00 Session herd
>        33185         2.00         1.28 SHM records
>        19306         2.00         0.75 SHM writes
>           32         0.00         0.00 SHM MTX contention
>           11         0.00         0.00 allocator requests
>            1          .            .   outstanding allocations
>         8192          .            .   bytes allocated
>   6612459520          .            .   bytes free
>            5         0.00         0.00 Backend requests made
>            1         0.00         0.00 N vcl total
>            1         0.00         0.00 N vcl available
>            1          .            .   N total active purges
>            1         0.00         0.00 N new purges added
>
>
>
>
>
>
>
> Any response is appreciated.
>
> Thanks,
> Tung
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 24, 2009 at 12:20 AM, Kristian Lyngstol <
> kristian at redpill-linpro.com> wrote:
>
>> On Mon, Mar 23, 2009 at 05:58:58PM -0700, Tung Nguyen wrote:
>> > Hi guys,
>> > So, Im reading over an archive email thread about twitters
>> configuration.
>> >
>> >
>> http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html
>> >
>> > It looks like they had to adjust a lot of parameters... and Im not
>> finding
>> > all the parameters definitions in the varnishd man pages.  Im wondering
>> if
>> > for most cases running varnish with the defaults is fine?
>> >
>> > Any caveats here which run time parameters should I focus on.
>>
>> You can mostly run it with the defaults, yes. This depends on what sort of
>> usage you have though.
>>
>> One notable exception is that I strongly recommend that you bring
>> thread_pool_min up to a decent level (reflecting how many users you
>> actually have. Numbers in the hundreds is normal). You'll also want to
>> adjust the cache size to your system, but that goes without saying.
>>
>> If you expect extremely high load, you might have to increase cli_timeout
>> too. I've run tests where even setting it to 15 seconds is insufficient
>> and
>> causes childs to be killed off. Though for most production sites, I'd
>> guess
>> 5 seconds could work and 10 seconds would definitely work.
>>
>> --
>> Kristian Lyngst?l
>> Redpill Linpro AS
>> Tlf: +47 21544179
>> Mob: +47 99014497
>>
>
>
>
> --
> Tung Nguyen, Lead Developer
> Bleacher Report, The Open Source Sports Network
> (510) 928-0475
>



-- 
Tung Nguyen, Lead Developer
Bleacher Report, The Open Source Sports Network
(510) 928-0475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090325/2cbc6565/attachment.html>

From kristian at redpill-linpro.com  Wed Mar 25 19:03:20 2009
From: kristian at redpill-linpro.com (Kristian Lyngstol)
Date: Wed, 25 Mar 2009 20:03:20 +0100
Subject: varnishd runtime parameters
In-Reply-To: <ca6364050903251037q421fa124lfe83c53c43461c5e@mail.gmail.com>
References: <ca6364050903231758x68b863d6kb00be22318b41954@mail.gmail.com>
	<20090324072050.GA17483@kjeks.linpro.no>
	<ca6364050903251037q421fa124lfe83c53c43461c5e@mail.gmail.com>
Message-ID: <20090325190320.GA11568@kjeks.lyngstol.int>

On Wed, Mar 25, 2009 at 10:37:52AM -0700, Tung Nguyen wrote:
> Im wondering how you are testing, Im using ab, apachebench, to see how
> things behave with -c 10 -n 1000, on the varnished pages.

I've got two ways of testing. One is with siege, typically run with siege
-c200 -b. Siege, however, is a little unreliable so I reserve that for test
that I actively monitor.

For stress testing trunk we've got a small script suite to run httperf
for a few hours against Varnish under both FreeBSD and Linux. This test is
split in two: All cold hits (fill the cache, start fetching objects that
are swapped out) and all hot hits (constantly hit the same tiny pages).
During the development of the hot hit tests it became apparent that the
default cli_timeout of 5 seconds was very insufficient. At 10 seconds it
would _mostly_ work, but even at 15 seconds the clients would occasionally
not respond in time, and thus get killed. The rig has been running with a
cli_timeout of 23 for the past few months without issue. 

It should be noted that this is an extreme case that is very unlikely to
happen in a production environment due to the nature of a network.

All in all, however, I much prefer siege for short-lived and specific
tests. 

It's also important to remember that stress testing varnish like this is
unlikely to reveal the most likely problems faced in Varnish deployment.
The most common problem is not the raw performance, but the interaction
between varnish and the backends with regards to what's cacheable and not.
And if the server has enough memory / disk. (Using disk is extremely slow,
but might make sense in some situations).

> Here's more specific questions more run time parameters.  The general
> question I have is what to look for during testing, should I be looking at
> your varnishstat and are the most important things to look for in that
> output.

Hit rate, hit rate and hit rate. Then look at overflowed requests, and make
sure dropped requests are always 0. Making sure backend_failures are under
control is also important.

But this has to be adjusted to what sort of traffic you're serving and what
sort of request rate you have.

> Our varnish stack will look like this:
> 
> LB -> Varnish x 2 -> Nginx x 6 -> Mongrel x 60
> 
> Some questions about how best to decide how to configure them best to
> configure the run time parameters.
> 
> -p obj_workspace=4096
> Cant find obj_workspace in the man page but found it in the twitter email
> post
> http://projects.linpro.no/pipermail/varnish-dev/2009-February/000968.html

Should be in the man page too, but it's documented if you telnet to the
management interface:

param.show obj_workspace
200 573     
obj_workspace              8192 [bytes]
                           Default is 8192
                           Bytes of HTTP protocol workspace allocated for
                           objects. This space must be big enough for the
			   entire HTTP protocol header and any edits done to
                           it in the VCL code while it is cached.
                           Minimum is 1024 bytes.

> Is obj_workspace how much space preallocated to be used for the obj that
> gets returned from the backend?  So, if my nginx backend returns a web page
> that is over 4MB than -p obj_workspace is not enough, would that crash
> varnish, or log the error somewhere.

No, it's just for the headers from your backend + whatever you do to it in
VCL. The actual object can be as large as needed.

> -p sess_workspace=262144
> Same deal here with the man page and twitter post.
> What is the sess_workspace?

Same as obj_workspace but for headers from a client if memory serves me
right.

> http_workspace
> How does sess_workspace and obj_workspace relate to http_workspace?
> If we use obj_workspace=4096 and sess_workspace=262144, does the default
> http_workspace=8192 make sense?

http_workspace doesn't exist in Varnish 2.x

> -p lru_interval=60
> Shows up on the twitter post again, but no man notes yet.  Whats the default
> for this?

... This man page really needs to be updated. The documentation is
available in the management interface.

param.show lru_interval
200 783     
lru_interval               2 [seconds]
                           Default is 2
                           Grace period before object moves on LRU list.
                           Objects are only moved to the front of the LRU
                           list if they have not been moved there already
                           inside this timeout period.  This reduces the
                           amount of lock operations necessary for LRU list
                           access.

> -p sess_timeout=10 \
> Default for this is 5.  If the requests from the backend takes longer than 5
> seconds, what happens?  Sometimes we have really slow response from the
> backend..

This isn't for backends. It's for client requests. So if a client doesn't
do anything in 5 (or 10 seconds), it's disconnected.

> -p shm_workspace=32768 \
> Is this the same as setting the command line flag -l shmlogsize.  The
> default is 80MB.  So dont know twitter did both setting it to less..

Eh, never had a problem with this myself, but I'm not twitter.

> -p thread_pools=4 \
> -p thread_pool_min=100 \
> thread_pool_max
> The defaults are 1,1,1000 respectively.  Im wondering how best to determine
> this or just leave as default.

You're definitely not using Varnish 2. Upgrade.

Increasing the number of thread pools might be necessary if you have
extreme traffic. Threads should be set to how many concurrent connections
you expect normally. Just keep in mind that thread_pool_min * thread_pools
is the amount of threads started. Starting a thousand threads isn't a bad
idea. 

(Considered commercial support? This is getting pretty extensive.)

-- 
Kristian Lyngst?l
Redpill Linpro AS
Tlf: +47 21544179
Mob: +47 99014497
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090325/b7776260/attachment.bin>

From harald at webmeisterei.com  Thu Mar 26 18:37:45 2009
From: harald at webmeisterei.com (Harald Friessnegger)
Date: Thu, 26 Mar 2009 19:37:45 +0100
Subject: make varnish don't start a subprocess
In-Reply-To: <86vdpylx4f.fsf@ds4.des.no>
References: <200903201029.41499.harald@webmeisterei.com>
	<200903241613.55858.harald@webmeisterei.com>
	<86vdpylx4f.fsf@ds4.des.no>
Message-ID: <200903261937.45839.harald@webmeisterei.com>

hi des

thanks for your reply.

in order to get an idea how to optimize my setup and get a better 
understanding i'd like to recap to make sure i understood correctly: 

Am Dienstag, 24. M?rz 2009 17:10:56 schrieb Dag-Erling Sm?rgrav:
> If you're using a storage file, varnishd will use a relatively small
> amount of memory + address space roughly equal to the size of the file.


-s file,"/home/zope/parts/varnish/storage",500M 
will make the varnishd use around 750M RAM (see my comment on the next block), 
a storage file with 700M will result in around 950M RAM used.


if that address space needs roughly the same amout of RAM as the storage 
file's size - and the cache is not persisted (lost when varnishd is 
restarted) - why do we need a storage file at all?


> > whilst the file itself is exactly 500 megabyte in size, varnish
> > uses 1115M memory - 44% of the total available 2,5GB RAM (1,5GB RAM, 1GB
> > disk-swap) after 5 days of uptime. see `figure 1` below.
>
> It's not that simple.  The file is mapped into varnishd's address space,
> so the VIRT number you get from top includes the size of the file (as
> well as the size of the program itself and all libraries it uses).  RES
> is how much of that is actually in RAM.  The OS may swap unused parts of
> the cache to the storage file, but never to the swap partition.

using the sizes given in the RES column varnish uses 673+81=754M RAM::

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1344 nobody    15   0 1349m 673m 133m S    0 44.5   0:08.38 varnishd
 1244 zope      15   0  637m 461m 3428 S    0 30.5  40:41.93 python2.4
 1245 root      15   0 98196  81m  81m S    0  5.4   0:00.02 varnishd

so the "relatively small amount of ram" varnish uses in addition to the 
address space is about 200M.

are these usual numbers?



> You should probably look at /proc/$pid/map instead of using top, BTW.

i tried out /proc/$pid/maps but did not really succeed in calculating memory 
usage out of the address blocks (i think this is what needs to be done here?)
this is an example from the manpage http://linux.die.net/man/5/proc

  address           perms offset  dev   inode      pathname
  08048000-08056000 r-xp 00000000 03:0c 64593      /usr/sbin/gpm
  08056000-08058000 rw-p 0000d000 03:0c 64593      /usr/sbin/gpm

probably the RES column in top is enough to get an idea how much RAM is 
consumed by a process.




regards, harald


-- 
Webmeisterei GmbH - B?ro f?r Netzfragen
Tel: +43 5572 908877, ?Fax: +43 5572 908877-66
Steinebach 18, A-6850 Dornbirn

http://www.webmeisterei.com


From iiminar at gmail.com  Thu Mar 26 21:35:18 2009
From: iiminar at gmail.com (Igor Minar)
Date: Thu, 26 Mar 2009 14:35:18 -0700
Subject: Intermittent latency issues on Solaris10
In-Reply-To: <49C01061.5000908@zill.net>
References: <B5920F03-9817-4FC2-B5EA-ADBA917D5002@gmail.com>
	<49C01061.5000908@zill.net>
Message-ID: <812A746F-B60E-42AF-A673-385DF85B47E0@gmail.com>


On Mar 17, 2009, at 2:04 PM, Patrick Giagnocavo wrote:

> Igor Minar wrote:
>> Hi Folks!
>>
>> I'm trying set up a Varnish instance on Solaris 10 and I'm facing  
>> some
>> weird issue there. I was wondering if anyone could give me some
>> insight into what's going on.
>>
>> After applying a few patches (I submited all of them to Trac), I was
>> able compile Varnish 2.0.2 and 2.0.3 with Sun Studio compiler.  
>> Varnish
>> starts and is able to handle requests, but from time to time, I see
>> multi-second latency when executing requests. As if varnish "hung"  
>> for
>> a few seconds. This latency occurs for cache hits and is not caused  
>> by
>> the backed app.
>
> You should look into using DTrace to figure out what is going on.   
> Do a
> search on dtrace at blogs.sun.com, there are many useful scripts and
> snippets of dtrace code there.
>
> --Patrick

I tried truss and dtrace but I don't see anything suspicious.

However what I did notice was an occurrence of "SessionClose c  
timeout" in varnishlog just before every stalled response:

     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1238102801 1.0
     0 CLI          - Rd ping
     0 CLI          - Wr 0 200 PONG 1238102804 1.0
    11 SessionClose c timeout
    11 StatSess     c 192.18.43.225 43205 0 1 2 0 0 0 814 677
     8 SessionClose c timeout
     8 StatSess     c 192.18.43.225 54410 0 1 3 0 0 0 1221 1275
     4 SessionClose c timeout
     4 StatSess     c 192.18.43.225 9008 3 1 5 0 0 1 2310 45105
     9 SessionClose c timeout
     9 StatSess     c 192.18.43.225 45298 0 1 3 0 0 0 1304 1986
     4 SessionOpen  c 192.18.43.225 13094 0.0.0.0:8080
     4 ReqStart     c 192.18.43.225 13094 1500381747
     4 RxRequest    c GET

Does anyone know what this means and what I can do to get rid of it?

thanks,
Igor




From suran007 at sina.com  Fri Mar 27 05:28:01 2009
From: suran007 at sina.com (suran007 at sina.com)
Date: Fri, 27 Mar 2009 13:28:01 +0800 
Subject: How to let varnishncsa to log the realserver ip
Message-ID: <20090327052801.E88C2A49806@mail3-51.sinamail.sina.com.cn>

&nbsp;hello!
&nbsp;I have a questtion, that is How to let varnishncsa log the backend realserver ip to varnish.log?I search in google,but no result,anyone can help me ?
&nbsp;thanks!!

???????????????????

-------------------------------------------------------------------
???????????????????(http://space.sina.com.cn/ )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090327/a353db37/attachment.html>

From ssm at redpill-linpro.com  Thu Mar 26 10:10:31 2009
From: ssm at redpill-linpro.com (Stig Sandbeck Mathisen)
Date: Thu, 26 Mar 2009 11:10:31 +0100
Subject: Weird backend selection policy
In-Reply-To: <c0f4783e0903250914p6df70909k31c0176ea7948f7@mail.gmail.com>
References: <c0f4783e0903250540o2e46e37t5254108a41d9b575@mail.gmail.com>
	<c0f4783e0903250619q4f356a39p5322cc36cd6b3318@mail.gmail.com>
	<c0f4783e0903250914p6df70909k31c0176ea7948f7@mail.gmail.com>
Message-ID: <20090326101031.GA25003@redpill-linpro.com>

On Wed, Mar 25, 2009 at 07:14:45PM +0300, Sergei Kononov wrote:
> Update:
> 
> Well, I spent almost whole day to figure out why this problem happend.  As I
> mentioned earlier the most strange thing is missing log entries for 404 in
> varnishlog (but they are seen in tcpdump). I tried few modifications to
> vcl_recv and noticed that if remove "pipe" from:
> if ( req.url ~ "^/api/.*" ) {
>      set req.backend = b2;
>      set req.url = regsub(req.url, "^/api/", "/")
>      set req.http.X-Cacheable = "false";
>      pipe; # ---> remove it
>   }
> 
> Everything start to working fine. It's really strange behavior and
> almost unpredictable. I suppose there is some bug in parsing of VCL or
> something related to vcl anyway.

The "pipe" makes all subsequent requests on the same TCP connection go to the
same backend unaltered.  When you use "pipe", it's just a stream of bytes
between the client and the backend.  Add:

sub vcl_pipe {
  set req.http.connection = "close";
}

A comment have been added to sub vcl_pipe in the default VCL in trunk regarding
this issue, see around line 64 in:
http://varnish.projects.linpro.no/browser/trunk/varnish-cache/bin/varnishd/default.vcl

-- 
Stig Sandbeck Mathisen
Senior systemadministrator, leder faggruppe nettverk
Redpill Linpro AS - Changing the Game
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090326/fc80666e/attachment.bin>

From itlj at gyldendal.dk  Fri Mar 27 13:12:59 2009
From: itlj at gyldendal.dk (=?ISO-8859-1?Q?Lars_J=F8rgensen?=)
Date: Fri, 27 Mar 2009 14:12:59 +0100
Subject: Danish characters in vcl_error.
Message-ID: <2A56A311-4F1A-4A07-8F30-0F7A66AB9E74@gyldendal.dk>

Hi,

I'm doing this:

sub vcl_error {
     set obj.http.Content-Type = "text/html; charset=utf-8";
     synthetic {"
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
   <body>
     <h1>Vi arbejder p? systemet </h1>
     <body>
</html>
"};
     return (deliver);

And getting this (omitting DOCTYPE for clarity):

<html>
  <body>
    <h1>Vi arbejder p?77777703?77777645 systemet </h1>
    body>
</html>

What am I doing wrong?


-- 
Lars J?rgensen



From audun at ytterdal.net  Fri Mar 27 13:26:25 2009
From: audun at ytterdal.net (Audun Ytterdal)
Date: Fri, 27 Mar 2009 14:26:25 +0100
Subject: Danish characters in vcl_error.
In-Reply-To: <2A56A311-4F1A-4A07-8F30-0F7A66AB9E74@gyldendal.dk>
References: <2A56A311-4F1A-4A07-8F30-0F7A66AB9E74@gyldendal.dk>
Message-ID: <8318f61f0903270626g136ed466ue8bbc5c42c5053a2@mail.gmail.com>

You have to html-encode the danish characters..

Like this:

   <h1>Beklager, en feil har oppst&aring;tt p&aring; en av VGs tjenester</h1>



On Fri, Mar 27, 2009 at 2:12 PM, Lars J?rgensen <itlj at gyldendal.dk> wrote:
> Hi,
>
> I'm doing this:
>
> sub vcl_error {
> ? ? set obj.http.Content-Type = "text/html; charset=utf-8";
> ? ? synthetic {"
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> ?"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html>
> ? <body>
> ? ? <h1>Vi arbejder p? systemet </h1>
> ? ? <body>
> </html>
> "};
> ? ? return (deliver);
>
> And getting this (omitting DOCTYPE for clarity):
>
> <html>
> ?<body>
> ? ?<h1>Vi arbejder p?77777703?77777645 systemet </h1>
> ? ?body>
> </html>
>
> What am I doing wrong?
>
>
> --
> Lars J?rgensen
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>



-- 
Audun Ytterdal
http://audun.ytterdal.net


From des at des.no  Fri Mar 27 14:44:26 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri, 27 Mar 2009 15:44:26 +0100
Subject: make varnish don't start a subprocess
In-Reply-To: <200903261937.45839.harald@webmeisterei.com> (Harald
	Friessnegger's message of "Thu, 26 Mar 2009 19:37:45 +0100")
References: <200903201029.41499.harald@webmeisterei.com>
	<200903241613.55858.harald@webmeisterei.com>
	<86vdpylx4f.fsf@ds4.des.no>
	<200903261937.45839.harald@webmeisterei.com>
Message-ID: <86fxgznhyt.fsf@ds4.des.no>

Harald Friessnegger <harald at webmeisterei.com> writes:
> if that address space needs roughly the same amout of RAM as the storage 
> file's size - and the cache is not persisted (lost when varnishd is 
> restarted) - why do we need a storage file at all?

Because that's how virtual memory works.

http://www.amazon.com/dp/0136006639

> probably the RES column in top is enough to get an idea how much RAM
> is consumed by a process.

Is it?  AFAIK, if two processes map the same file, it will be counted
twice.  This is the case for shared libraries, for instance, and
multiple instances of the same program.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From tfheen at redpill-linpro.com  Mon Mar 30 11:31:25 2009
From: tfheen at redpill-linpro.com (Tollef Fog Heen)
Date: Mon, 30 Mar 2009 13:31:25 +0200
Subject: "uptime" not available to nagios plugin?
In-Reply-To: <200812311458.42349.ottolski@web.de> (Sascha Ottolski's message
	of "Wed, 31 Dec 2008 14:58:42 +0100")
References: <200812311458.42349.ottolski@web.de>
Message-ID: <87k567uu0i.fsf@qurzaw.linpro.no>

]] Sascha Ottolski 

| bug or feature? The nagios plugin seems not to be able to extract the 
| uptime:

Bug.  Fixed now, thanks.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From tfheen at redpill-linpro.com  Mon Mar 30 11:40:04 2009
From: tfheen at redpill-linpro.com (Tollef Fog Heen)
Date: Mon, 30 Mar 2009 13:40:04 +0200
Subject: Caching ScriptResource.axd files-
In-Reply-To: <FB74E431522B2444838713348ED81F071CE16C@cfmail02.uk.cheapflights.com>
	(Abu Syed Islam's message of "Wed, 18 Mar 2009 17:33:04 -0000")
References: <FB74E431522B2444838713348ED81F071CE16B@cfmail02.uk.cheapflights.com>
	<FB74E431522B2444838713348ED81F071CE16C@cfmail02.uk.cheapflights.com>
Message-ID: <87fxgvutm3.fsf@qurzaw.linpro.no>

]] "Abu Syed Islam" 

| I am very new to Varnish and like to know how I could cache
| ScriptResource.axd files? The browsers making several call to this file
| per http page. But each call to ScriptResource.axd file generates
| different query strings-

Well, I don't know what that .axd file is, but if the content varies
with the query string, you can't really get rid of the query string.
Else, you could do something like

  set req.url = regsub(req.url, "\?.*", "")

in vcl_recv to strip the complete query string.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73


From obeau79 at gmail.com  Mon Mar 30 11:41:40 2009
From: obeau79 at gmail.com (Olivier Beau)
Date: Mon, 30 Mar 2009 13:41:40 +0200
Subject: 2 varnish server "work together" config question
Message-ID: <49D0AFF4.2000903@gmail.com>

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







From jeff at funnyordie.com  Mon Mar 30 19:59:55 2009
From: jeff at funnyordie.com (Jeff Anderson)
Date: Mon, 30 Mar 2009 12:59:55 -0700
Subject: Restart fetches the page but still displays a 503 to client
Message-ID: <07FDA9D3-EFB9-4DB6-BA79-0EAB700FECD9@funnyordie.com>

This client received a 503 even though it looks like the cache restart  
successfully fetched the page from the backend.  Would the 5 discards  
in a row cause the 503 in this thread?  What's happening here in the  
logs?

Thanks,


111 SessionOpen  c 64.12.95.228 5530 :80
   111 ReqStart     c 64.12.95.228 5530 442458545
   111 RxRequest    c GET
   111 RxURL        c /videos/e8afc40df0/happy-halloween-from-kevin- 
masterson-from-kevin-masterson
   111 RxProtocol   c HTTP/1.1
   111 RxHeader     c Connection: close
   111 RxHeader     c Accept: */*
   111 RxHeader     c User-Agent: NSPlayer/9.0.0.3250
   111 RxHeader     c Host: www.funnyordie.com
   111 VCL_call     c recv lookup
   111 VCL_call     c hash hash
   111 VCL_call     c miss fetch
   111 Backend      c 112 cachecluster cachemaster
   111 ObjProtocol  c HTTP/1.1
   111 ObjStatus    c 503
   111 ObjResponse  c Service Unavailable
   111 ObjHeader    c Server: Varnish
   111 ObjHeader    c Retry-After: 0
   111 ObjHeader    c Content-Type: text/html; charset=utf-8
   111 ObjHeader    c Date: Mon, 30 Mar 2009 18:51:50 GMT
   111 ObjHeader    c X-Varnish: 1765034392
   111 ObjHeader    c Via: 1.1 varnish
   111 ObjHeader    c Served-by: web9/(null)
   111 TTL          c 442458545 RFC 120 1238439110 0 0 0 0
   111 VCL_call     c fetch restart
   111 VCL_call     c recv lookup
   111 VCL_call     c hash hash
   111 VCL_call     c miss fetch
   111 Backend      c 112 cachecluster cachemaster
   111 ObjProtocol  c HTTP/1.1
   111 ObjStatus    c 200
   111 ObjResponse  c OK
   111 ObjHeader    c Content-Type: text/html; charset=utf-8
   111 ObjHeader    c X-Runtime: 1941ms
   111 ObjHeader    c ETag: "543372ea478715e48c5a3123b0a05d76"
   111 ObjHeader    c Cache-Control: no-cache, public, max-age=300
   111 ObjHeader    c Server: LiteSpeed
   111 ObjHeader    c Date: Mon, 30 Mar 2009 18:51:52 GMT
   111 ObjHeader    c X-Varnish: 1765034393
   111 ObjHeader    c Via: 1.1 varnish
   111 ObjHeader    c Served-by: web9/app11
   111 VCL_call     c discard discard
   111 VCL_call     c discard discard
   111 VCL_call     c discard discard
   111 VCL_call     c discard discard
   111 VCL_call     c discard discard
   111 TTL          c 442458545 RFC 300 1238439112 0 0 300 0
   111 VCL_call     c fetch deliver
   111 Length       c 136482
   111 VCL_call     c deliver deliver
   111 TxProtocol   c HTTP/1.1
   111 TxStatus     c 200
   111 TxResponse   c OK
   111 TxHeader     c Content-Type: text/html; charset=utf-8
   111 TxHeader     c X-Runtime: 1941ms
   111 TxHeader     c ETag: "543372ea478715e48c5a3123b0a05d76"
   111 TxHeader     c Cache-Control: no-cache, public, max-age=300
   111 TxHeader     c Server: LiteSpeed
   111 TxHeader     c X-Varnish: 1765034393
   111 TxHeader     c Via: 1.1 varnish
   111 TxHeader     c Content-Length: 136482
   111 TxHeader     c Date: Mon, 30 Mar 2009 18:51:52 GMT
   111 TxHeader     c X-Varnish: 442458545
   111 TxHeader     c Age: 0
   111 TxHeader     c Via: 1.1 varnish
   111 TxHeader     c Served-by: web10/web9/app11
   111 TxHeader     c Connection: close
   111 ReqEnd       c 442458545 1238439110.499521971  
1238439112.896286964 0.000036001 2.142404079 0.254360914



--Jeff
jeff at funnyordie.com





From iiminar at gmail.com  Mon Mar 30 20:52:13 2009
From: iiminar at gmail.com (Igor Minar)
Date: Mon, 30 Mar 2009 13:52:13 -0700
Subject: Intermittent latency issues on Solaris10
In-Reply-To: <812A746F-B60E-42AF-A673-385DF85B47E0@gmail.com>
References: <B5920F03-9817-4FC2-B5EA-ADBA917D5002@gmail.com>
	<49C01061.5000908@zill.net>
	<812A746F-B60E-42AF-A673-385DF85B47E0@gmail.com>
Message-ID: <CF5AE825-BF83-4347-9512-8F52236E78F4@gmail.com>


On Mar 26, 2009, at 2:35 PM, Igor Minar wrote:

>
> On Mar 17, 2009, at 2:04 PM, Patrick Giagnocavo wrote:
>
>> Igor Minar wrote:
>>> Hi Folks!
>>>
>>> I'm trying set up a Varnish instance on Solaris 10 and I'm facing  
>>> some
>>> weird issue there. I was wondering if anyone could give me some
>>> insight into what's going on.
>>>
>>> After applying a few patches (I submited all of them to Trac), I was
>>> able compile Varnish 2.0.2 and 2.0.3 with Sun Studio compiler.  
>>> Varnish
>>> starts and is able to handle requests, but from time to time, I see
>>> multi-second latency when executing requests. As if varnish "hung"  
>>> for
>>> a few seconds. This latency occurs for cache hits and is not  
>>> caused by
>>> the backed app.
>>
>> You should look into using DTrace to figure out what is going on.   
>> Do a
>> search on dtrace at blogs.sun.com, there are many useful scripts and
>> snippets of dtrace code there.
>>
>> --Patrick
>
> I tried truss and dtrace but I don't see anything suspicious.
>
> However what I did notice was an occurrence of "SessionClose c  
> timeout" in varnishlog just before every stalled response:
>
>    0 CLI          - Rd ping
>    0 CLI          - Wr 0 200 PONG 1238102801 1.0
>    0 CLI          - Rd ping
>    0 CLI          - Wr 0 200 PONG 1238102804 1.0
>   11 SessionClose c timeout
>   11 StatSess     c 192.18.43.225 43205 0 1 2 0 0 0 814 677
>    8 SessionClose c timeout
>    8 StatSess     c 192.18.43.225 54410 0 1 3 0 0 0 1221 1275
>    4 SessionClose c timeout
>    4 StatSess     c 192.18.43.225 9008 3 1 5 0 0 1 2310 45105
>    9 SessionClose c timeout
>    9 StatSess     c 192.18.43.225 45298 0 1 3 0 0 0 1304 1986
>    4 SessionOpen  c 192.18.43.225 13094 0.0.0.0:8080
>    4 ReqStart     c 192.18.43.225 13094 1500381747
>    4 RxRequest    c GET
>
> Does anyone know what this means and what I can do to get rid of it?

Any hits as to what could be causing the timeouts? The backend is  
definitely not timing out, but even if it was, it shouldn't matter for  
cache hit requests.

thanks,
Igor


From on at cs.ait.ac.th  Tue Mar 31 03:21:34 2009
From: on at cs.ait.ac.th (Olivier Nicole)
Date: Tue, 31 Mar 2009 10:21:34 +0700 (ICT)
Subject: Varnish on FreeBSD
Message-ID: <200903310321.n2V3LYlU022699@banyan.cs.ait.ac.th>

Hi,

I have a small issue when runnig Varnish on FreeBSD 6.4 amd64 (64 bits
extension).

I use the command (which seems very straigh forward to me):

$ /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a localhost:6081 -f /usr/local/etc/varnish/default.vcl -T localhost:6082 -s malloc,5G -s file,/web/varnish,50% -u www -g www

And Varnish starts with:

storage_malloc: max size 5120 MB.
storage_file: filename: /web/varnish/varnish.5edLFk (unlinked) size 1665195 MB.
Using old SHMFILE

But:

$ df -h /web
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/mfid0s1f    446G    4.0G    407G     1%    /web

The file system used for storage has 407 GB available and Varnish
plans to use up to 1626 GB out of that, that is far more than the 50%.

It could be an error in reporting the size, which would be nothing mor
ethan anoying. But it could also be an error in estimating the size
that Varnish can use, which would be a more serious error.

Any help on that?

Best regards,

Olivier


From des at des.no  Tue Mar 31 11:07:41 2009
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 31 Mar 2009 13:07:41 +0200
Subject: Varnish on FreeBSD
In-Reply-To: <200903310321.n2V3LYlU022699@banyan.cs.ait.ac.th> (Olivier
	Nicole's message of "Tue, 31 Mar 2009 10:21:34 +0700 (ICT)")
References: <200903310321.n2V3LYlU022699@banyan.cs.ait.ac.th>
Message-ID: <86wsa6x85e.fsf@ds4.des.no>

Olivier Nicole <on at cs.ait.ac.th> writes:
> $ /usr/local/sbin/varnishd -P /var/run/varnishd.pid -a localhost:6081 -f /usr/local/etc/varnish/default.vcl -T localhost:6082 -s malloc,5G -s file,/web/varnish,50% -u www -g www

Why use both malloc and file?  Varnish will spread objects equally
between both storage backends.  You'd be better off using just the file.

> The file system used for storage has 407 GB available and Varnish
> plans to use up to 1626 GB out of that, that is far more than the 50%.

Try instrumenting str2bytes() in lib/libvarnish/num.c to show the
details of the calculations.  In str2bytes(), p is a pointer to the size
specification ("50%" in your case), fval is the numeric value (should be
50), rel is the size of the file system in bytes (should be
approximately 407*2^30).

DES
-- 
Dag-Erling Sm?rgrav - des at des.no


From ITLJ at gyldendal.dk  Tue Mar 31 11:30:47 2009
From: ITLJ at gyldendal.dk (=?ISO-8859-1?Q?Lars_J=F8rgensen?=)
Date: Tue, 31 Mar 2009 13:30:47 +0200
Subject: Danish characters in vcl_error.
In-Reply-To: <8318f61f0903270626g136ed466ue8bbc5c42c5053a2@mail.gmail.com>
References: <2A56A311-4F1A-4A07-8F30-0F7A66AB9E74@gyldendal.dk>
	<8318f61f0903270626g136ed466ue8bbc5c42c5053a2@mail.gmail.com>
Message-ID: <FB216436-1F7A-4B6F-9C06-53EEA550E481@gyldendal.dk>

Hi Audun,

Great, thank you for your help!


--  
Lars

Den 27/03/2009 kl. 14.26 skrev Audun Ytterdal:

> You have to html-encode the danish characters..
>
> Like this:
>
>   <h1>Beklager, en feil har oppst&aring;tt p&aring; en av VGs  
> tjenester</h1>
>
>
>
> On Fri, Mar 27, 2009 at 2:12 PM, Lars J?rgensen <itlj at gyldendal.dk>  
> wrote:
>> Hi,
>>
>> I'm doing this:
>>
>> sub vcl_error {
>>    set obj.http.Content-Type = "text/html; charset=utf-8";
>>    synthetic {"
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
>> <html>
>>  <body>
>>    <h1>Vi arbejder p? systemet </h1>
>>    <body>
>> </html>
>> "};
>>    return (deliver);
>>
>> And getting this (omitting DOCTYPE for clarity):
>>
>> <html>
>> <body>
>>   <h1>Vi arbejder p?77777703?77777645 systemet </h1>
>>   body>
>> </html>
>>
>> What am I doing wrong?
>>
>>
>> --
>> Lars J?rgensen
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at projects.linpro.no
>> http://projects.linpro.no/mailman/listinfo/varnish-misc
>>
>
>
>
> --
> Audun Ytterdal
> http://audun.ytterdal.net



From s.kain at eraffe-media.de  Tue Mar 31 11:28:41 2009
From: s.kain at eraffe-media.de (Sascha Kain)
Date: Tue, 31 Mar 2009 13:28:41 +0200
Subject: varnish stopps responding with no reason
Message-ID: <49D1FE69.4050609@eraffe-media.de>

Hi,

im was running squid3 for a while now, but now i tested varnish, to 
cache my cdn.

Following:
proxycache1:/var# varnishd -V
varnishd (varnish-2.0.3)

The Server is Debian Etch 4.0 incl. all official updates.
It has 24GB of RAM with 64Bit CPU.

I compiled and installed varnish with no errors. And it is running on 
one of my 2 Servers like a charm!
load of the server + delivery of my static files is great.

But i have a problem on the other machine, its exact the same.

I start varnishd like this:
varnishd -a :80 -b 89.xxx.xxx.xxx:80 -s malloc,15360M
storage_malloc: max size 15360 MB.
Using old SHMFILE

Im not using a config yet, since i only have one backendserver for 
static files.

In Log i see:
Mar 31 12:56:34 proxycache1 varnishd[4608]: child (4609) Started
Mar 31 12:56:34 proxycache1 varnishd[4608]: Child (4609) said Closed 
fds: 3 7 8 10 11
Mar 31 12:56:34 proxycache1 varnishd[4608]: Child (4609) said Child starts
Mar 31 12:56:34 proxycache1 varnishd[4608]: Child (4609) said Ready

Then i change my application-config to use the 2nd varnishd as proxy two 
(actually have an array of ips for my CDN).
All went well, it delivers fast.
After a few minutes it stops responding on Port 80, localhost + ethXips 
not working but Varnishd still running.
telnet give me timeout.

ps auxf:
root      4608  0.0  0.0  98196   944 ?        Ss   12:56   0:00 
varnishd -a :80 -b 8xx.xxx.xxx:80 -s malloc,15360M
nobody    4609  0.2  0.4 398384 114996 ?       Sl   12:56   0:03  \_ 
varnishd -a :8xx.xxx.xxx:80 -s malloc,15360M

I switch all traffic over to the other varnishd and its running smooth 
again...
I activate squid on the other server, and all works smooth again.

any ideas?

regards

-- 
Sascha Kain
IT / Administration
eraffe media GmbH & Co. KG Marketing - Consulting - Software
Sch?nfeldstr. 17 - 83022 Rosenheim

Fon: + 49 (0)8031 - 941 41 -46
Fax: + 49 (0)8031 - 941 41 -59
E-Mail: s.kain at eraffe-media.de
www.eraffe-media.de - www.eraffe.de

eraffe media GmbH & Co. KG, Sitz: Rosenheim,
Registergericht: AG Traunstein HR A Nr. 9104,
St-Nr. 156/157/58806, FA Rosenheim,
USt.-ID: DE250117972

Pers?nlich haftende Gesellschafterin:
eraffe media Verwaltungs-GmbH, Sitz: Rosenheim,
Registergericht: AG Traunstein HR B 16956
St-Nr. 156/116/90247, FA Rosenheim

Gesch?ftsf?hrer: Maximilian Kuss, Oliver D?ser



From eshwar_bvpr at hotmail.com  Tue Mar 31 12:05:41 2009
From: eshwar_bvpr at hotmail.com (Koteswara Rao)
Date: Tue, 31 Mar 2009 17:35:41 +0530
Subject: No subject
Message-ID: <BLU106-W4541E401F89D186722C6599C8A0@phx.gbl>


Hello,

I am using Varnish on Free BSD. I am using varanishncsa to output apache style logs from Varnish. My question is, how do I get varnishncsa to work with cronolog to rotate logs?

Please let me know if there's a document already somewhere for this.

Thanks in advance.

Eshwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/vinyl-misc/attachments/20090331/d3a37089/attachment.html>