I'm going to write a paper comparing the various relays (speed, stability, etc.) and trying to setup similar conditions from different geographic locations and so on.
That won't be for a month or more, tho. Just wanted to get you some quick feedback and a reference.
Well, then wait for the deployment of this with geographical distribution :)
No stress.
You can also do local benchmarks to compare software performance.
Yes. We'll do a whole board of tests and the entire GitCitadel team will measure.
Suspect everyone will be quite fast, but some will be faster than others.
But we also want to test stuff like stability, reliability, filtering capabilities, and general QC stuff like cataloging, caching and storing, and comparing functionality and administration possibilities.
nostr:nprofile1qqspdudqzqx5ellme3prp68qus5se3vynsddcexkv5la5p7qxxcswjcprdmhxue69uhhw6r9v96zu6rpwpc8jarpwejhym3wvdhj7qgnwaehxw309ac82unsd3jhqct89ejhxtcpzdmhxue69uhk7enxvd5xz6tw9ec82c30hq9nk4 I will also include wheat.
Very curious to see how grain compares.
my relay runs on a 2 vCPU, 2gb ram VPS in bulgaria with 4gb of swap configured just to stop it blowing up and having to restart, although i've never seen it blow out the memory so far (not been monitoring it that close either tho)
i think you should definitely compare the resources in the deployments, if they are using a lot more memory and storage then of course they are going to have lower latency
it is tradeoffs all the way down.
it uses more resources as a baseline, yes, but it becomes more efficient than other relay implementations at scale.
have you actually used realy yet?
it seems to be running flawlessly on 1 core 1gb memory no swap, though my deployment has 2gb and 2 cores now, the times i have looked at what it actually uses it's really doing well considering i have several other services on the machine
no.
the type of deployment I’m intending needs geographical distribution, a lot of extensibility, and fault tolerance
so, you are aiming for low latency and availability
these are not metrics that have a big factor of the relay's code quality in them, more about the quality of servers you are running on
as for extensibility
lol, you will extend realy in a matter of days and even less if you already have Go experience
i don't shit on the popular languages for nothing, they are all hard to learn, complicated, cost a lot in development and are slow in the test cycle
the underlying DB matters too, in this case, it uses an external K/V DB that handles scaling, and can distribute load to multiple servers instead of one disk
which allows scaling way higher than 1 server’s disk or CPU
the amount of latency added is negligible compared to a local DB
i can see how that would be a plus... i have pondered a lot the idea of making relays able to use othre relays as second level stores, i already wrote the code so that whatever comes back from the layer2 is cached and is found faster from the relay event store
also, yeah, K/V stores are the best... it's really not worth the time to market advantage of generalised sql/graph databases unless the data really is of the kind those DB architectures are faster for
for nostr, KV is teh only way, the indexes are super simple and there's just no reason to extend it unless you want to implement this "DVM" bullshit, which is really just fucking full text search and maybe image/video classifier shit that AIs could probably help with
people are so hyped about AI but really it only improves image, voice and video recognition, that's good, and all, but lol, it's not skynet, gimme a break, fucking morons in fiat corporate VC land
I will check out realy, at least for replacing parts of go-nostr and khatru as I don’t really like it
NFDB is just an event store, the extensibility part is for modifying the query pipeline and indexing
the indexes use a fully pluggable provider, and it is really easy to change things, such as to add search indexes
We may create our own test installations, to see how different environments impact the relays.
We'll need to think this through. The paper should have results that can be independently confirmed by repeating the test.
I do this sort of thing at work, for big databases, so this is me actually being useful, for once.
