Browse Source

Docs: Add query-node integration note

Leszek Wiesner 3 years ago
parent
commit
29e9ca34e1
1 changed files with 17 additions and 0 deletions
  1. 17 0
      distributor-node/docs/node/index.md

+ 17 - 0
distributor-node/docs/node/index.md

@@ -27,6 +27,7 @@
     - [LRU groups](#lru-groups)
   - [Cache cleanup](#cache-cleanup)
 - [Logging](#logging)
+- [Query node integration](#query-node-integration)
 <!-- AUTO-GENERATED-CONTENT:END -->
 
 <a name="the-api"></a>
@@ -381,3 +382,19 @@ The logs can be directed to some of the 3 available outputs, depending on the [`
 - console
 - a log file inside [`directories.logs`](../schema/definition-properties-directories.md#logs)
 - an elasticsearch endpoint specified via [`endpoints.elasticsearch`](../schema/definition-properties-endpoints.md#elasticsearch)
+
+# Query node integration
+
+Because the distributor node is making requests to a query node:
+- on [cache miss](#scenario-3)
+- periodically, for [cache cleanup](#cache-cleanup) purposes
+
+In order to achieve the best perfomance it is recommended to either run the query-node processor and graphql server on the same machine the distributor node will be running on, or use a query node endpoint that can be accessed with a minimal latency.
+
+Taking the [docker-compose.yml](../../docker-compose.yml) example, the services that could be run on the same machine may include:
+- `db`
+- `processor`
+- `graphql-server`
+- `distributor-node`
+
+The `INDEXER_ENDPOINT_URL` can be point to a completely external indexer endpoint, as the latency between `processor` and `indexer` is less of an issue in this case.