First impressions of Matrix: frequent lag spikes at upwards of 10+ seconds and now the server is just straight up dead
Please just use IRC, people ;_;
@sir matrix is great if you dont federate with anyone!
@sir this was my exact conclusion when I tried out Matrix. That, and the intense bugginess and bad UI of riot.im, even after 1.0-beta
@sir dunno how my server manages to stay afloat despite federating with large rooms. Have you tried to run it with PostgreSQL ?
@l4p1n I'm just using matrix.org
@sir matrix.org is heavily loaded and can lag a lot because it also runs integrations and whatnot.
Matrix being slow as heck has also been my first impression.
Since I run my own Matrix server, it doesn't feel like lagging to death / timeout ^^
@sir IRC is kind of broken as designed; the server pretty much expects to be talking directly to the user, so there are fundamental things missing, like knowing which past request an error message is a response to, or knowing whether a message you see or sent has been truncated because it was too long (or even what the length limit is)
@sir @lain @ciaby on the contrary: scaling problems are very often protocol problems, and even more often are much easier to solve by protocol changes than by implementation changes. HTTP scaled better than telnet, gopher, or FTP for protocol reasons; NNTP scaled better along some dimensions than HTTP for protocol reasons; HTTP/2 scales better than HTTP/1 for protocol reasons; TCP/IP scales better than NCP for protocol reasons; and I think, though I'm not sure, that the IRC protocol beats AP
@kaniini @sir @lain @ciaby Well, I was thinking also about AP's individual messages being a bit heavierweight than IRC's, and about it not having a native channel mechanism to limit the number of copies of a given message that any given server has to make. But at least it doesn't have netsplits, right?
@kaniini @sir @lain @ciaby The example messages in https://www.w3.org/TR/activitypub/ have 160 bytes or more of apparently mandatory per-message overhead, which is about 4× the size of an average IRC message. At the point where we hit bandwidth limits this means a 5× scalability penalty. But presumably we have to improve other bottlenecks a lot before that becomes the problem
@kaniini @sir @lain @ciaby But I was saying that the IRC protocol seemed likely to be more scalable than AP, not that AP's improvements over IRC and other messaging protocols weren't worth those putative scalability penalties. And as you probably saw in the other thread, IRC has substantial scalability problems of its own.
@lain presumably someone has done load testing? I'd like to have some kind of vague order of magnitude idea of when things start to break: on a 1000MIPS machine with 1GiB, is it when statuses are flowing in at 1 Hz, 10 Hz, 100 Hz, 1 kHz, 10 kHz, 100 kHz, 1 MHz? Is it when there are 10 clients, 100 clients, 1000 clients, 10k clients, 100k clients? Does it matter how many other servers you're directly federating with, and where does that break, roughly?
@kragen the limit is well defined and you just seem to have encountered a bad client if it doesn't split it up/tell you it's too long.
@sir your client silently corrupting your data before sending it to the server is a solution in limited circumstances, but even so, it doesn't solve the problem, just makes it less frequent; and the institutionalized behavior when you violate the well-defined limit is to undetectably corrupt your data further, which is not reasonable behavior
@kragen this is still a client problem, not a protocol problem. Like I said, the limit is well defined, if your client doesn't deal with it the way you like you should ask them to change it.
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.