We're routing requests to workers according to Tom's homeserver guide. The guide is focused on achieving high performance for a server that serves only a handful of local users.
However, our situation is different. We are hoping to have lots of local users, and they will be running Circles instead of a traditional Matrix client.
So there are a few areas where we can possibly tweak Tom's routing to good effect:
/_matrix/client/v3/joined_rooms to the user's sync worker, as it should know which rooms the user is in. Or if not, then maybe to a client reader, hashed based on the user id from the access token.
/_matrix/client/v3/profile/{userId}... to a client reader, hashed based on the user id in the URL.
similar to the above, but for profile requests over federation
/_matrix/client/v3/keys/query to a client reader, based on the user id from the access token. The intuition here is that when you send multiple encrypted messages, you will repeatedly query for the same set of users. Also there's no way to do consistent hashing based on anything else in the request.
/_matrix/client/v3/keys/changes to the user's sync worker, since it involves looking at changes since a sync token.
/_matrix/client/v3/user/{userId}/account_data/... to the user's sync worker, since it's just going to be replicated out to the user's other devices on their next sync. Or if that doesn't work, then maybe to a client reader balanced by user id.
Bigger questions:
Does it really make sense to have both sync workers AND client readers for authenticated users? Why not just load balance all non-room client requests according to the requesting user id?
Moving issue to Github. From @cvwright:
We're routing requests to workers according to Tom's homeserver guide. The guide is focused on achieving high performance for a server that serves only a handful of local users.
However, our situation is different. We are hoping to have lots of local users, and they will be running Circles instead of a traditional Matrix client.
So there are a few areas where we can possibly tweak Tom's routing to good effect:
/_matrix/client/v3/joined_roomsto the user's sync worker, as it should know which rooms the user is in. Or if not, then maybe to a client reader, hashed based on the user id from the access token./_matrix/client/v3/profile/{userId}...to a client reader, hashed based on the user id in the URL./_matrix/client/v3/keys/queryto a client reader, based on the user id from the access token. The intuition here is that when you send multiple encrypted messages, you will repeatedly query for the same set of users. Also there's no way to do consistent hashing based on anything else in the request./_matrix/client/v3/keys/changesto the user's sync worker, since it involves looking at changes since a sync token./_matrix/client/v3/user/{userId}/account_data/...to the user's sync worker, since it's just going to be replicated out to the user's other devices on their next sync. Or if that doesn't work, then maybe to a client reader balanced by user id.Bigger questions:
Does it really make sense to have both sync workers AND client readers for authenticated users? Why not just load balance all non-room client requests according to the requesting user id?