WORK IN PROGRESS

XXX: this need to be linked into the whole documentation structure.

The following is the output from either varnishstat -1 or by telneting to the management port and issuing the command stats. The output is identical.

The sections of the output are explained below.

Client connections

        8541  Client connections accepted

This is increased when we have accepted the connection. On systems with accept-filters this does usually not happen until we have also received the first request.

        1680  Client requests received

This is increased whenever we have complete request and starts to service it. The numbers are counters, i.e. increasing over time, and will be reset if Varnish is shut down.

Cache utilization

        1039  Cache hits
           0  Cache hits for pass
         369  Cache misses

Here, a high ratio between "Cache hits" and "Cache misses" is good. "Cache hits" means that the file was served from Varnish, "Cache misses" means that Varnish had to fetch the file from the backend. The above example is something like 3:1, which is not very good. "Cache hits for pass", is when varnish gets a response from the backend and finds out it cannot be cached, it will then create a cache object that records that fact, so that the next request goes directly to "pass".

The numbers are counters, i.e. increasing over time, and will be reset if Varnish is shut down.

Backend usage

         633  Backend connections initiated
         324  Backend connections recycles
          54  Backend connections reused
           3  Backend connections unused

The first number ("Backend connections initiated") is the total number of (TCP socket) connections that has been opened from Varnish to the backend. This number is a counter.

"Backend connections recycled" is increased whenever we have a keep-alive connection that is put back into the pool of connections. It has not yet been used, but it might be, unless the backend closes it.

"Backend connections reused" is increased whenever we actually reuse a connection from the pool of backend connections.

Last, "Backend connections unused", are the number of available connections at any given time. This number is an absolute number, and will increase and decrease during operation.

          41  N struct srcaddr
           0  N active struct srcaddr
           6  N struct sess_mem
           1  N struct sess
           9  N struct object
          10  N struct objecthead
           3  N struct smf
           0  N small free smf
           2  N large free smf
           4  N struct vbe_conn

           1  N worker threads
          23  N worker threads created
           0  N worker threads not created
           0  N worker threads limited
           0  N queued work requests
          23  N overflowed work requests
           0  N dropped work requests

N worker threads is the number of worker threads right now. "N worker threads created" is the number of times a thread has been created.

"N worker threads not created" is the number of times Varnish tried but _failed_ to create a worker thread. It should be 0.

"N worker threads limited" is the number of times Varnish wanted to create a worker thread, but wasn't able to because of the thread_pool_max setting. This should also be 0.

"N queued work requests" is the number of requests that are on the queue, waiting for a worker thread to become available. After the initial startup, this value should usually be 0, but it will spike up every now and then if you need to create threads.

"N overflowed work requests" is the number of times a request has been put on the queue. In other words: Each time "N queued work requests" grows, "N overflowed work requests" grows too, but "N queued work requests" goes down as the queue is handled, while "N queued work requests" only increments. Overflowed requests should stay static after startup (not necessarily 0).

"N dropped work requests" is the number of requests Varnish has given up trying to handle due to a full queue. This should be 0. Always. If it grows, that means either Varnish has too high load, or the queue is too small. The queue is defined by thread_pool_max.

All in all, these values help you tune the thread pool: If you set the thread_pool_min to 5, and notice that Varnish typically uses 50-120 threads, you'll see that it creates threads frequently. This typically means you want to increase thread_pool_min to 50, for instance (assuming you have two thread pools, that gives you 100 threads at any given time). Idle threads are cheap; creating threads is expensive. It really doesn't hurt to have a few hundred threads idle at any given time.

         368  N expired objects
           0  N objects on deathrow
           0  HTTP header overflows

          40  Objects sent with sendfile
        1283  Objects sent with write

The numbers are counters, i.e. increasing over time, and will be reset if Varnish is shut down. They denote how a file was sent, and is mostly relevant to developers.

        1667  Total Sessions
        1680  Total Requests
           0  Total pipe
         275  Total pass
         358  Total fetch
      494969  Total header bytes
     3624303  Total body bytes

        1340  Session Closed
           0  Session Pipeline
           0  Session Read Ahead
         340  Session herd

Shared memory

      103731  SHM records
       39618  SHM writes
           0  SHM MTX contention

Shared memory (SHM) counters show FIXME

The numbers are counters, i.e. increasing over time, and will be reset if Varnish is shut down.