diff options
| author | Aleš Mrázek <ales.mrazek@nic.cz> | 2024-04-17 15:41:52 +0200 |
|---|---|---|
| committer | Aleš Mrázek <ales.mrazek@nic.cz> | 2024-04-22 12:43:52 +0200 |
| commit | 5bc1e0370b47fd9e5a011a35f2a1ba0329f95457 (patch) | |
| tree | 8f437780af186f30facb53d70e46038b8631cfd2 /modules | |
| parent | datamodel: cache: prefetch for expiring record is separated from prediction (diff) | |
| download | knot-resolver-5bc1e0370b47fd9e5a011a35f2a1ba0329f95457.tar.xz knot-resolver-5bc1e0370b47fd9e5a011a35f2a1ba0329f95457.zip | |
modules: predict: prefetching expired records has been removed
Diffstat (limited to 'modules')
| -rw-r--r-- | modules/predict/README.rst | 23 | ||||
| -rw-r--r-- | modules/predict/predict.lua | 14 |
2 files changed, 4 insertions, 33 deletions
diff --git a/modules/predict/README.rst b/modules/predict/README.rst index 966c4ca4..0bc85671 100644 --- a/modules/predict/README.rst +++ b/modules/predict/README.rst @@ -2,34 +2,19 @@ .. _mod-predict: -Prefetching records -=================== - -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. - -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, +``predict`` is an experimental module that tries to help keep the cache hot by prefetching records using a prediction mechanism to select records which should be refreshed. + +The module can learn usage patterns and repetitive queries, though this mechanism is a prototype and **not recommended** for use in production or with high traffic. 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, +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. diff --git a/modules/predict/predict.lua b/modules/predict/predict.lua index 0117fd52..38fb7258 100644 --- a/modules/predict/predict.lua +++ b/modules/predict/predict.lua @@ -172,18 +172,4 @@ function predict.config(config) predict.init() end -predict.layer = { - -- Prefetch all expiring (sub-)queries immediately after the request finishes. - -- Doing that immediately is simplest and avoids creating (new) large bursts of activity. - finish = function (_, req) - local qrys = req.rplan.resolved - for i = 0, (tonumber(qrys.len) - 1) do -- size_t doesn't work for some reason - local qry = qrys.at[i] - if qry.flags.EXPIRING == true then - resolve(kres.dname2str(qry.sname), qry.stype, qry.sclass, {'NO_CACHE'}) - end - end - end -} - return predict |