forked from Fediversity/Fediversity
Expanded the checklist, added tables for easier viewing.
This commit is contained in:
parent
56c3fc13b4
commit
19dc889db6
|
@ -17,7 +17,9 @@ server with users who don't engage in busy rooms like
|
||||||
than 2 CPU cores, 8GB of RAM and 50GB of diskspace.
|
than 2 CPU cores, 8GB of RAM and 50GB of diskspace.
|
||||||
|
|
||||||
A server with users who do join very busy rooms, can easily eat 4 cores and
|
A server with users who do join very busy rooms, can easily eat 4 cores and
|
||||||
16GB of RAM. Or more. Or even much more.
|
16GB of RAM. Or more. Or even much more. If you have a public server, where
|
||||||
|
unknown people can register new accounts, you'll probably need a bit more
|
||||||
|
oompf (and [moderation](draupnir)).
|
||||||
|
|
||||||
During its life, the server may need more resources, if users change
|
During its life, the server may need more resources, if users change
|
||||||
their behaviour. Or less. There's no one-size-fits-all approach.
|
their behaviour. Or less. There's no one-size-fits-all approach.
|
||||||
|
@ -30,6 +32,14 @@ should probably follow the [worker-based setup](synapse/workers), because
|
||||||
changing the architecture from monolithic to worker-based once the server is
|
changing the architecture from monolithic to worker-based once the server is
|
||||||
already in use, is a tricky task.
|
already in use, is a tricky task.
|
||||||
|
|
||||||
|
Here's a ballpark figure. Remember, your mileage will probably vary.
|
||||||
|
|
||||||
|
| Scenario | Architecture | CPU | RAM | Diskspace (GB) |
|
||||||
|
| :------------------------------------ | :-----------------------------: | :----: | :----: | :------------: |
|
||||||
|
| Personal, not many very busy rooms | [monolithic](synapse) | 2 | 8GB | 50 |
|
||||||
|
| Private, users join very busy rooms | [worker-based](synapse/workers) | 4 | 16GB | 100 |
|
||||||
|
| Public, many users in very busy rooms | [worker-based](synapse/workers) | 8 | 32GB | 250 |
|
||||||
|
|
||||||
|
|
||||||
# DNS and certificates
|
# DNS and certificates
|
||||||
|
|
||||||
|
@ -73,3 +83,12 @@ certificate for that, let's assume you use `call.example.com` for that. This
|
||||||
can be a CNAME again. Element Call uses [LiveKit](element-call#livekit) for the
|
can be a CNAME again. Element Call uses [LiveKit](element-call#livekit) for the
|
||||||
actual processing of audio and video, and that needs its own DNS entry and certificate
|
actual processing of audio and video, and that needs its own DNS entry and certificate
|
||||||
too. We'll use `livekit.example.com`.
|
too. We'll use `livekit.example.com`.
|
||||||
|
|
||||||
|
| FQDN | Use | Comment |
|
||||||
|
| :-------------------- | :--------------------- | :-------------------------------- |
|
||||||
|
| `example.com` | Hosting `.well-known` | |
|
||||||
|
| `matrix.example.com` | Synapse server | Can't be `CNAME` |
|
||||||
|
| `element.example.com` | Webclient | |
|
||||||
|
| `turn.example.com` | TURN / Element Call | Highly recommended |
|
||||||
|
| `call.example.com` | Element Call | Optional |
|
||||||
|
| `livekit.example.com` | LiveKit SFU | Optional, needed for Element Call |
|
||||||
|
|
Loading…
Reference in a new issue