Fix a few refs

diff --git a/pdns/recursordist/docs/changelog/4.1.rst b/pdns/recursordist/docs/changelog/4.1.rst
index 86e61c0145ac1f490543dce86723421bb21d3474..3c0ed759a81717ee73beb72c6c61e763956462b3 100644 (file)
--- a/pdns/recursordist/docs/changelog/4.1.rst
+++ b/pdns/recursordist/docs/changelog/4.1.rst
@@ -933,7 +933,7 @@ See :doc:`EOL Statements <../appendices/EOL>`.
     :tags: Improvements
     :pullreq: 5774
 
-    Add :ref:`experimental metrics <stat-x-our-latency>` that track the time spent inside PowerDNS per query.
+    Add experimental :doc:`../metrics` ``x-our-latency`` that track the time spent inside PowerDNS per query.
     These metrics ignore time spent waiting for the network.
 
   .. change::

diff --git a/pdns/recursordist/docs/performance.rst b/pdns/recursordist/docs/performance.rst
index fcfd67157fc1505ca97cc22f29efb6eff4fd255c..27cb2333f3ea406ccc5ac64b87b58bfe5cd7f1be 100644 (file)
--- a/pdns/recursordist/docs/performance.rst
+++ b/pdns/recursordist/docs/performance.rst
@@ -205,15 +205,15 @@ If you expect few clients, you can increase :ref:`setting-max-concurrent-request
 If you expect many clients and you have increased :ref:`setting-max-tcp-clients`, reduce :ref:`setting-max-concurrent-requests-per-tcp-connection` number to prevent mthread starvation or increase the maximum number of mthreads.
 
 To increase the maximum number of concurrent queries consider increasing  :ref:`setting-max-mthreads`, but be aware that each active mthread consumes more than 200k of memory.
-To see the current number of mthreads in use consult the :ref:`stat-concurrent-queries` metric.
-If a query could not be handled due to mthread shortage, the :ref:`stat-over-capacity-drops` metric is increased.
+To see the current number of mthreads in use consult the :doc:`metrics` ``concurrent-queries`` metric.
+If a query could not be handled due to mthread shortage, the ``over-capacity-drops`` metric is increased.
 
 As an example, if you have typically 200 TCP clients, and the default maximum number of mthreads of 2048, a good number of concurrent requests per TCP connection would be 5. Assuming a worst case packet cache hit ratio, if all 200 TCP clients fill their connections with queries, about half (5 * 200) of the mthreads would be used by incoming TCP queries, leaving the other half for incoming UDP queries.
 Note that starting with version 5.0.0, TCP queries are processed by dedicated TCP thread(s), so the sharing of mthreads between UDP and TCP queries no longer applies.
 
 The total number of incoming TCP connections is limited by :ref:`setting-max-tcp-clients`.
 There is also a per client address limit: :ref:`setting-max-tcp-per-client` to limit the impact of a single client.
-Consult the :ref:`stat-tcp-clients` metric for the current number of TCP connections and the :ref:`stat-tcp-client-overflow` metric to see if client connection attempts were rejected because there were too many existing connections from a single address.
+Consult the :doc:`metrics` ``tcp-clients`` metric for the current number of TCP connections and the ``tcp-client-overflow`` metric to see if client connection attempts were rejected because there were too many existing connections from a single address.
 
 .. _tcp-fast-open-support: