Replying to Avatar ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ

i tried to add some rate limiter to it and it just made it misbehave... maybe i need to refactor how i added that thing, but for now, it's functioning ok

if i get even more users, then ok, maybe i start to see more stress points, and that's great but you know what

the biggest stress point of any public facing internet server is this:

spam

i don't have this problem because i don't allow public writing to the relay, you are on my follows, or one of my follows follows, and not in my mutes, and yes you can write

amazingly, and evidence of my discrimination, i don't have a spam problem on my relay

the database is taking up about 200mb of space

it obviously is not failing to limit access
Avatar
ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 10mo ago

also, this is another point about the problem of websockets

what happens with spammers and rate limiters and sockets is if you slow down on one connection, they open another

i'm pretty sure that is what was happening, and they blew up the relay, exibit 52491 in the case against websockets for request/response APIs

Reply to this note

Please Login to reply.

Discussion

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

also, yes, changing the threading model probably would fix it in my code, so managing pings and whatnot was done in one thread, but the actual socket management data would still blow up even there, and when you consider that 2kb is the coroutine load per socket, and the socket itself is probably more than that, it was probably actually just holding that socket open that was the problem, while trying to "throttle" their requests

idk what to say, it's just a bad model, if you ask me, i'm pretty sure that there is likely myriads of historical experience relating to request/response protocols being a disaster to manage over bidirectional sockets