This cache can serve invalid responses, and has an extremely low hit
rate.
It serves invalid responses because because it's only keyed off
the `since` parameter, but many of the other request parameters also
affect the response or it's side effects. This will become worse once we
implement filtering, because there will be a wider space of parameters
with different responses. This problem is fixable, but not worth it
because of the low hit rate.
The low hit rate is because normal clients will always issue the next
sync request with `since` set to the `prev_batch` value of the previous
response. The only time we expect to see multiple requests with the same
`since` is when the response is empty, but we don't cache empty
responses.
This was confirmed experimentally by logging cache hits and misses over
15 minutes with a wide variety of clients. This test was run on
matrix.computer.surgery, which has only a few active users, but a
large volume of sync traffic from many rooms. Over the test period, we
had 3 hits and 5309 misses. All hits occurred in the first minute, so I
suspect that they had something to do with client recovery from an
offline state. The clients that were connected during the test are:
- element web
- schildichat web
- iamb
- gomuks
- nheko
- fractal
- fluffychat web
- fluffychat android
- cinny web
- element android
- element X android
Fixes: #2
This change is fully automated, except the `rustfmt.toml` changes and
a few clippy directives to allow specific functions with too many lines
because they are longer now.
I manually expanded the HTML into a more readable format, the rest was
rustfmt's doing. It's beyond me why/how someone would willing write a
pile of HTML like that...
I would've preferred to factor these out into their own functions, but
unfortunately the inner type of the `FuturesUnordered` is unnameable.
`Box` or TAIT would help, but the former has a performance cost and the
latter doesn't exist on stable yet.
Doing this will allow `rustfmt` to collapse lines more efficiently.
Specifically, a lot of these lines fail to wrap to 80 columns without
these changes.
This makes it possible to deploy Grapevine while using a database
originally created by Conduit, including leaving the admin bot user's
localpart the same as before.
This prevents us from needing to recompile the dependencies when that
environment variable changes, which generally changes on every commit,
which is far more frequently than the dependencies are actually changed.
Users of the nix package can now just use `.override` to choose what
features they want.
This also makes RocksDB automatically use jemalloc when Grapevine is
configured to use jemalloc.
This fixes the problem where some artifacts were not being cached when
they should have been. The secret sauce is the `nix-store` command.
Also stops emitting artifacts to GitLab. Automatic build scheduling via
Nix is too convenient. Maybe I'll figure out a way to do both later on.
Also pins the remaining unpinned dependencies, namely direnv and
nix-direnv.
I'm turning off the documentation related ones because they generate
way too many warnings, this kind of thing will need to be improved over
a longer timespan.
Functions using `services()` are allowed to pointlessly take `self`
because the existence of `services()` is a crime and the solution is
making the types store references to their dependencies and then going
through `self`, so just allowing the lint saves us from modifying some
code only to switch it back later. Much later. Getting rid of
`services()` will probably be an ordeal.
