NOTE: The present document is work in progress for the September 2018 release. The version number 6.1.0 is provisional and may change. See Upgrading to Varnish 6.0 for notes about the currently most recent Varnish release.
XXX
We have added the max_vcl parameter to set a threshold for the number of loaded VCL programs, since it is a common error to let previous VCL instances accumulate without discarding them. The remnants of undiscarded VCLs take the form of files in the working directory of the management process. Over time, too many of these may take up significant storage space, and administrative operations such as vcl.list may become noticeably slow, or even time out, when Varnish has to iterate over many files.
The default threshold in max_vcl is 100, and VCL labels are not counted against the total. The max_vcl_handling parameter controls what happens when you reach the limit. By default you just get a warning from the VCL compiler, but you can set it to refuse to load more VCLs, or to ignore the threshold.
Added the backend_local_error_holddown and backend_remote_error_holddown parameters. These define delays for new attempts to connect to backends when certain classes of errors have been encountered, for which immediate re-connect attempts are likely to be counter-productive. See the parameter documentation for details.
XXX
req.ttl had been previously listed as deprecated, but it is now fully supported, since there are use cases that cannot be solved without it.
req.ttl and req.grace set upper bounds on the TTL and grace times that are permitted for the current request -- if these variables are set and the TTL/grace of a cache object is longer than their settings, then a new response is fetched from the backend, despite the presence of the response in the cache.
A common application is to set shorter TTLs when the backend is known to be healthy, so that responses are fresher when all is well. But if the backend is unhealthy, then use cached responses with longer TTLs to relieve load on the troubled backend:
sub vcl_recv {
# ...
if (std.healthy(req.backend_hint)) {
# Get responses no older than 70s for healthy backends
set req.ttl = 60s;
set req.grace = 10s;
}
# If the backend is unhealthy, then permit cached responses
# that are older than 70s.
}
The evaluation of the beresp.keep timer has changed a bit. keep sets a lifetime in the cache in addition to TTL for objects that can be validated by a 304 "Not Modified" response from the backend to a conditional request (with If-None-Match or If-Modified-Since). If an expired object is also out of grace time, it is no longer possible to deliver a "keep" object from vcl_hit. It is possible to validate a 304 candidate from vcl_miss.
The documentation in Grace mode and keep has been expanded to discuss these matters in greater depth, look there for more details.
The beresp.filters variable is readable and writable in vcl_backend_response. This is a space-separated list of modules that we call VFPs, for "Varnish fetch processors", that may be applied to a backend response body as it is being fetched. In default Varnish, the list may include values such as gzip, gunzip, esi and stream, depending on how you have set the beresp.do_* variables.
This addition makes it possible for VMODs to define VFPs to filter or manipulate backend response bodies, which can be added by changing the list in beresp.filters. VFPs are applied in the order given in beresp.filters, and you may have to ensure that a VFP is positioned correctly in the list, for example if it can only apply to uncompressed response bodies.
This is a new capability, and at the time of release we only know of test VFPs implemented in VMODs. Over time we hope that an "ecology" of VFP code will develop that will enrich the features available to Varnish deployments.
Added the fnmatch(...) function to vmod_std, which you can use for shell-style wildcard matching (if you prefer that to regular expressions).
vmod_unix is now supported for SunOS and descendants. This entails changing the privilege set of the child process while the VMOD is loaded, see the documentation.
XXX
varnishd(1):
varnishlog(1) and vsl(7):
varnishadm(1) and varnish-cli(7)
For a number of CLI commands, you can now use the -j argument to get a JSON response, which may help in automation. These include:
A JSON response in the CLI always includes a timestamp (epoch time in seconds with millisecond precision).
The backend.list command now lists both directors and backends, with their health status. The command now has a -v option for verbose output, in which detailed health states for each backend/director are displayed.
varnishstat(1) and varnish-counters(7):
varnishtest(1) and vtc(7):
varnishhist(1):
For all of the utilities that access the Varnish log -- varnishlog(1), varnishncsa(1), varnishtop(1) and varnishhist(1) -- it is now possible to set multiple -I and -X command-line arguments. So you can use multiple include and exclude filters that apply regular expressions to selected log messages.
Changes for developers:
eof