Monitoring perMessageDeflate performance?

[nathanieltagg]

Is there any way for me to see the achieved compression ratio for messages? (Also, is there any way to measure the time it takes to do compression, or other system resources?)

I've got an application where I'm moving large data payloads, with data of 10s of MB. So far, I've been doing one massive AJAX pull, but I'm thinking of moving to a more incremental transfer using websockets. But it's considerably more complicated, and performance has to be reasonably comparable before I convert.

Thank you for the wonderful code.

[lpinca]

Is there any way for me to see the achieved compression ratio for messages? (Also, is there any way to measure the time it takes to do compression, or other system resources?)

There is no built-in way to do that and it really depends on the parameters that are used and negotiated during the handshake (context takeover, window bits, etc.). Internally an inflate stream per socket is used so that could be used in isolation to get an esteem of compression ratio and performance overhead.

There is also an unresolved problem with Node.js raw inflate streams on some platforms, see nodejs/node#8871 for more details. We work around that problem with the concurrencyLimit option which mitigates the issue a bit.

For performance I think it's better to keep permessage-deflate disabled if bandwidth is not a problem but yes, it should be tested with real data and a realistic load in terms of connected sockets on the server.

[lpinca]

Closing as answered, discussion can continue if needed.