Nikita, 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 Regards, Igor -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
