aaron on Nostr: This will depend to a significant degree on which relay implementation you are using. ...
This will depend to a significant degree on which relay implementation you are using.
If the implementation doesn't use multiple cores, then you won't see much advantage scaling out vcpus.
Also consider what db does the relay use and how do they use it? Does it support concurrent writes?
Does the relay index subscriptions so it doesn't have to iterate on every subscription each time a new event arrives?
Probably we need to improve our relay code. Very modest hardware with little concurrency should be able to support much more than 20 notes per second.
My relay runs on the smallest gcp machine (2 vcpus) and median *note* write latencies are <3ms. This is with little optimization on writes, so should be able to support a least 100s of writes/sec on basic hardware eventually.
Indexing subscriptions should mean the time to dispatch a note to subscription should remain small assuming most subscriptions are not firehose/global feed filters.
If the implementation doesn't use multiple cores, then you won't see much advantage scaling out vcpus.
Also consider what db does the relay use and how do they use it? Does it support concurrent writes?
Does the relay index subscriptions so it doesn't have to iterate on every subscription each time a new event arrives?
Probably we need to improve our relay code. Very modest hardware with little concurrency should be able to support much more than 20 notes per second.
My relay runs on the smallest gcp machine (2 vcpus) and median *note* write latencies are <3ms. This is with little optimization on writes, so should be able to support a least 100s of writes/sec on basic hardware eventually.
Indexing subscriptions should mean the time to dispatch a note to subscription should remain small assuming most subscriptions are not firehose/global feed filters.