WordPress
Transients
Transients is WordPress's built-in way to cache a value with an expiry time. They are stored in wp_options by default and in the object cache if one is active.
How it is measured
The API is set_transient( 'weather_90210', $data, HOUR_IN_SECONDS ), get_transient(), and delete_transient(). Without a persistent object cache, WordPress writes two rows to wp_options: _transient_weather_90210 and _transient_timeout_weather_90210. With a timeout they are not autoloaded; without one, they are.
Count them with SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '\_transient\_%'. wp transient list is available through a package, and wp transient delete --expired removes the ones past their timeout.
Worked example
A site that shows a live exchange rate stores it in a transient for 15 minutes. Traffic is 30 requests a minute, so the remote API is called about 4 times an hour instead of 1,800. When the API is down the code returns false and the widget disappears.
The developer changes the code to keep the last good value in a second transient with a 24-hour life, and falls back to it when the fetch fails.
How it differs
A transient is a cached value with an expiry, and wp_options is the table where it lands when there is no external cache. With an object cache such as Redis, transients go to memory and never touch the table, which also means they are lost on a restart. Options persist until you delete them.
Common errors
Setting no expiry and having the row autoloaded on every request. Assuming the value exists after set_transient because a cache flush may remove it. Storing a transient per user or per URL until the table fills. Treating a transient as storage for data you cannot rebuild. Leaving thousands of expired rows because cron is not running.
In practice
Count transient rows in wp_options and check that the cron task which deletes expired ones runs. Always write the code so a missing transient is rebuilt. Give every set_transient a finite timeout.