aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/doc/src/diameter.xml
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2015-12-07 17:06:38 +0100
committerAnders Svensson <[email protected]>2015-12-21 17:16:37 +0100
commit8fd4e5f47efd13a6bad7811239438539ae383966 (patch)
tree5047570e18b53db9e21c106b0a7d3a299fe882b8 /lib/diameter/doc/src/diameter.xml
parent09a4ef659657525b7530416697f92db8a360a28f (diff)
downloadotp-8fd4e5f47efd13a6bad7811239438539ae383966.tar.gz
otp-8fd4e5f47efd13a6bad7811239438539ae383966.tar.bz2
otp-8fd4e5f47efd13a6bad7811239438539ae383966.zip
Make peer handling more efficient
Each service process maintains a dictionary of peers, mapping an application alias to a {pid(), #diameter_caps{}} list of connected peers. These lists are potentially large, peers were appended to the end of the list for no particular reason, and these long lists were constructed/deconstructed when filtering them for pick_peer callbacks. Many simultaneous outgoing request could then slow the VM to a crawl, with many scheduled processes mired in list manipulation. The pseudo-dicts are now replaced by plain ets tables. The reason for them was (once upon a time) to have an interface interchangeable with a plain dict for debugging purposes, but strict swapablity hasn't been the case for some time now, and in practice a swap has never taken place. Additional tables mapping Origin-Host/Realm have also been introduced, to minimize the size of the peers lists when peers are filtered on host/realm. For example, a filter like {any, [{all, [realm, host]}, realm]} is probably a very common case: preferring a Destination-Realm/Host match before falling back on Destination-Realm alone. This is now more efficiently (but not equivalently) expressed as {first, [{all, [realm, host]}, realm]} to stop the search when the best match is made, and extracts peers from host/realm tables instead of searching through the list of all peers supporting the application in question. The code to try and start with a lookup isn't exhaustive, and the 'any' filter is still as inefficient as previously.
Diffstat (limited to 'lib/diameter/doc/src/diameter.xml')
-rw-r--r--lib/diameter/doc/src/diameter.xml22
1 files changed, 13 insertions, 9 deletions
diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index b0cff32c9a..dbbbb01138 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -466,7 +466,7 @@ Matches only those peers whose Origin-Host has the
specified value, or all peers if the atom <c>any</c>.</p>
</item>
-<tag><c>{realm, any|&dict_DiameterIdentity;</c></tag>
+<tag><c>{realm, any|&dict_DiameterIdentity;}</c></tag>
<item>
<p>
Matches only those peers whose Origin-Realm has the
@@ -499,18 +499,22 @@ Matches only those peers matched by each filter in the specified list.</p>
<item>
<p>
Matches only those peers matched by at least one filter in the
-specified list.</p>
+specified list.
+The resulting list will be in match order, peers matching the
+first filter of the list sorting before those matched by the second,
+and so on.</p>
+</item>
+<tag><c>{first, [&peer_filter;]}</c></tag>
+<item>
<p>
-The resulting peer list will be in match order, peers matching the
-first filter of the list sorting before those matched by the second,
-and so on.
-For example, the following filter causes peers matching both the host
-and realm filters to be presented before those matching only the realm
-filter.</p>
+Like <c>any</c>, but stops at the first filter for which there are
+matches, which can be much more efficient when there are many peers.
+For example, the following filter causes only peers best matching
+both the host and realm filters to be presented.</p>
<pre>
-{any, [{all, [host, realm]}, realm]}
+{first, [{all, [host, realm]}, realm]}
</pre>
</item>