Merging upstream version 1.12.0.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 14 insertions, 9 deletions

diff --git a/streaming/README.md b/streaming/README.md
index e455d1070..e1ebad536 100644
--- a/streaming/README.md
+++ b/streaming/README.md
@@ -1,4 +1,4 @@
-# Metrics streaming
+# Streaming and replication
 
 Each netdata is able to replicate/mirror its database to another netdata, by streaming collected
 metrics, in real-time to it. This is quite different to [data archiving to third party time-series
@@ -18,13 +18,13 @@ a netdata performs:
 Local netdata (`slave`), **without any database or alarms**, collects metrics and sends them to
 another netdata (`master`).
 
-The user can take the full functionality of the `slave` netdata at
-http://master.ip:19999/host/slave.hostname/. Alarms for the `slave` are served by the `master`.
+The `my-netdata` menu shows a list of all "databases streamed to" the master. Clicking one of those links allows the user to view the full dashboard of the `slave` netdata. The URL has the form http://master-host:master-port/host/slave-host/. 
 
-In this mode the `slave` is just a plain data collector.
-It runs with... **5MB** of RAM (yes, you read correct), spawns all external plugins, but instead
+Alarms for the `slave` are served by the `master`.
+
+In this mode the `slave` is just a plain data collector. It spawns all external plugins, but instead
 of maintaining a local database and accepting dashboard requests, it streams all metrics to the
-`master`.
+`master`. The memory footprint is reduced significantly, to between 6 MiB and 40 MiB, depending on the enabled plugins. To reduce the memory usage as much as possible, refer to [running netdata in embedded devices](../docs/Performance.md#running-netdata-in-embedded-devices).
 
 The same `master` can collect data for any number of `slaves`.
 
@@ -33,8 +33,8 @@ The same `master` can collect data for any number of `slaves`.
 Local netdata (`slave`), **with a local database (and possibly alarms)**, collects metrics and
 sends them to another netdata (`master`).
 
-The user can use all the functions **at both** http://slave.ip:19999/ and
-http://master.ip:19999/host/slave.hostname/.
+The user can use all the functions **at both** http://slave-ip:slave-port/ and
+http://master-host:master-port/host/slave-host/.
 
 The `slave` and the `master` may have different data retention policies for the same metrics.
 
@@ -81,12 +81,15 @@ monitoring (there cannot be health monitoring without a database).
 
 ```
 [web]
-    mode = none | static-threaded | single-threaded | multi-threaded
+    mode = none | static-threaded 
+    accept a streaming request every seconds = 0 
 ```
 
 `[web].mode = none` disables the API (netdata will not listen to any ports).
 This also disables the registry (there cannot be a registry without an API).
 
+`accept a streaming request every seconds` can be used to set a limit on how often a master Netdata server will accept streaming requests from the slaves. 0 sets no limit, 1 means maximum once every second. If this is set, you may see error log entries "... too busy to accept new streaming request. Will be allowed in X secs". 
+
 ```
 [backend]
     enabled = yes | no
@@ -410,3 +413,5 @@ The sending side of a netdata proxy, connects and disconnects to the final desti
 metrics, following the same pattern of the receiving side.
 
 For a practical example see [Monitoring ephemeral nodes](#monitoring-ephemeral-nodes).
+
+[![analytics](https://www.google-analytics.com/collect?v=1&aip=1&t=pageview&_s=1&ds=github&dr=https%3A%2F%2Fgithub.com%2Fnetdata%2Fnetdata&dl=https%3A%2F%2Fmy-netdata.io%2Fgithub%2Fstreaming%2FREADME&_u=MAC~&cid=5792dfd7-8dc4-476b-af31-da2fdb9f93d2&tid=UA-64295674-3)]()