Nostr

i'm surprised how fast it's saying the events were published tho. if you use the import tool on a trove of events of around 117k, it takes about 15 seconds to swallow the whole lot, which means it's more like 8000 events/s

but maybe you have faster, next generation hardware, my pc has like 3 years ago tech in it. i've used a hetzner server that was about 3-4x faster at everything in my recent previous project with a large database iteration (comparing a set of 1000 records to each other, N(N-1) operations, something like, what was it, 400,000 operations in total. this included standard library JSON decoding. i was going to optimize that stuff with a decoder cache but it was working well enough for processing one row at a time.

Kyle 🐆 5mo ago

Those benchmarks are just for encoding/decoding in memory. The 8k/s import speed includes database writes, which are way slower than pure codec operations.

Reply to this note

Please Login to reply.

Discussion

Kyle 🐆 5mo ago

nostr:nprofile1qythwumn8ghj7mtvv44h2tnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnzv9hxgtcqypxgqqjh5ky2s2zf6pyczlptm2kesje953ddnak66ehy05a50caj75ukn0y if helpful, I can add a note in the benchmark docs clarifying this.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

what i was more so interested in was a tool that you run the relay and it hurls events at it and then queries it and times the full operation. such a tester could be pointed at any relay implementation then. certainly then you could add a script that builds and installs khatru and relayer, and probably since the secp256k1 library install script in scripts puts all the C/C++ things in, probably can also do strfry and the rust relay as well, by adding a rustup installer

i might do it myself at some point but feel free to do it if you like. it shouldn't be hard to add this to it.

seeing a side by side comparison of all of the relays would be great for seeing how good performance is but also how good each different relay is in comparison with each other on the same test workloads.

Kyle 🐆 5mo ago

That's interesting... I'll work on this.

Kyle 🐆 5mo ago

nostr:nprofile1qythwumn8ghj7mtvv44h2tnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnzv9hxgtcqypxgqqjh5ky2s2zf6pyczlptm2kesje953ddnak66ehy05a50caj75ukn0y I put up an initial PR for this, let me know what you think. https://github.com/mleku/orly/pull/8

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

i couldn't get it to all run, anyway, as we discussed, when it's all wrapped in a docker it will work for everyone.

now i've removed all those pesty serialization calls in the logging into closure logs, when logging is at default, it will go as fast as it can go.

i'm really curious to see how that works. i'm also curious how it comes to be that relayer is so freakin slow. and lol strfry. really. my goodness it's awful, and it's one of the most commonly deployed relays? wow.

probably lucky we haven't had the massive influx that some keep on complaining about.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

ah.

still, that's incredibly fast. i knew they were fast because i already wrote a benchmark for the json and binary codecs and they take tens of microseconds on my hardware.

damn, now i dang want an upgrade of my mobo/ram/cpu