Comment by cloutiertyler
16 days ago
I would encourage you to read our technical write up in reply to this article: https://spacetimedb.com/blog/benchmarking
16 days ago
I would encourage you to read our technical write up in reply to this article: https://spacetimedb.com/blog/benchmarking
Doesn't really cover the types used in the beta APIs. Nor would I expect it to though.
Is there a more technical explanation post somewhere? I'm definitely curious how it works, and I like the core idea quite a bit - I'm fairly convinced that WASM uses like this are going to grow immensely, and "it's just a global mutex/single thread" reduces complexity so much that it's always interesting to see where it's possible to use.
The latency+throughout brings many questions though, like "are you holding responding to writes and any reads that occur after until changes are written to disk" and "if so I kinda assume that change log is constantly streamed to disk with a moving high water mark for responses". I can generally see how that'd hit such benchmarks, especially with non-dirty reads being near instant, but details are always interesting.
I don't really have a deep technical explanation blog post out, but we should definitely publish one.
I can say that your last paragraph is essentially correct though. It works exactly that way.
Is there anything on how a multi-node cluster works (I'm kinda assuming there's something since it makes "single" mentions a few times)? Application-level sharding is always an option (and multiple things I've worked on have used it to great effect), but anything automatic seems likely gnarly and fun to learn about, if it recovers some of the naive perf loss of "just hold the lock while doing rpc to other nodes".
1 reply →