MirrorHub/dendrite
0
0
Fork 0
mirror of https://github.com/matrix-org/dendrite synced 2024-12-14 19:53:50 +01:00
Code Issues Releases Wiki Activity

Update 1_planning.md (#2467)

Browse source 
* Update 1_planning.md

Modes section of the planning component of the documentation rewritten for grammar and clarity.

* Update 1_planning.md

Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>
This commit is contained in:
Brandon 2022-05-25 11:17:02 -05:00 committed by GitHub
parent 6940c7c7dd
commit 015465d496
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
docs/installation/1_planning.md
View file

@ -9,21 +9,19 @@ permalink: /installation/planning
## Modes ## Modes
Dendrite can be run in one of two configurations: Dendrite consists of several components, each responsible for a different aspect of the Matrix protocol.
Users can run Dendrite in one of two modes which dictate how these components are executed and communicate.
* **Monolith mode**: All components run in the same process. In this mode, * **Monolith mode** runs all components in a single process. Components communicate through an internal NATS
it is possible to run an in-process NATS Server instead of running a standalone deployment. server with generally low overhead. This mode dramatically simplifies deployment complexity and offers the
This will usually be the preferred model for low-to-mid volume deployments, providing the best best balance between performance and resource usage for low-to-mid volume deployments.
balance between performance and resource usage.
* **Polylith mode**: A cluster of individual components running in their own processes, dealing * **Polylith mode** runs all components in isolated processes. Components communicate through an external NATS
with different aspects of the Matrix protocol. Components communicate with each other using server and HTTP APIs, which incur considerable overhead. While this mode allows for more granular control of
internal HTTP APIs and NATS Server. This will almost certainly be the preferred model for very resources dedicated toward individual processes, given the additional communications overhead, it is only
large deployments but scalability comes with a cost. API calls are expensive and therefore a necessary for very large deployments.
polylith deployment may end up using disproportionately more resources for a smaller number of
users compared to a monolith deployment.
At present, we **recommend monolith mode deployments** in all cases. Given our current state of development, **we recommend monolith mode** for all deployments.
## Databases ## Databases