bool NO_EDNS : 1; /**< Don't use EDNS. */
bool CACHED : 1; /**< Query response is cached. */
bool NO_CACHE : 1; /**< No cache for lookup; exception: finding NSs and subqueries. */
- bool EXPIRING : 1; /**< Query response is cached, but expiring. */
+ bool EXPIRING : 1; /**< Query response is cached but expiring. See is_expiring(). */
bool ALLOW_LOCAL : 1; /**< Allow queries to local or private address ranges. */
bool DNSSEC_WANT : 1; /**< Want DNSSEC secured answer; exception: +cd,
* i.e. knot_wire_get_cd(request->qsource.packet->wire) */
Prefetching records
===================
-The module refreshes records that are about to expire when they're used (having less than 1% of original TTL).
-This improves latency for frequently used records, as they are fetched in advance.
+The ``predict`` module helps to keep the cache hot by prefetching records.
+It can utilize two independent mechanisms to select the records which should be refreshed:
+expiring records and prediction.
-It is also able to learn usage patterns and repetitive queries that the server makes. For example, if
-it makes a query every day at 18:00, the resolver expects that it is needed by that time and prefetches it
-ahead of time. This is helpful to minimize the perceived latency and keeps the cache hot.
+Expiring records
+----------------
+
+This mechanism is always active when the predict module is loaded and it is not configurable.
+
+Any time the resolver answers with records that are about to expire,
+they get refreshed. (see :c:func:`is_expiring`)
+That improves latency for records which get frequently queried, relatively to their TTL.
+
+Prediction
+----------
+
+The predict module can also learn usage patterns and repetitive queries,
+though this mechanism is basically a prototype.
+
+For example, if it makes a query every day at 18:00,
+the resolver expects that it is needed by that time and prefetches it ahead of time.
+This is helpful to minimize the perceived latency and keeps the cache hot.
+
+You can disable prediction by configuring ``period = 0``.
+Otherwise it will load the required :ref:`stats <mod-stats>` module if not present,
+and it will use its :func:`stats.frequent` table and clear it periodically.
.. tip:: The tracking window and period length determine memory requirements. If you have a server with relatively fast query turnover, keep the period low (hour for start) and shorter tracking window (5 minutes). For personal slower resolver, keep the tracking window longer (i.e. 30 minutes) and period longer (a day), as the habitual queries occur daily. Experiment to get the best results.
}
}
-Defaults are 15 minutes window, 6 hours period.
-
-.. tip:: Use period 0 to turn off prediction and just do prefetching of expiring records.
- That works even without the :ref:`stats <mod-stats>` module.
-
-.. note:: Otherwise this module requires :ref:`stats <mod-stats>` module and loads it if not present.
+Defaults are as above: 15 minutes window, 6 hours period.
Exported metrics
----------------