3 ms·

An approximate 20% reduction in bandwidth looks significant to me. I think the problem here is that the chart uses a linear scale instead of a logarithmic scale

An approximate 20% reduction in bandwidth looks significant to me. I think the problem here is that the chart uses a linear scale instead of a logarithmic scale. Looking at the data, I'm inclined to agree that not much CPU is saved, but the point of MessagePack is to save bandwidth, and it seems to be doing a good job at that.

motorest 2y ago
> An approximate 20% reduction in bandwidth looks significant to me. Significante with regards to what? Not doing anything? Flipping the toggle to compress the response?
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 ago
  In 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 ago
  Compression 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 ago
    Okay so you just use plain JSON again... In a discussion about using messagepack that doesn't really sound like messagepack is winning.
    - junon 2y ago
      A 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?

motorest 2y ago

> An approximate 20% reduction in bandwidth looks significant to me. Significante with regards to what? Not doing anything? Flipping the toggle to compress the response?

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 ago
In 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 ago
Compression 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 ago
  Okay so you just use plain JSON again... In a discussion about using messagepack that doesn't really sound like messagepack is winning.
  - junon 2y ago
    A 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?