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

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)

0 reposts1 like

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)