Varnish Cache 運用編


この記事の内容はvarnish-3.0.4で確認しています.

## キャッシュ

### 全てのキャッシュクリア

```
# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 "ban.url .*"
# echo $?
0
```

## バックエンド

運用中はバックエンドの状態や状態の変更したいことがあります.
その場合は以下のコマンドで対応できます.

### ステータス確認

`backend.list`を使うとステータスの確認ができます.

```shell
# varnishadm backend.list
Backend name               Refs   Admin      Probe
web_01(192.168.0.11,,8080) 1      probe      Healthy 3/3
web_02(192.168.0.12,,8080) 1      probe      Healthy 3/3
```

### ステータス変更

`backend.set_health $BACKEND_NAME $STATE`を使うとステータスが変更できます.

`$BACKEND_NAME`には変更したいバックエンド名を指定し、
`$STATE`には`auto`,`sick`または`healthy `を指定します

```shell
# varnishadm backend.set_health web_01 sick
# varnishadm backend.list

Backend name               Refs   Admin      Probe
web_01(192.168.0.11,,8080) 1      sick       Healthy 3/3
web_02(192.168.0.12,,8080) 1      probe      Healthy 3/3
```

### backend.list の Refs

結論から言うと`backend.list`の`Refs`は __同時接続数__ です.

イマイチ、ドキュメント見ても書いてないのでコードを追ってみました.

`backend.list`のRefsを表示してる箇所は[cache_backend_cfg.cの__match_proto__()](https://github.com/varnish/Varnish-Cache/blob/2edbe43feda671dd432152e82e4cc376e1b79cb4/bin/varnishd/cache/cache_backend_cfg.c#L374)で出力されていて. `b->refcount`がそれ.

```c:cache_backend_cfg.c
static int __match_proto__()
do_list(struct cli *cli, struct backend *b, void *priv)
{
    /* 省略 */

	VCLI_Out(cli, "\n%-30s %-6d", b->display_name, b->refcount);

```

っで`b->refcount`は[`backend`構造体の`int`型](https://github.com/varnish/Varnish-Cache/blob/2edbe43feda671dd432152e82e4cc376e1b79cb4/bin/varnishd/cache/cache_backend.h#L107)で


```c:cache_backend.h
struct backend {
	unsigned		magic;
#define BACKEND_MAGIC		0x64c4c7c6

	VTAILQ_ENTRY(backend)	list;
	int			refcount;
	struct lock		mtx;

```

この`refcount`自体の変更箇所を追って見ると[コネクション確定時にカウントアップ](https://github.com/varnish/Varnish-Cache/blob/2edbe43feda671dd432152e82e4cc376e1b79cb4/bin/varnishd/cache/cache_backend.c#L151)されていました.
この時点でバックエンドへのコネクション数なのは確実っぽい.

ってことは`backend.list`の`Refs`を合計するとbackendの __ほぼ総同時接続数__ と同等で.「 __ほぼ__ 」なのはhealthcheckをしていると1は確実にカウントアップされ実際の接続数とはここで１ズレてるとお思います.



## ログ

### varnishlogの見方

`varnishlog` を実行すると以下の様なログが出力される.

```
   14 BackendClose - default
   14 BackendOpen  b default 192.168.0.110 37567 192.168.0.111 8080
   14 TxRequest    b HEAD
   14 TxURL        b /robots.txt
   14 TxProtocol   b HTTP/1.1
   14 TxHeader     b Authorization: Basic aG9iZWhvZ2U6aG9nZWhvZ2U=
   14 TxHeader     b User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5
   14 TxHeader     b Host: hogehoge.jp
   14 TxHeader     b Accept: */*
   14 TxHeader     b X-Forwarded-For: 192.168.0.101
   14 TxHeader     b X-Varnish: 301929229
   14 RxProtocol   b HTTP/1.1
   14 RxStatus     b 404
   14 RxResponse   b Not Found
   14 RxHeader     b Server: Apache-Coyote/1.1
   14 RxHeader     b Content-Length: 0
   14 RxHeader     b Date: Thu, 30 Jan 2014 10:12:26 GMT
   14 Fetch_Body   b 0(none) cls 0 mklen 0
   14 Length       b 0
   14 BackendReuse b default
```

１行１行のログは4カラムの情報から成り立っている

* トランザクションNo
 * トランザクション毎に同じ番号が振られます
* タグ
 * タグで特に重要なのはプレフィックスで`Rx`と`Tx`がある
 * `Rx`はVarnishが受け取るデータ
 * `Tx`はVarnishが渡すデータ
* 向き
 * 向きは対クライアントか対バックエンドを判断できます
 * `c`は対クライアントとのやりとり
 * `b`は対バックエンドとのやりとり
* データ
 * 実際のデータ内容


| トランザクションNo | タグ      | 向き | データ        |
|:----------------|:----------|:----|:-------------|
| 14              | TxRequest | b   | HEAD         |
| 14              | TxURL     | b   | /robots.txt  |