Subnostr

nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz nostr:npub1nlk894teh248w2heuu0x8z6jjg2hyxkwdc8cxgrjtm9lnamlskcsghjm9c nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h

If you don't mind, i need some opinions/suggestions from you as experienced relay operators. Currently, i'm running custom relay, nostr-id-relay.hf.space using this following strfry.conf configuration:

https://huggingface.co/spaces/nostr-id/relay/blob/main/strfry.conf

The relay hosted in limited PaaS thus i can't modify any related system tweak such as sysctl.conf, kernel tuning, etc. I can only adjust at application level (strfry configuration and nostr-filter logic code).

What do i need to improve based on strfry.conf configuration above?

Thank you.

Btw, this is overall relay architecture flow:

Mazin 2y ago

Hey sorry for the delay in getting back to you and thanks for building as always! Only things I noticed:

- We’ve never needed to increase maxreaders above default of 256.

- I would enable noReadAhead otherwise you will start having Disk IO issues when DB size > available memory.

- I assume you are not able to set limits.conf either. You may eventually have issues if you can’t raise nofiles on the system. Usually strfry won’t start if it can’t use the nofiles limit set in the conf, so you may need to set it to 0.

Reply to this note

Please Login to reply.

Discussion

Rif'at Ahdi R 2y ago

It's ok Mazin, thank you for your suggestions. 🙂

I see. Yes, i have increased maxreaders as experiment since the relay focused as read-only relay. So not sure whether it will impact overall performance.

Oh, is it ok to leave noReadAhead same as default? I think in my case it will be ok because i have set regular cleanup data script (max 7 days retention). Also, huggingface can also occasionally restart the vm on their own so it get flushed easily before hitting memory limit 😅

Yes, it is truly limited. Unfortunately.

Mazin 2y ago

Yes and the relay will run a bit faster with noReadAhead = false. It’s only something nostr:npub1nlk894teh248w2heuu0x8z6jjg2hyxkwdc8cxgrjtm9lnamlskcsghjm9c and I saw as our DBs scaled.

Rif'at Ahdi R 2y ago

Ah, good to know, thank you. Well i think it is fine for now as the relay won't likely hit the limit

The last question might be related how you handle malicious bot traffic that open multiple websocket connection. Does the value below can help mitigate that a bit?

#Websocket-level PING message frequency (should be less than any reverse proxy idle timeouts) (restart required)

autoPingSeconds = 55

#If TCP keep-alive should be enabled (detect dropped connections to upstream reverse proxy)

enableTcpKeepalive = true

Mazin 2y ago

Shouldn’t make any difference. Websockets automatically disconnect without activity after 1 minute, so the 55 seconds auto ping will keep the sockets open even if nothing is being sent. Generally this is a good thing because you may want to keep the socket open for several minutes but only occasionally make REQs.

Malicious bot traffic will generally be sending lots of REQs (assuming they are wasting resources) not just connecting/disconnecting needlessly (although this happens with poorly made crawlers). Best way to address that is with a firewall in front of/apart of your proxy but you’ll have to see what kind of malicious traffic you get and then go from there!

Rif'at Ahdi R 2y ago

Well, it can't be helped then. Since the main routing or reverse proxy comes from Huggingface. I assume they use traefik or similar proxy with their own settings. 😅

Semi has said that i can probably handle that in application level. So, i think i really need to add that in nostr-filter as it stands as frontend proxy application before strfry

Mazin 2y ago

Yes, thats probably your best option then. Unfortunately that means extra stress on your application, but if properly designed you should be able to mitigate it. I wouldn’t expect too much malicious activity at least for now.

Rif'at Ahdi R 2y ago

Yes, thank you Mazin for all your suggestions. I really need to add that later as backlog. The last time i have checked the relay has peak of 1500+ connections, while normally around 20-30 alive connections. Thankfully it seems only affect a little bit with relay performance 😅