Explore the Newest Features in the latest Varnish Enterprise release

Hot on the heels of a major Varnish Controller release, a series of updates to Varnish Enterprise are now available! See the release notes and changelog here.

These releases, which comprise 6.0.9r5, 6.0.9r6 and 6.0.9r7, contain the following significant updates:

• A new way to extract statistics from the cache and answer interesting questions
• A bundle of tools that make it easier to manage dynamic backends and self routing
• Improved performance for HTTP communication to other services

Query the cache for statistics

Ykey is the Varnish Enterprise tool for tag-based invalidation of cached objects. Now, a new set of functions (stat_real and stat_int) in ykey allows Varnish administrators to extract statistics from the data set that’s currently stored in the cache. Use these tools to answer questions like:

• How many images are currently in cache?
• When do we expect to evict the video-on-demand assets that are currently in cache?
• How much storage capacity is currently being consumed by this tenant?

This feature introduces a new way to use tags, and can be employed independently or together with tag-based cache invalidation. The statistics are available on a per-tag basis and you can use VCL to compose a response with the statistics you need. Since the stat functions describe the content of your cache, make sure that this is protected from unauthorized access, for example through ACLs, shared secrets and/or privileged ports. Find out more here.

Easier DNS and name resolution inside Varnish

This version of Varnish Enterprise makes significant upgrades to VMOD udo, allowing it to manage dynamic backends and set up self-routing clusters. Two prerequisites for these capabilities are the following new features:

• libadns is an asynchronous DNS resolution library developed by Varnish. VMODs can use libadns to configure a domain for active resolution by the ActiveDNS service and receive DNS updates each time the domain is resolved.
• vmod_activedns offers a VCL interface for libadns and enables the creation of dns_groups. A dns_group contains a set of rules for DNS resolution, and a template for creating dynamic backends. VMODS that support this functionality can subscribe to updates from a dns_group to create dynamic backends.

Managing dynamic backends with vmod_udo

Using libadns and vmod_activedns, vmod_udo can subscribe to dns_group updates and manage dynamic backends, supporting A, AAAA, CNAME and SRV records. Dynamic backends were already possible with vmod_goto, and sharding with udo; now dynamic backends can be managed within udo, for using sharding in a dynamic backend context. Other improvements over existing dynamic backend capabilities are:

• Compatible with multiple policies, including consistent hashing
• Rich feature set that can be combined
• Robust default values

Self routing with vmod_udo

vmod_udo also has three new functions, .get_identifier(), .self_identify(), and .self_is_next(). These are useful for implementing self-identification and self-routing, and work with both static and dynamic clusters. With the new support for DNS resolution, udo can be used to support self-routing clusters that can do the job of a load balancer or router, without needing a dedicated application: routing logic is distributed across all participating nodes. Self routing allows a cluster of Varnish instances to agree on which instance or instances that are designated as storage instances for given assets. This allows horizontal scaling of storage capacity and reduced number of origin requests when using a single tier of Varnish instances.

The main improvements over existing self-routing mechanisms are:

• Self-routing clusters can dynamically grow and shrink.
• The backend name does not need to match server.identity or another variable for the self-identification step. This makes UDO self routing resilient against configuration errors.
• The number of replicas can be specified per transaction, and objects can be stored on one or more instances (configurable in VCL).

Better resource utilization with vmod_http

Another small release, 6.0.9r6, brings a significant change to vmod_http. This VMOD allows for HTTP communication to be made to other services from VCL, including communication back to Varnish in the form of a new request and both synchronous and asynchronous calls. Popular uses for vmod_http include prefetching of video segments, search results and links.

vmod_http has undergone a reimplementation to allow for:

• Better connection reuse
• Caching of hostname lookups
• Better performance when many simultaneous requests are active

For Varnish setups that make heavy use of HTTP calls, this redesign will bring excellent performance improvements. The new version is VCL compatible with the previous version, and no adjustments to VCL are needed.

See the changelog for the complete list of changes in this release.