Post

learned so far: - 4 cores seems _enough to run_ but on this particular host it’s kind of marginal. 16GB ram seems plenty. - it’s been dropping pds websockets, and doesn’t seem to recover on its own. not sure why. - bandwidth is less than i was expecting. - +jetstream on this server is too much

fig (aka:[phil])@bad-example.com

kinda still a relay noob but uh i think it’s doing the thing non-us jurisdiction (montreal) non-us-company-cloud-provider relay. chillin.

- pds backfill is rough on this server, cpu pegs 100% - made worse by having jetstream on the same server trying to do a higher event rate - also interesting: jetstream just crashes when it’s relay websocket closes? fine if the supervisor auto-restarts it i guess.

- 4 shared cores on a 2017-era 2ghz epyc is not enough for a relay. could probably tune some things to get it there—seeing significant overhead from userspace networking + logging—but i def want more performance margin than this. for $5.5CAD i can get two more shared cores, or double that for 8

did you have to do anything special to get this working with pdsls? I have Caddy fronting one and it works with websocat but not with pdsls

0 reposts2 likes

actually yes! two things, thank you for reminding me. 1. tls. assume you’re set since caddy 2. dropping the origin header in the reverse proxy. i haven’t dug into why exactly but the relay didn’t like it when a request included the origin.

like it kind of makes sense— if you ship an app that gets people to connect to a relay from browser, something is probably not right. …but pdsls works with prod so i think rainbow must allow it (again fair i guess)

for nginx this is proxy_set_header Origin ""; and i’m curious to see how caddy goes for you! it fell over on the last medium-throughput thing i tried to do (but i’m always trying to get away with too-small machines)