lb cache

The lb cache command creates the cache profiles that manage the responses coming from the backend being kept on TR7. When the profile is bound to a vService, the responses that comply with the rules are kept and are given to the subsequent requests without going to the backend. Its panel equivalent is the Cache screen.

Command Summary

TR7 WEB-CLI · lb cache

# Tab after the command

admin@TR7LBWAF01> lb cache

add delete list show update

 

admin@TR7LBWAF01> lb cache list # list all of them

admin@TR7LBWAF01> lb cache show <id> # show one

admin@TR7LBWAF01> lb cache add name <name> … # new profile

admin@TR7LBWAF01> lb cache update id <id> … # change

admin@TR7LBWAF01> lb cache delete <id> # delete

admin@TR7LBWAF01>  

Writing Order

Step 1 Write the name

This is the only required field: lb cache add web-cache

Step 2 Set the duration and the size

--timeout.val 30 --timeout.unit m --sizeMB 20

Step 3 Add the rules

Every rule takes its own index and id: --cacheRules.0.id …

Step 4 Bind it to a vService

lb service update id <vService> --cache <profile> — only in the vServices of the HTTP type

Required Fields

Order	Field	Status	Value
1	name	Required	The name of the profile; it must be unique in the collection

The rest of the profile is optional: if no field is given, the profile is formed with the defaults.

The Duration, the Size and the Header

Field	What it does	What is written after it
--timeout.val · --timeout.unit	Determines how long a response will stay in the cache	A number and a unit: s seconds · m minutes · h hours. The default is 1 hour, the shortest is 10 seconds
--sizeMB	Limits the size of the largest object that will be cached	An integer between 0 and 2048 (MB). Larger responses are not cached
--cacheHeaderName	Determines the name of the header added to the response given from the cache	A header name; the default is TRCACHE. By looking at this header the client understands that the response comes from the cache

The Caching Rules

The rules determine which requests will be cached. Every rule is written with its own index and carries its own id.

Field	Status	What it does	What is written after it
--cacheRules.N.id	Required	Gives an id to the rule	The rule id; it must be unique within the profile. When a rule is added, this field has to be given
--cacheRules.N.cond	Optional	Determines to which requests the rule will be applied	A condition expression; it is built from the lb condition records. If no condition is given, the rule matches every request
--cacheRules.N.etag	Optional	Turns on the ETag header being added to the response; when the version has not changed, the client does not download the content again	true · false (default false)

The Fields That Loosen the Matching Criterion

While the cache looks at whether a request is the same as a previously kept response, it takes the host header, the query string and the request and response headers into account by default. The fields below disable these criteria one by one: when they are turned on, different requests share the same response and the cache hit rate increases.

Field	Default	What it does
--ignoreHost	false	Ignores the Host header; the requests coming from different domain names share the same response
--ignoreQuery	false	Ignores the query string; even if what comes after ? changes, the same response is given
--ignoreRequestCheck	false	Ignores the request headers
--ignoreResponseCheck	false	Ignores the response headers; the headers of the backend that prevent caching are not taken into account
--allowCacheAllMethods	false	Ignores the HTTP method standards; the methods that are not normally cached are kept as well

Loosening can return a wrong response

These fields narrow the distinguishing criterion of the cache. For example, when --ignoreQuery true is written, the same response is given to the ?id=1 and ?id=2 requests. They are turned on only in the places where the content really does not change.

Dynamic Caching

Field	Status	What it does	What is written after it
--dynamicCaching	Optional	Turns on the cache key being created from the request content	true · false (default false)
--dynamicCachingKeys.N	Conditionally required	Determines the variables that make up the key	A smart variable; Tab lists the usable ones. When --dynamicCaching true is written at least one is needed; each is written with its own index and different from the others

When dynamic caching is turned on, the responses are kept not as a single copy but separately according to the value of the selected variables. In this way the content that changes according to the user or to the request can be cached too.

Examples

TR7 WEB-CLI · A) A simple profile for static content

admin@TR7LBWAF01> lb cache add name static-content --timeout.val 6 --timeout.unit h --sizeMB 50

admin@TR7LBWAF01>  

TR7 WEB-CLI · B) A profile with two rules

# every rule takes its own index and id

admin@TR7LBWAF01> lb cache add name portal-cache --timeout.val 30 --timeout.unit m \

--cacheRules.0.id images --cacheRules.0.cond <condition> --cacheRules.0.etag true \

--cacheRules.1.id styles --cacheRules.1.cond <condition>

admin@TR7LBWAF01>  

TR7 WEB-CLI · C) Dynamic caching and binding to a vService

admin@TR7LBWAF01> lb cache add name per-user --dynamicCaching true \

--dynamicCachingKeys.0 <variable-1> --dynamicCachingKeys.1 <variable-2>

 

admin@TR7LBWAF01> lb service update id <vService> --cache <profile>

admin@TR7LBWAF01>  

Updating and Deleting

TR7 WEB-CLI · update and delete

# changing an existing rule

admin@TR7LBWAF01> lb cache update id <id> --cacheRules.0.etag false

 

# adding a new rule to the list: the next index is written

admin@TR7LBWAF01> lb cache update id <id> --cacheRules.2.id fonts

 

# removing a single rule · emptying the rule list

admin@TR7LBWAF01> lb cache update id <id> --cacheRules.1.delete

admin@TR7LBWAF01> lb cache update id <id> --cacheRules.delete

 

# the dynamic key list is emptied in the same way

admin@TR7LBWAF01> lb cache update id <id> --dynamicCachingKeys.delete

 

admin@TR7LBWAF01> lb cache delete <id>

admin@TR7LBWAF01>  

Things to Know

• A profile does not work on its own. The caching starts when the profile is bound to a vService with the --cache field. This field is found only in the vServices of the HTTP type.
• The rule id is required. While a rule is being added, --cacheRules.N.id has to be given; the ids are unique within the profile.
• The shortest duration is 10 seconds. A shorter value cannot be written in the --timeout field; only s, m and h are used as the unit.
• The size limit is per response. The responses larger than the --sizeMB value are not cached at all; the limit cannot exceed 2048 MB.
• The name is unique. A second profile with the same name cannot be created.