Performance considerations 

Overview 

The extension buys correct temporal behavior by making page cache entries expire earlier than they otherwise would, or by flushing them from a background task. Both cost cache hits. How many depends entirely on which scoping and timing strategy is configured, and the default is the most expensive combination.

This chapter describes what each configuration actually does, so the cost can be measured on a specific site. It contains no benchmark figures: none have been measured for this extension, and numbers from another site would not transfer.

The model in one table 

Scoping and timing are independent, and scoping answers two different questions depending on which timing strategy reads it.

Scoping with dynamic timing (shortens lifetimes) with scheduler timing (flushes tags)
global Every entry expires at the earliest transition site-wide. Flushes the pages tag: the entire page cache, once per transition.
per-page An entry expires at the earlier of: the next pages transition site-wide, or the next transition of a content element on that page. Flushes pageId_<uid> for a page, pageId_<pid> for a content element.
per-content Same as global — this strategy does not narrow lifetimes. Flushes one pageId_* tag per page that sys_refindex reports for the element.

Read the table before choosing a strategy. Two combinations are commonly misread:

  • per-content + dynamic narrows nothing. Its precision lives in the flush tags, which dynamic timing never reads. Configuring it without switching timing gives global behavior plus refindex code that never runs.
  • per-page or per-content + scheduler flushes only the tags named above. A page transition then refreshes that page, not the menus on every other page. Only global scoping refreshes those.

hybrid timing picks per record type: timing.hybrid.pages decides the lifetime calculation and page transitions, timing.hybrid.content decides content transitions.

Where the cost sits 

Query cost with dynamic timing
Every page cache write runs two MIN() queries per monitored table — four with the default pages and tt_content, two more for every table another extension registers. Each query is a single indexed aggregate returning one integer. One request carries one workspace and one language, so the query count does not grow with the number of configured languages.
Cache hit ratio
This is the cost that matters, and it is a property of the site, not of the extension: how often transitions occur, how many pages exist, and how much traffic arrives between two transitions.
Simultaneous expiry
With global scoping every entry carries the same expiry timestamp, so they all miss at once. Behind a CDN or reverse proxy that miss propagates upstream. per-page scoping spreads the timestamps for content transitions; page transitions still land on all entries at once.
Query cost with scheduler timing
Zero during page generation. The cost moves into the scheduled task, which is heavier than the lookup it replaces: each run loads every record carrying a starttime or endtime from every monitored table into PHP — one query per table, no time restriction in SQL — and then filters the run's time window in PHP. Its cost therefore scales with the total amount of temporal content on the site, not with the number of transitions in the window. Each transition that does fall in the window costs one flushByTag() per tag the scoping strategy names.

Chapters 

⚡ Optimization strategies 

What scoping, timing and harmonization each change, and how to combine them.

⚠️ Limitations 

What the approach cannot do, and the failure modes to plan for.

🎯 Decision guide 

Which configuration matches which shape of site, and what to measure before deciding.

🔄 Alternative approaches 

Solving temporal content without this extension: uncached menus, ESI, client-side loading, scheduled clearing.

❓ Frequently asked questions 

Cache synchronization, CDNs, workspaces, and when not to use the extension.