2 ms·
> An approximate 20% reduction in bandwidth looks significant to me. To me it doesn't. There's compression for much bigger gains. Or just, you know, just send
by tasuki 2y ago
> An approximate 20% reduction in bandwidth looks significant to me.
To me it doesn't. There's compression for much bigger gains. Or just, you know, just send less data?
I've worked at a place where our backend regularly sent humongous jsons to all the connected clients. We were all pretty sure this could be reduced by 95%. But, who would try to do that? There wasn't a business case. If someone tried succeeded, no one would notice. If someone tried and broke something, it'd look bad. So, status quo...
- bythreads 2y agoIn a system that requires the absolute speediest throughput compression is actually usually the worst thing in a parsechain - so parsing without first decompression is valuable. I've tried messagepack a few times, but to be honest the hassle of the debugging was never really worth it
- junon 2y agoCompression is a performance killer for intra-DC communication. You typically avoid it at all costs when doing RPC within the same AZ/DC. Thus, the only thing you can do after that to improve performance is to reduce bytes on the wire.
- imtringued 2y agoOkay so you just use plain JSON again... In a discussion about using messagepack that doesn't really sound like messagepack is winning.
- junon 2y agoA 20% reduction of bytes on the wire is not losing. 99.9999999% of the data sent across the network in that Datacenter will never be read by humans directly. Why put it into a textual form?