Old content is still being served after an application update; what should I do?

Short answer

First, it is determined whether the old content comes from the TR7 cache or from the browser: if TRCACHE: HIT is in the response, the source is TR7; if the header is not present at all, the Cache profile is not active on the vService or the response came from the browser's own cache. In TR7 there is no operation that empties the cache entry by entry; the copy is refreshed when Cache Timeout expires. To refresh immediately, a Reload is performed on the vService (a short interruption occurs) or a change is saved in the Cache profile; both empty the cache. The permanent solution is a short Cache timeout for frequently changing content and file names that carry version information.

Problem: The Update Is Live but Users See the Old File

After new CSS, images or scripts are uploaded to the application, users can continue to see the old version. The old copy can be in the TR7 cache or in the browser of the user. First, the source is determined: if TRCACHE: HIT is in the curl -s -o /dev/null -D - https://www.example.com/app.css response, the copy is in TR7; if TRCACHE: MISS appears or the header is not present at all, the old copy is not in TR7; the old version is in the browser of the user, and a hard refresh is required in the browser (How do I know a response came from the cache (Cached(HIT) Header Name, default value TRCACHE)?). If nothing is done, the copy in TR7 is refreshed on its own at the end of Cache timeout (default 1 hour).

Solution: Three Methods

Your situation	Suitable method
Emptying the cache immediately; a short interruption is acceptable	Method 1: vService Reload
Emptying the cache without dropping connections	Method 2: Saving a change in the Cache profile
The problem not recurring in the next release	Method 3: Short duration, versioned names and narrow scope

Method 1: vService Reload

• How it works The vService is restarted and the cache in memory is emptied completely.
• Where it is openedLoad Balancer → Load Balancer vService List → right-click on the vService → Reload
• Requirement A time when the short interruption that drops open connections is acceptable; Reload is inactive while the vService is disabled
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Open the vService list

The Load Balancer → Load Balancer vService List screen is opened.

2

Adım 2 Reload

The vService row is right-clicked and Reload is selected (right-click menu). The same command is also in the ⋮ menu in the vService preview.

Verification

1First requestClient side

After Reload, the updated file is requested with curl -s -o /dev/null -D - https://www.example.com/app.css.

ExpectedTRCACHE: MISS and new content

Method 2: Saving a Change in the Cache Profile Recommended

• How it works When a change made in the Cache profile is saved, the cache is emptied; the change is applied without dropping open connections.
• Where it is openedLoad Balancer → Profiles → Cache → right-click → Edit
• Requirement If the profile is used in more than one vService, the cache of all of them is emptied; the Used in tab in the preview is checked beforehand
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Edit the profile

On the Load Balancer → Profiles → Cache screen, the row of the profile used by the vService is right-clicked and Edit is selected. If the vService uses the Default profile, this path does not exist; Method 1 is used.

2

Adım 2 Make the change

The required change is made; e.g. Cache Timeout is shortened according to how often the content changes.

3

Adım 3 Save

Save is clicked; the cache is emptied (recommended values). In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1First requestClient side

After the save, the updated file is requested with curl -s -o /dev/null -D - https://www.example.com/app.css.

ExpectedTRCACHE: MISS and new content

Method 3: Short Duration, Versioned Names and Narrow Scope

• How it works Frequently changing content stays in the cache for a short time or is not cached at all; since a file whose version information changes is a new address, it is fetched from the Backend Service immediately.
• Where it is openedLoad Balancer → Profiles → Cache · the release process of the application
• Requirement For the ?v= form, Ignore query must be off in the profile
• vService type HTTP

Step-by-Step Configuration

1

Adım 1 Edit the profile

On the Load Balancer → Profiles → Cache screen, the profile row is right-clicked and Edit is selected; if the vService uses the Default profile, a new profile is created with Add (how to add).

2

Adım 2 Shorten the duration

Cache Timeout is shortened according to how often the content changes; seconds, minutes or hours is selected as the unit.

3

Adım 3 Leave out frequently changing paths

If needed, the negated form of the condition that defines the frequently changing paths is added to the Caching Rules field with and (Which content gets cached; how do I define cache rules?).

4

Adım 4 Save the profile

Save is clicked when editing, Add for a new profile. If the profile is already assigned to a vService, the change is applied without dropping open connections.

5

Adım 5 Select the profile on the vService

If a new profile was created, the vService is opened with Edit and the profile is selected in the Details → Cache box.

6

Adım 6 Save

Save is clicked. In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.

7

Adım 7 Version the names

In the release process of the application, file names carry version information (app.v2.css) or ?v=2 is added to the address. The ?v= form works while Ignore Query is off in the profile (Are the query string and Host Header part of the cache key; can I change this?).

Verification

1New versionClient side

The new versioned address is requested with curl -s -o /dev/null -D - "https://www.example.com/app.css?v=2".

ExpectedTRCACHE: MISS and new content on the first request

Common Mistakes

• Taking action without distinguishing the source. If there is no TRCACHE: HIT in the curl response, the old copy is not in TR7; an operation done in TR7 does not change the result.
• Doing Reload at peak hours. Reload restarts the vService and open connections drop; it is done in a maintenance window.
• Using ?v= together with Ignore query. While Ignore query is on, the query string is not included in the key; the version parameter does not refresh the cache.

How it is done in the documentation

• Cache · Cache Timeout
• Cache · Operational Best Practices
• vService · Right-Click Menu

Related questions

• How do I know a response came from the cache (Cached(HIT) Header Name, default value TRCACHE)?
• Are the query string and Host Header part of the cache key; can I change this?
• Which content gets cached; how do I define cache rules?