Yes, you're right. Maybe I wasn't clear enough.
Usually server nodes are placed in the same fast network segment (one
datacenter); in any case we need an ability to setup compression per
connection using some filter like useCompression(ClusterNode, ClusterNode)
to compress traffic only between servers and client nodes.
But issue is still there, since the same NIO worker serves both client and
server connections, enabled compression may impact whole cluster performance
because NIO threads will compress client messages instead of processing
servers' compute requests. That was my concern.
Compression for clients is really cool feature and usefull in some cases.
Probably it makes sense to have two NIO servers with and without compression
to process server and client requests separately or pin somehow worker
threads to client or server sessions...
Also we have to think about client connections (JDBC, ODBC, .Net thin
client, etc) and setup compression for them separately.
Anyway I would compare put, get, putAll, getAll and SQL SELECT operations
for strings and POJOs, one server, several clients with and without
compression, setting up the server to utilize all cores by NIO workers, just
to get know possible impact.
Possible configuration for servers with 16 cores:
Selectors cnt = 16
Connections per node = 4
Where client nodes perform operations in 16 threads
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/