0
0
Fork 0
mirror of https://github.com/matrix-org/dendrite synced 2024-05-16 12:23:45 +02:00
Go to file
PiotrKozimor 12649ccedd
Improve selectRoomIDsWithAnyMembershipSQL performance (#2738)
Recently I have observed that dendrite spends a lot of time (~390s) in
`selectRoomIDsWithAnyMembershipSQL` query

```
dendrite_syncapi=# select total_exec_time, left(query,100) from pg_stat_statements order by total_exec_time desc limit 5 ;
  total_exec_time   |                                                 left
--------------------+------------------------------------------------------------------------------------------------------
  747826.5800519128 | SELECT event_id, id, headered_event_json, session_id, exclude_from_sync, transaction_id, history_vis
  389130.5490339942 | SELECT DISTINCT room_id, membership FROM syncapi_current_room_state WHERE type = $2 AND state_key =
 376104.17514700035 | SELECT psd.datname, xact_commit, xact_rollback, blks_read, blks_hit, tup_returned, tup_fetched, tup_
   363644.164092031 | SELECT event_type_nid, event_state_key_nid, event_nid FROM roomserver_events WHERE event_nid = ANY($
  58570.48104699995 | SELECT event_id, headered_event_json FROM syncapi_current_room_state WHERE room_id = $1 AND ( $2::te
(5 rows)
```

Explain analyze showed correct usage of `syncapi_room_state_unique`
index:

```
dendrite_syncapi=#
explain analyze SELECT distinct room_id, membership FROM syncapi_current_room_state WHERE type = 'm.room.member' AND state_key = '@qjfl:dendrite.stg.globekeeper.com';
                                                                               QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Unique  (cost=2749.38..2749.56 rows=24 width=52) (actual time=2.933..2.956 rows=65 loops=1)
   ->  Sort  (cost=2749.38..2749.44 rows=24 width=52) (actual time=2.932..2.937 rows=65 loops=1)
         Sort Key: room_id, membership
         Sort Method: quicksort  Memory: 34kB
         ->  Index Scan using syncapi_room_state_unique on syncapi_current_room_state  (cost=0.41..2748.83 rows=24 width=52) (actual time=0.030..2.890 rows=65 loops=1)
               Index Cond: ((type = 'm.room.member'::text) AND (state_key = '@qjfl:dendrite.stg.globekeeper.com'::text))
 Planning Time: 0.140 ms
 Execution Time: 2.990 ms
(8 rows)
```

Multi-column indexes in Postgres shall perform well for leftmost
columns, but I gave it a try and created
`syncapi_current_room_state_type_state_key_idx` index. I could observe
significant performance improvement. Execution time dropped from 2.9 ms
to 0.24 ms:

```
explain analyze SELECT distinct room_id, membership FROM syncapi_current_room_state WHERE type = 'm.room.member' AND state_key = '@qjfl:dendrite.stg.globekeeper.com';
                                                                             QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Unique  (cost=96.46..96.64 rows=24 width=52) (actual time=0.199..0.218 rows=65 loops=1)
   ->  Sort  (cost=96.46..96.52 rows=24 width=52) (actual time=0.199..0.202 rows=65 loops=1)
         Sort Key: room_id, membership
         Sort Method: quicksort  Memory: 34kB
         ->  Bitmap Heap Scan on syncapi_current_room_state  (cost=4.53..95.91 rows=24 width=52) (actual time=0.048..0.139 rows=65 loops=1)
               Recheck Cond: ((type = 'm.room.member'::text) AND (state_key = '@qjfl:dendrite.stg.globekeeper.com'::text))
               Heap Blocks: exact=59
               ->  Bitmap Index Scan on syncapi_current_room_state_type_state_key_idx  (cost=0.00..4.53 rows=24 width=0) (actual time=0.037..0.037 rows=65 loops=1)
                     Index Cond: ((type = 'm.room.member'::text) AND (state_key = '@qjfl:dendrite.stg.globekeeper.com'::text))
 Planning Time: 0.236 ms
 Execution Time: 0.242 ms
(11 rows)
```

Next improvement is skipping DISTINCT and rely on map assignment in
`SelectRoomIDsWithAnyMembership`. Execution time drops by almost half:

```
explain analyze SELECT room_id, membership FROM syncapi_current_room_state WHERE type = 'm.room.member' AND state_key = '@qjfl:dendrite.stg.globekeeper.com';
                                                                       QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on syncapi_current_room_state  (cost=4.53..95.91 rows=24 width=52) (actual time=0.032..0.113 rows=65 loops=1)
   Recheck Cond: ((type = 'm.room.member'::text) AND (state_key = '@qjfl:dendrite.stg.globekeeper.com'::text))
   Heap Blocks: exact=59
   ->  Bitmap Index Scan on syncapi_current_room_state_type_state_key_idx  (cost=0.00..4.53 rows=24 width=0) (actual time=0.021..0.021 rows=65 loops=1)
         Index Cond: ((type = 'm.room.member'::text) AND (state_key = '@qjfl:dendrite.stg.globekeeper.com'::text))
 Planning Time: 0.087 ms
 Execution Time: 0.136 ms
(7 rows)
```

In our env we spend only 1s on inserting to table, so the write penalty
of creating an index should be small.
```
dendrite_syncapi=# select total_exec_time, left(query,100) from pg_stat_statements where query like '%INSERT%syncapi_current_room_state%' order by total_exec_time desc;
  total_exec_time   |                                                 left
--------------------+------------------------------------------------------------------------------------------------------
 1139.9057619999971 | INSERT INTO syncapi_current_room_state (room_id, event_id, type, sender, contains_url, state_key, he
(1 row)
``` 

This PR does not require test modifications.

### Pull Request Checklist

<!-- Please read docs/CONTRIBUTING.md before submitting your pull
request -->

* [x] I have added added tests for PR _or_ I have justified why this PR
doesn't need tests.
* [x] Pull request includes a [sign
off](https://github.com/matrix-org/dendrite/blob/main/docs/CONTRIBUTING.md#sign-off)

Signed-off-by: `Piotr Kozimor <p1996k@gmail.com>`
2022-09-27 09:41:36 +01:00
.github Add pinecone demo container image (#2710) 2022-09-27 09:39:39 +01:00
appservice Bug fix #2718 appservice txnid should be different for each batch of events (#2719) 2022-09-19 18:39:06 +02:00
build Add pinecone demo container image (#2710) 2022-09-27 09:39:39 +01:00
clientapi Send-to-device consumer/producer tweaks (#2713) 2022-09-13 09:35:45 +02:00
cmd Add -dir option to dendrite-demo-pinecone and dendrite-demo-yggdrasil 2022-09-23 15:44:21 +01:00
docs Update documentation to state that Dendrite requires PostgreSQL UTF-8 encoding 2022-09-26 09:33:34 +01:00
federationapi Remove origin field from PDUs (#2737) 2022-09-26 17:35:35 +01:00
internal Version 0.9.9 (#2732) 2022-09-22 14:54:25 +01:00
keyserver Mark device list as stale, if we don't have the requesting device (#2728) 2022-09-20 11:32:03 +02:00
mediaapi Do not use ioutil as it is deprecated (#2625) 2022-08-05 10:26:59 +01:00
roomserver Remove origin field from PDUs (#2737) 2022-09-26 17:35:35 +01:00
setup HTTP connection keepalives (#2730) 2022-09-20 17:17:44 +01:00
syncapi Improve selectRoomIDsWithAnyMembershipSQL performance (#2738) 2022-09-27 09:41:36 +01:00
test Fulltext implementation incl. config (#2480) 2022-09-07 18:15:54 +02:00
userapi Use TxStmt in SQLite pusher table 2022-09-26 09:54:54 +01:00
.dockerignore Docker Hub (#1053) 2020-05-21 13:02:28 +01:00
.gitignore New documentation: https://matrix-org.github.io/dendrite/ 2022-05-11 15:39:36 +01:00
.golangci.yml Increase gocyclo complexity to 25 (and remove all but 2 golint directives related to it) (#1783) 2021-03-03 14:35:57 +00:00
are-we-synapse-yet.list Update AWSY test groups (#2365) 2022-04-21 17:17:52 +01:00
are-we-synapse-yet.py Add Are We Synapse Yet to GHA (#2321) 2022-04-05 15:32:30 +02:00
build-dendritejs.sh Add startup testing for Wasm Pinecone build (#1910) 2021-07-20 12:14:58 +01:00
build.cmd build.sh to build.cmd (#2319) 2022-04-05 11:27:29 +01:00
build.sh Disable WebAssembly builds for now 2022-07-01 09:50:06 +01:00
CHANGES.md Version 0.9.9 (#2732) 2022-09-22 14:54:25 +01:00
dendrite-sample.monolith.yaml HTTP connection keepalives (#2730) 2022-09-20 17:17:44 +01:00
dendrite-sample.polylith.yaml HTTP connection keepalives (#2730) 2022-09-20 17:17:44 +01:00
go.mod Remove origin field from PDUs (#2737) 2022-09-26 17:35:35 +01:00
go.sum Remove origin field from PDUs (#2737) 2022-09-26 17:35:35 +01:00
LICENSE Add Apache Version 2.0 license and headers to all golang files 2017-04-21 00:40:52 +02:00
README.md Update readme 2022-09-20 14:10:30 +01:00
run-sytest.sh Add race testing to tests, and fix a few small race conditions in the tests (#2587) 2022-08-05 09:19:33 +01:00
show-expected-fail-tests.sh Add Are We Synapse Yet to GHA (#2321) 2022-04-05 15:32:30 +02:00
sytest-blacklist Add HTTP status code to FederationClientError (#2699) 2022-09-07 16:14:09 +02:00
sytest-whitelist Add HTTP status code to FederationClientError (#2699) 2022-09-07 16:14:09 +02:00
test-dendritejs.sh Add startup testing for Wasm Pinecone build (#1910) 2021-07-20 12:14:58 +01:00

Dendrite

Build status Dendrite Dendrite Dev

Dendrite is a second-generation Matrix homeserver written in Go. It intends to provide an efficient, reliable and scalable alternative to Synapse:

  • Efficient: A small memory footprint with better baseline performance than an out-of-the-box Synapse.
  • Reliable: Implements the Matrix specification as written, using the same test suite as Synapse as well as a brand new Go test suite.
  • Scalable: can run on multiple machines and eventually scale to massive homeserver deployments.

Dendrite is beta software, which means:

  • Dendrite is ready for early adopters. We recommend running in Monolith mode with a PostgreSQL database.
  • Dendrite has periodic releases. We intend to release new versions as we fix bugs and land significant features.
  • Dendrite supports database schema upgrades between releases. This means you should never lose your messages when upgrading Dendrite.

This does not mean:

  • Dendrite is bug-free. It has not yet been battle-tested in the real world and so will be error prone initially.
  • Dendrite is feature-complete. There may be client or federation APIs that are not implemented.
  • Dendrite is ready for massive homeserver deployments. There is no sharding of microservices (although it is possible to run them on separate machines) and there is no high-availability/clustering support.

Currently, we expect Dendrite to function well for small (10s/100s of users) homeserver deployments as well as P2P Matrix nodes in-browser or on mobile devices. In the future, we will be able to scale up to gigantic servers (equivalent to matrix.org) via polylith mode.

If you have further questions, please take a look at our FAQ or join us in:

Requirements

See the Planning your Installation page for more information on requirements.

To build Dendrite, you will need Go 1.18 or later.

For a usable federating Dendrite deployment, you will also need:

  • A domain name (or subdomain)
  • A valid TLS certificate issued by a trusted authority for that domain
  • SRV records or a well-known file pointing to your deployment

Also recommended are:

  • A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms
  • A reverse proxy server, such as nginx, configured like this sample

The Federation Tester can be used to verify your deployment.

Get started

If you wish to build a fully-federating Dendrite instance, see the Installation documentation. For running in Docker, see build/docker.

The following instructions are enough to get Dendrite started as a non-federating test deployment using self-signed certificates and SQLite databases:

$ git clone https://github.com/matrix-org/dendrite
$ cd dendrite
$ ./build.sh

# Generate a Matrix signing key for federation (required)
$ ./bin/generate-keys --private-key matrix_key.pem

# Generate a self-signed certificate (optional, but a valid TLS certificate is normally
# needed for Matrix federation/clients to work properly!)
$ ./bin/generate-keys --tls-cert server.crt --tls-key server.key

# Copy and modify the config file - you'll need to set a server name and paths to the keys
# at the very least, along with setting up the database connection strings.
$ cp dendrite-sample.monolith.yaml dendrite.yaml

# Build and run the server:
$ ./bin/dendrite-monolith-server --tls-cert server.crt --tls-key server.key --config dendrite.yaml

# Create an user account (add -admin for an admin user).
# Specify the localpart only, e.g. 'alice' for '@alice:domain.com'
$ ./bin/create-account --config dendrite.yaml --url http://localhost:8008 --username alice

Then point your favourite Matrix client at http://localhost:8008 or https://localhost:8448.

Progress

We use a script called Are We Synapse Yet which checks Sytest compliance rates. Sytest is a black-box homeserver test rig with around 900 tests. The script works out how many of these tests are passing on Dendrite and it updates with CI. As of August 2022 we're at around 90% CS API coverage and 95% Federation coverage, though check CI for the latest numbers. In practice, this means you can communicate locally and via federation with Synapse servers such as matrix.org reasonably well, although there are still some missing features (like Search).

We are prioritising features that will benefit single-user homeservers first (e.g Receipts, E2E) rather than features that massive deployments may be interested in (OpenID, Guests, Admin APIs, AS API). This means Dendrite supports amongst others:

  • Core room functionality (creating rooms, invites, auth rules)
  • Room versions 1 to 10 supported
  • Backfilling locally and via federation
  • Accounts, profiles and devices
  • Published room lists
  • Typing
  • Media APIs
  • Redaction
  • Tagging
  • Context
  • E2E keys and device lists
  • Receipts
  • Push
  • Guests
  • User Directory
  • Presence

Contributing

We would be grateful for any help on issues marked as Are We Synapse Yet. These issues all have related Sytests which need to pass in order for the issue to be closed. Once you've written your code, you can quickly run Sytest to ensure that the test names are now passing.

If you're new to the project, see our Contributing page to get up to speed, then look for Good First Issues. If you're familiar with the project, look for Help Wanted issues.