Varnish Cache Plus

MSE control (mse)


The MSE VMOD lets you influence how MSE works, on a per request basis directly from VCL.

It is possible (and reasonable) to use MSE without using the VMOD. It is advised to read the MSE 3 documentation before reading about this VMOD.

However, if you need a more fine grained control than what you get from the configuration file, the MSE VMOD will give you access to this.

Example VCLs

Change algorithm for filling stores

Set the algorithm for filling up stores to consider the size of the stores.

vcl 4.0;

import mse;

sub vcl_backend_response {

The above replaces the default behavior which is round robin. In addition to size, the words smooth and available can be used.

Select a set of stores or make object memory only

vcl 4.0;

import mse;
import std;

sub vcl_backend_response {
     if (beresp.ttl < 120s) {
     } else {
          if (beresp.http.Transfer-Encoding ~ "chunked" || std.integer(beresp.http.Content-Length, 0) > 1000000) {
          } else {

The code above selects between two different kinds of stores, or sets object to be memory only, depending on properties of the object. Note that there is a parameter in the MSE configuration file which lets you specify a default set of stores, and this can simplify the VCL code slightly. This is described further in a configuration example in the MSE 3 documentation.

How to start using the VMOD in an existing setup

Since this VMOD simply modifies the behavior of MSE, no additional action is needed when you start using this VMOD. The exception is if you want to add a default_stores parameter in your configuration file. This will require a restart, but no mkfs.mse invocation is necessary.

In other words, there is even no need for a restart - you can just load a new VCL with storage selection logic, and it will take effect on the next request.

Best practices for setups with more than one -s argument - transition to one MSE

Previously, when mixing persisted storage with memory storage, or when having multiple different MSEs, there was no way around having multiple -s arguments. With the MSE vmod, the only recommended setup is having only one MSE. The process of going from many to one MSEs is straightforward. Simply make a new mse.conf file with all of the book blocks from your old configurations, and choose a reasonable value for memcache_size. No mkfs.mse invocation is necessary.

The existing VCL which chooses individual stevedores can be easily changed to select stores or setting objects to memory only, as demonstrated above.



VOID set_weighting(ENUM {size, available, smooth} weights)

This method selects how stores should be weighted when a random store is needed for an object in the cache. The weights can be based on the store sizes, the amount of free space in the stores or the special “smooth” weights, which corresponds to the amount of available space in the stevedore plus the size of the store itself.


BOOL set_stores(STRING tag)

This function sets a tag that will be used when randomly selecting a store. If there are no stores defined or if no stores match the tag, false will be returned.

If there exists a store with the given tag, true is returned.

If false is returned, and the failure is not remedied (for example by calling mse.set_stores("none");), the transaction will fail with a 503 message (unless changed in sub vcl_backend_error).


INT server_fingerprint()

This function returns the fingerprint of the set of books loaded in the MSE environment(s). (Again, it is recommended to have only one -s argument, as described above.)

The fingerprint is the xor of the unique IDs of all the books in all of the loaded MSE environments. This means that if a book is added or removed, the fingerprint will change. If several books are combined into one MSE environment, as described above, the fingerprint will not change as long as the set of books remain constant.