You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by "Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com> on 2017/11/22 07:04:03 UTC
Transport compression (not store compression)
Hi Igniters,
I see there is a lot of discussion in certain threads about compression. This seems to have diverged into conversations about object versus field compression, and even throwing encryption into the mix. For my use case, I am not interested in compressing the cache stored in memory, I have plenty of memory for my application. What I don't have is a good network. I have a high latency, low bandwidth network between my C# ignite client and my Java ignite server. I only want to compress data when it is sent over the network to remote nodes. It should be stored in the local memory uncompressed. How can we achive this? Can the TcpCommunicationSpi support compression?
Thanks,
Gordon.
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Vladimir Ozerov, I also agree that your solution is good.
I will check this flag before adding a client to map of clients. If one of
the nodes have the flag then the session will be marked "compressed". At
the nearest time, I will provide a solution.
Dmitriy Setrakyan, I will implement and test compressed flag after I write
test with real operations (put, get etc) on yardstick.
2018-02-16 0:05 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> Vova, I think your solution is fine, but I think we will always have some
> messages compressed and others not. For example, in many cases, especially
> when messages are relatively small, compressing them will introduce an
> unnecessary overhead, and most likely slow down the cluster.
>
> Why not have compression flag or compression bit on per-message level? We
> check if the bit is turned on, and if it is, then we uncompress the message
> on the receiving side before processing it.
>
> D.
>
> On Thu, Feb 15, 2018 at 12:24 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > I think that we should not guess on how the clients are used. They could
> be
> > used in any way - in the same network, in another network, in Docker, in
> > hypervisor, etc.. This holds for both thin and thick clients. It is
> > essential that we design configuration API in a way that compression
> could
> > be enabled only for some participants.
> >
> > What if we do this as follows:
> > 1) Define "IgniteConfiguration.compressionEnabled" flag
> > 2) When two nodes communicate and at least one of them has this flag,
> then
> > all data sent between them is compressed.
> >
> > Makes sense?
> >
> > On Thu, Feb 15, 2018 at 8:50 AM, Nikita Amelchev <ns...@gmail.com>
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > I have not seen such use-cases, where heavy client ignite node placed
> in
> > a
> > > much worse network than the server. I'm not sure we should encourage a
> > bad
> > > cluster architecture.
> > >
> > > Usually, in my use-cases, the servers and clients locate in the same
> > > network. And if the cluster has SSL enabled, it makes sense to enable
> > > compression, even if the network is fast. It also makes sense when we
> > have
> > > a high load on the network, and the CPU is utilized poorly.
> > >
> > > I'll do tests on yardstick for real operations like get, put etc. and
> SQL
> > > requests.
> > >
> > > I propose to add configurable compression for thin client/ODBC/JDBC as
> a
> > > separate issue because it increases the current PR.
> > >
> > > Even if it really makes sense to compress the traffic only between
> > > client-server ignite nodes, it should also be a separate issue, that
> > would
> > > not increase the PR. Especially, since this compression architecture
> may
> > > not be accepted by the community.
> > >
> > > 2018-02-05 13:02 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> > >
> > > > Thanks for your comments,
> > > >
> > > > I will try to separate network compression for clients and servers.
> > > >
> > > > It makes sense to enable compression on servers if we have SSL turned
> > on.
> > > > I tested rebalancing time and compression+ssl is faster. SSL
> throughput
> > > is
> > > > limited by 800 Mbits/sec per connection and if enable compression, it
> > > > boosted up to 1100 Mbits.
> > > >
> > > > 2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> > > >
> > > >> I think Igor is right.
> > > >>
> > > >> Ususally servers connected via fast local network.
> > > >> But clients could be in external and slow network.
> > > >> In this scenario compression will be very useful.
> > > >>
> > > >> Once I had such scenario - client connected to cluster via 300 kb/s
> > > >> network
> > > >> and tries to transfer ~10Mb of uncumpressed data.
> > > >> So it takse ~30 seconds.
> > > >> After I implemented compression it becamed 1M and transfered for ~3
> > > >> seconds.
> > > >>
> > > >> I think we should take care of all mentioned problems with NIO
> threads
> > > in
> > > >> order to not slow down whole cluster.
> > > >>
> > > >>
> > > >> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com>
> > > wrote:
> > > >>
> > > >> > 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/
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Alexey Kuznetsov
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Feb 16, 2018 at 4:22 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> Dmitry,
>
> IMO we should not compress individual messages. Instead, we should compress
> stream of enqueued messages. This way we will reduce number of array
> copying and improve performance. Makes sense?
>
Yes, it does, as long as we can have a stream of uncompressed messages as
well.
Re: Transport compression (not store compression)
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Dmitry,
IMO we should not compress individual messages. Instead, we should compress
stream of enqueued messages. This way we will reduce number of array
copying and improve performance. Makes sense?
On Fri, Feb 16, 2018 at 12:05 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> Vova, I think your solution is fine, but I think we will always have some
> messages compressed and others not. For example, in many cases, especially
> when messages are relatively small, compressing them will introduce an
> unnecessary overhead, and most likely slow down the cluster.
>
> Why not have compression flag or compression bit on per-message level? We
> check if the bit is turned on, and if it is, then we uncompress the message
> on the receiving side before processing it.
>
> D.
>
> On Thu, Feb 15, 2018 at 12:24 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
>
> > I think that we should not guess on how the clients are used. They could
> be
> > used in any way - in the same network, in another network, in Docker, in
> > hypervisor, etc.. This holds for both thin and thick clients. It is
> > essential that we design configuration API in a way that compression
> could
> > be enabled only for some participants.
> >
> > What if we do this as follows:
> > 1) Define "IgniteConfiguration.compressionEnabled" flag
> > 2) When two nodes communicate and at least one of them has this flag,
> then
> > all data sent between them is compressed.
> >
> > Makes sense?
> >
> > On Thu, Feb 15, 2018 at 8:50 AM, Nikita Amelchev <ns...@gmail.com>
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > I have not seen such use-cases, where heavy client ignite node placed
> in
> > a
> > > much worse network than the server. I'm not sure we should encourage a
> > bad
> > > cluster architecture.
> > >
> > > Usually, in my use-cases, the servers and clients locate in the same
> > > network. And if the cluster has SSL enabled, it makes sense to enable
> > > compression, even if the network is fast. It also makes sense when we
> > have
> > > a high load on the network, and the CPU is utilized poorly.
> > >
> > > I'll do tests on yardstick for real operations like get, put etc. and
> SQL
> > > requests.
> > >
> > > I propose to add configurable compression for thin client/ODBC/JDBC as
> a
> > > separate issue because it increases the current PR.
> > >
> > > Even if it really makes sense to compress the traffic only between
> > > client-server ignite nodes, it should also be a separate issue, that
> > would
> > > not increase the PR. Especially, since this compression architecture
> may
> > > not be accepted by the community.
> > >
> > > 2018-02-05 13:02 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> > >
> > > > Thanks for your comments,
> > > >
> > > > I will try to separate network compression for clients and servers.
> > > >
> > > > It makes sense to enable compression on servers if we have SSL turned
> > on.
> > > > I tested rebalancing time and compression+ssl is faster. SSL
> throughput
> > > is
> > > > limited by 800 Mbits/sec per connection and if enable compression, it
> > > > boosted up to 1100 Mbits.
> > > >
> > > > 2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> > > >
> > > >> I think Igor is right.
> > > >>
> > > >> Ususally servers connected via fast local network.
> > > >> But clients could be in external and slow network.
> > > >> In this scenario compression will be very useful.
> > > >>
> > > >> Once I had such scenario - client connected to cluster via 300 kb/s
> > > >> network
> > > >> and tries to transfer ~10Mb of uncumpressed data.
> > > >> So it takse ~30 seconds.
> > > >> After I implemented compression it becamed 1M and transfered for ~3
> > > >> seconds.
> > > >>
> > > >> I think we should take care of all mentioned problems with NIO
> threads
> > > in
> > > >> order to not slow down whole cluster.
> > > >>
> > > >>
> > > >> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com>
> > > wrote:
> > > >>
> > > >> > 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/
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Alexey Kuznetsov
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Best wishes,
> > > > Amelchev Nikita
> > > >
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
>
Re: Transport compression (not store compression)
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Vova, I think your solution is fine, but I think we will always have some
messages compressed and others not. For example, in many cases, especially
when messages are relatively small, compressing them will introduce an
unnecessary overhead, and most likely slow down the cluster.
Why not have compression flag or compression bit on per-message level? We
check if the bit is turned on, and if it is, then we uncompress the message
on the receiving side before processing it.
D.
On Thu, Feb 15, 2018 at 12:24 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> I think that we should not guess on how the clients are used. They could be
> used in any way - in the same network, in another network, in Docker, in
> hypervisor, etc.. This holds for both thin and thick clients. It is
> essential that we design configuration API in a way that compression could
> be enabled only for some participants.
>
> What if we do this as follows:
> 1) Define "IgniteConfiguration.compressionEnabled" flag
> 2) When two nodes communicate and at least one of them has this flag, then
> all data sent between them is compressed.
>
> Makes sense?
>
> On Thu, Feb 15, 2018 at 8:50 AM, Nikita Amelchev <ns...@gmail.com>
> wrote:
>
> > Hello, Igniters.
> >
> > I have not seen such use-cases, where heavy client ignite node placed in
> a
> > much worse network than the server. I'm not sure we should encourage a
> bad
> > cluster architecture.
> >
> > Usually, in my use-cases, the servers and clients locate in the same
> > network. And if the cluster has SSL enabled, it makes sense to enable
> > compression, even if the network is fast. It also makes sense when we
> have
> > a high load on the network, and the CPU is utilized poorly.
> >
> > I'll do tests on yardstick for real operations like get, put etc. and SQL
> > requests.
> >
> > I propose to add configurable compression for thin client/ODBC/JDBC as a
> > separate issue because it increases the current PR.
> >
> > Even if it really makes sense to compress the traffic only between
> > client-server ignite nodes, it should also be a separate issue, that
> would
> > not increase the PR. Especially, since this compression architecture may
> > not be accepted by the community.
> >
> > 2018-02-05 13:02 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> >
> > > Thanks for your comments,
> > >
> > > I will try to separate network compression for clients and servers.
> > >
> > > It makes sense to enable compression on servers if we have SSL turned
> on.
> > > I tested rebalancing time and compression+ssl is faster. SSL throughput
> > is
> > > limited by 800 Mbits/sec per connection and if enable compression, it
> > > boosted up to 1100 Mbits.
> > >
> > > 2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> > >
> > >> I think Igor is right.
> > >>
> > >> Ususally servers connected via fast local network.
> > >> But clients could be in external and slow network.
> > >> In this scenario compression will be very useful.
> > >>
> > >> Once I had such scenario - client connected to cluster via 300 kb/s
> > >> network
> > >> and tries to transfer ~10Mb of uncumpressed data.
> > >> So it takse ~30 seconds.
> > >> After I implemented compression it becamed 1M and transfered for ~3
> > >> seconds.
> > >>
> > >> I think we should take care of all mentioned problems with NIO threads
> > in
> > >> order to not slow down whole cluster.
> > >>
> > >>
> > >> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com>
> > wrote:
> > >>
> > >> > 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/
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Alexey Kuznetsov
> > >>
> > >
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>
Re: Transport compression (not store compression)
Posted by Vladimir Ozerov <vo...@gridgain.com>.
I think that we should not guess on how the clients are used. They could be
used in any way - in the same network, in another network, in Docker, in
hypervisor, etc.. This holds for both thin and thick clients. It is
essential that we design configuration API in a way that compression could
be enabled only for some participants.
What if we do this as follows:
1) Define "IgniteConfiguration.compressionEnabled" flag
2) When two nodes communicate and at least one of them has this flag, then
all data sent between them is compressed.
Makes sense?
On Thu, Feb 15, 2018 at 8:50 AM, Nikita Amelchev <ns...@gmail.com>
wrote:
> Hello, Igniters.
>
> I have not seen such use-cases, where heavy client ignite node placed in a
> much worse network than the server. I'm not sure we should encourage a bad
> cluster architecture.
>
> Usually, in my use-cases, the servers and clients locate in the same
> network. And if the cluster has SSL enabled, it makes sense to enable
> compression, even if the network is fast. It also makes sense when we have
> a high load on the network, and the CPU is utilized poorly.
>
> I'll do tests on yardstick for real operations like get, put etc. and SQL
> requests.
>
> I propose to add configurable compression for thin client/ODBC/JDBC as a
> separate issue because it increases the current PR.
>
> Even if it really makes sense to compress the traffic only between
> client-server ignite nodes, it should also be a separate issue, that would
> not increase the PR. Especially, since this compression architecture may
> not be accepted by the community.
>
> 2018-02-05 13:02 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
>
> > Thanks for your comments,
> >
> > I will try to separate network compression for clients and servers.
> >
> > It makes sense to enable compression on servers if we have SSL turned on.
> > I tested rebalancing time and compression+ssl is faster. SSL throughput
> is
> > limited by 800 Mbits/sec per connection and if enable compression, it
> > boosted up to 1100 Mbits.
> >
> > 2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> >
> >> I think Igor is right.
> >>
> >> Ususally servers connected via fast local network.
> >> But clients could be in external and slow network.
> >> In this scenario compression will be very useful.
> >>
> >> Once I had such scenario - client connected to cluster via 300 kb/s
> >> network
> >> and tries to transfer ~10Mb of uncumpressed data.
> >> So it takse ~30 seconds.
> >> After I implemented compression it becamed 1M and transfered for ~3
> >> seconds.
> >>
> >> I think we should take care of all mentioned problems with NIO threads
> in
> >> order to not slow down whole cluster.
> >>
> >>
> >> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com>
> wrote:
> >>
> >> > 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/
> >> >
> >>
> >>
> >>
> >> --
> >> Alexey Kuznetsov
> >>
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hello, Igniters.
I have not seen such use-cases, where heavy client ignite node placed in a
much worse network than the server. I'm not sure we should encourage a bad
cluster architecture.
Usually, in my use-cases, the servers and clients locate in the same
network. And if the cluster has SSL enabled, it makes sense to enable
compression, even if the network is fast. It also makes sense when we have
a high load on the network, and the CPU is utilized poorly.
I'll do tests on yardstick for real operations like get, put etc. and SQL
requests.
I propose to add configurable compression for thin client/ODBC/JDBC as a
separate issue because it increases the current PR.
Even if it really makes sense to compress the traffic only between
client-server ignite nodes, it should also be a separate issue, that would
not increase the PR. Especially, since this compression architecture may
not be accepted by the community.
2018-02-05 13:02 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> Thanks for your comments,
>
> I will try to separate network compression for clients and servers.
>
> It makes sense to enable compression on servers if we have SSL turned on.
> I tested rebalancing time and compression+ssl is faster. SSL throughput is
> limited by 800 Mbits/sec per connection and if enable compression, it
> boosted up to 1100 Mbits.
>
> 2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
>
>> I think Igor is right.
>>
>> Ususally servers connected via fast local network.
>> But clients could be in external and slow network.
>> In this scenario compression will be very useful.
>>
>> Once I had such scenario - client connected to cluster via 300 kb/s
>> network
>> and tries to transfer ~10Mb of uncumpressed data.
>> So it takse ~30 seconds.
>> After I implemented compression it becamed 1M and transfered for ~3
>> seconds.
>>
>> I think we should take care of all mentioned problems with NIO threads in
>> order to not slow down whole cluster.
>>
>>
>> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com> wrote:
>>
>> > 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/
>> >
>>
>>
>>
>> --
>> Alexey Kuznetsov
>>
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Thanks for your comments,
I will try to separate network compression for clients and servers.
It makes sense to enable compression on servers if we have SSL turned on. I
tested rebalancing time and compression+ssl is faster. SSL throughput is
limited by 800 Mbits/sec per connection and if enable compression, it
boosted up to 1100 Mbits.
2018-02-02 18:52 GMT+03:00 Alexey Kuznetsov <ak...@apache.org>:
> I think Igor is right.
>
> Ususally servers connected via fast local network.
> But clients could be in external and slow network.
> In this scenario compression will be very useful.
>
> Once I had such scenario - client connected to cluster via 300 kb/s network
> and tries to transfer ~10Mb of uncumpressed data.
> So it takse ~30 seconds.
> After I implemented compression it becamed 1M and transfered for ~3
> seconds.
>
> I think we should take care of all mentioned problems with NIO threads in
> order to not slow down whole cluster.
>
>
> On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com> wrote:
>
> > 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/
> >
>
>
>
> --
> Alexey Kuznetsov
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Alexey Kuznetsov <ak...@apache.org>.
I think Igor is right.
Ususally servers connected via fast local network.
But clients could be in external and slow network.
In this scenario compression will be very useful.
Once I had such scenario - client connected to cluster via 300 kb/s network
and tries to transfer ~10Mb of uncumpressed data.
So it takse ~30 seconds.
After I implemented compression it becamed 1M and transfered for ~3 seconds.
I think we should take care of all mentioned problems with NIO threads in
order to not slow down whole cluster.
On Fri, Feb 2, 2018 at 10:05 PM, gvvinblade <gv...@gmail.com> wrote:
> 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/
>
--
Alexey Kuznetsov
Re: Transport compression (not store compression)
Posted by gvvinblade <gv...@gmail.com>.
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/
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Thanks for your comments,
1. At first, I would define final design and then I will make it pluggable.
2. We cannot prioritize messages at this network communication level. If
compression utilizes processor poorly then we can increase count of
selectors (make more threads when compression enabled).
These benchmarks show how much bytes and time will be saved on transfer
messages with different length and regularity. Tests provide data which
have a simple physical meaning. The use of "real" operations will give the
unstable result and will change as you change the implementation of these
"real" operations. Test that generated a lot of puts will also be
synthetic, just like any other.
However, I can try to come up with yardstick test with operations like a
real case. What will we test? Do we test putAll + getAll with text data?
2018-01-25 13:23 GMT+03:00 gvvinblade <gv...@gmail.com>:
> Nikita,
>
> I took a look at the changes and see two issues.
>
> The first one is additional dependencies in core module. That means you
> should whether make the filter plugable and provide some additional module
> for it or put all the necessary classes to ignite-core.
>
> The second is possible bottleneck in NIO threads. Since each worker serves
> several connections we may face troubles on big clusters (for example one
> or
> two ignite server nodes and a few dozens client nodes) because
> compression/decompression is an expensive operation and happens (in your
> implementation) in NIO threads where message processing becames sequential.
>
> The provided benchmarks are quite synthetic (they are local, they involve
> only two nodes, they don't use "real" operations like put, get, putAll etc
> and don't show a real picture)
>
> We have to be careful with such changes and check all possible scenarios.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by gvvinblade <gv...@gmail.com>.
Nikita,
I took a look at the changes and see two issues.
The first one is additional dependencies in core module. That means you
should whether make the filter plugable and provide some additional module
for it or put all the necessary classes to ignite-core.
The second is possible bottleneck in NIO threads. Since each worker serves
several connections we may face troubles on big clusters (for example one or
two ignite server nodes and a few dozens client nodes) because
compression/decompression is an expensive operation and happens (in your
implementation) in NIO threads where message processing becames sequential.
The provided benchmarks are quite synthetic (they are local, they involve
only two nodes, they don't use "real" operations like put, get, putAll etc
and don't show a real picture)
We have to be careful with such changes and check all possible scenarios.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hello, Igniters!
I implement network compression as described earlier [1]. I implemented
Zstd, LZ4, and Deflater [2, 3]. LZ4 have good speed (1.2 G/s per
connection) but compression ratio is not more than 2. Zstd has good
compression ratio, up to 5, but relatively slow throughputs (0.28 G/s per
connection). In addition, we boost SSL throughput from 0.8 G/s up to 1.0
G/s, because we encrypt fewer data.
Alexander (sharplermc@gmail.com) has developed benchmarks for a network.
They measure effective and real throughput, compression ratio, and latency.
The test generates data with a structure similar to natural language. At
first, generated "words" of lengths from the Poisson distribution. Each
word is a byte array filled randomly. These "words" form a "language" that
is being added to the buffer by Zipf's law distribution until the buffer is
full.
In case SSL is turned on results follow:
On 500kb messages, Zstd shows best results per thread (Real throughput
0.202 G/s, compression ratio 5), LZ4 is second (Real throughput 0.498 G/s,
compression ratio 1.92). A base throughput of SSL is 0.76 G/s. Enabling
Zstd compression boosts effective throughput up to 30%. LZ4 - to 26%.
On 1kb messages, Zstd shows best results per thread (Real throughput 0.042
G/s, compression ratio 2.5), LZ4 is second (Real throughput 0.065 G/s,
compression ratio 1.74). A real throughput of SSL is 0.107 G/s. Enabling
LZ4 compression boosts effective throughput up to 6%. Zstd only compresses
the data.
These are good results even if a network is not fully utilized. Throughput
can be boosted up to several times if network speed is limited. I wrote the
result into comments of the issue [1].
Now I cover code with tests.
Any thoughts?
1. https://issues.apache.org/jira/browse/IGNITE-7024
2. https://reviews.ignite.apache.org/ignite/review/IGNT-CR-467
3. https://github.com/apache/ignite/pull/3101/files
2017-11-30 13:00 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> I would start with communication only, and put discovery and clients aside
> for now. Let's confirm that communication works well with compression first
> in terms of performance.
>
> On Thu, Nov 30, 2017 at 10:36 AM, Nikita Amelchev <ns...@gmail.com>
> wrote:
>
> > Hello, everybody.
> > I propose the following design for network compression.
> >
> > I suggest to implement it like SSL implementation that already works. I
> add
> > compression filter to a chain of NIO filters. It changes the logic of
> > TcpCommunicationSpi.safeTcpHandshake() and
> > DirectNioClientWorker.processWrite() methods, where depending on whether
> > SSL and/or compression are turned on we compress and/or encrypt data and
> > messages using compress handler. Also, I will use application buffer
> > (implemented in "GridNioCompressHandler") for decompressing.
> >
> > For compression verification, I have to write the header with a length of
> > compressed data (or get it from an algorithm headers) and a flag of
> > compression disabled (for small messages). When we are reading compressed
> > data from a channel, we check length, the same way as an isInboundDone
> flag
> > is checked in SSL implementation. It is conveniently to implement this
> flag
> > in "CompressEngine" with wrap and unwrap methods for compress and
> > decompress to byte buffer. Compression settings should be placed in a
> > configuration (Ignite configuration/discovery SPI and
> > GridClientConfiguration).
> >
> > Any thoughts?
> >
> >
> > 2017-11-28 10:39 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> >
> > > Hi,
> > > I've filed a ticket [1]. I'll try to share design details in a couple
> of
> > > days.
> > >
> > > 1. https://issues.apache.org/jira/browse/IGNITE-7024
> > >
> > > 2017-11-23 18:31 GMT+03:00 Denis Magda <dm...@apache.org>:
> > >
> > >> Nikita,
> > >>
> > >> Sounds like a good plan. Please share the design details prior getting
> > >> down to the implementation.
> > >>
> > >> —
> > >> Denis
> > >>
> > >> > On Nov 23, 2017, at 4:38 AM, Nikita Amelchev <ns...@gmail.com>
> > >> wrote:
> > >> >
> > >> > Hi Igniters!
> > >> >
> > >> > I’m working on the similar feature for my own project.
> > >> > I would like to suggest use in-line compression and write encoded
> > bytes
> > >> in
> > >> > network channel by bytes array buffer. It allows us avoiding
> expensive
> > >> > memory allocation.
> > >> > The described design may be implemented in TcpCommunicationSpi
> level.
> > We
> > >> > can introduce pluggable compressor on TCP level where we will be
> able
> > to
> > >> > describe our compression strategy, for example, exclude some small
> > >> messages
> > >> > and many other.
> > >> >
> > >> > If the community doesn't mind I will file the ticket and will start
> > >> > implementing it.
> > >> > Any thoughts?
> > >> >
> > >> > 2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > >> >
> > >> >> Denis,
> > >> >>
> > >> >> Regarding zipped marshaller - this would be inefficient, because
> > >> >> compression rate will be lower.
> > >> >>
> > >> >> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org>
> > >> wrote:
> > >> >>
> > >> >>> Nikita,
> > >> >>>
> > >> >>> Your solution sounds reasonable from the first glance. However,
> the
> > >> >>> communication layer processes a dozen of small system messages
> that
> > >> >> should
> > >> >>> be excluded from the compression. Guess, that we will spend more
> > time
> > >> on
> > >> >>> compressing/decompressing them thus diminishing the positive
> effect
> > of
> > >> >> the
> > >> >>> compression.
> > >> >>>
> > >> >>> Alexey K., Vladimir O.,
> > >> >>>
> > >> >>> What if we create Zip version of the binary marshaller the same
> way
> > we
> > >> >>> implemented GridClientZipOptimizedMarshaller?
> > >> >>>
> > >> >>> —
> > >> >>> Denis
> > >> >>>
> > >> >>>> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <
> > akuznetsov@apache.org
> > >> >
> > >> >>> wrote:
> > >> >>>>
> > >> >>>> I think it is very useful feature.
> > >> >>>> I also have experience when server nodes connected via fast
> > network.
> > >> >>>> But client nodes via very slow network.
> > >> >>>>
> > >> >>>> I implemeted GridClientZipOptimizedMarshaller and that solved my
> > >> >> issue.
> > >> >>>> But this marshaller works only with old
> > >> >>>> and org.apache.ignite.internal.client.GridClient and has a lot
> of
> > >> >>>> limitations.
> > >> >>>> But compression was about 6-20x times.
> > >> >>>>
> > >> >>>> We need a solution for Ignite 2.x and client nodes.
> > >> >>>>
> > >> >>>>
> > >> >>>> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <
> > >> nsamelchev@gmail.com
> > >> >>>
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> Hello, Igniters!
> > >> >>>>>
> > >> >>>>> I think it is a useful feature. I suggest to implement it to
> > >> >>> communication
> > >> >>>>> SPI like SSL encryption implemented. I have experience with this
> > >> >> feature
> > >> >>>>> and I can try to develop it.
> > >> >>>>>
> > >> >>>>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
> > >> >> kukushkinalexey@gmail.com
> > >> >>>> :
> > >> >>>>>
> > >> >>>>>> Forwarding to DEV list: Ignite developers, could you please
> share
> > >> >> your
> > >> >>>>>> thoughts on how hard it is to extend Ignite to compress data on
> > the
> > >> >>>>>> network.
> > >> >>>>>>
> > >> >>>>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> > >> >>>>>> gordon.reid@ninemilefinancial.com> wrote:
> > >> >>>>>>
> > >> >>>>>>> Hi Igniters,
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> I see there is a lot of discussion in certain threads about
> > >> >>>>> compression.
> > >> >>>>>>> This seems to have diverged into conversations about object
> > versus
> > >> >>>>> field
> > >> >>>>>>> compression, and even throwing encryption into the mix. For my
> > use
> > >> >>>>> case,
> > >> >>>>>> I
> > >> >>>>>>> am not interested in compressing the cache stored in memory, I
> > >> have
> > >> >>>>>> plenty
> > >> >>>>>>> of memory for my application. What I don’t have is a good
> > >> network. I
> > >> >>>>>> have a
> > >> >>>>>>> high latency, low bandwidth network between my C# ignite
> client
> > >> and
> > >> >> my
> > >> >>>>>> Java
> > >> >>>>>>> ignite server. I only want to compress data when it is sent
> over
> > >> the
> > >> >>>>>>> network to remote nodes. It should be stored in the local
> memory
> > >> >>>>>>> uncompressed. How can we achive this? Can the
> > TcpCommunicationSpi
> > >> >>>>> support
> > >> >>>>>>> compression?
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> Thanks,
> > >> >>>>>>>
> > >> >>>>>>> Gordon.
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>> This email and any attachments are proprietary & confidential
> > and
> > >> >> are
> > >> >>>>>>> intended solely for the use of the individuals to whom it is
> > >> >>> addressed.
> > >> >>>>>> Any
> > >> >>>>>>> views or opinions expressed are solely for those of the author
> > and
> > >> >> do
> > >> >>>>> not
> > >> >>>>>>> necessarily reflect those of Nine Mile Financial Pty. Limited.
> > If
> > >> >> you
> > >> >>>>>> have
> > >> >>>>>>> received this email in error, please let us know immediately
> by
> > >> >> reply
> > >> >>>>>> email
> > >> >>>>>>> and delete from your system. Nine Mile Financial Pty. Limited.
> > >> ABN:
> > >> >>> 346
> > >> >>>>>>> 1349 0252
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> --
> > >> >>>>>> Best regards,
> > >> >>>>>> Alexey
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> --
> > >> >>>>> Best wishes,
> > >> >>>>> Amelchev Nikita
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> --
> > >> >>>> Alexey Kuznetsov
> > >> >>>
> > >> >>>
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Best wishes,
> > >> > Amelchev Nikita
> > >>
> > >>
> > >
> > >
> > > --
> > > Best wishes,
> > > Amelchev Nikita
> > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Vladimir Ozerov <vo...@gridgain.com>.
I would start with communication only, and put discovery and clients aside
for now. Let's confirm that communication works well with compression first
in terms of performance.
On Thu, Nov 30, 2017 at 10:36 AM, Nikita Amelchev <ns...@gmail.com>
wrote:
> Hello, everybody.
> I propose the following design for network compression.
>
> I suggest to implement it like SSL implementation that already works. I add
> compression filter to a chain of NIO filters. It changes the logic of
> TcpCommunicationSpi.safeTcpHandshake() and
> DirectNioClientWorker.processWrite() methods, where depending on whether
> SSL and/or compression are turned on we compress and/or encrypt data and
> messages using compress handler. Also, I will use application buffer
> (implemented in "GridNioCompressHandler") for decompressing.
>
> For compression verification, I have to write the header with a length of
> compressed data (or get it from an algorithm headers) and a flag of
> compression disabled (for small messages). When we are reading compressed
> data from a channel, we check length, the same way as an isInboundDone flag
> is checked in SSL implementation. It is conveniently to implement this flag
> in "CompressEngine" with wrap and unwrap methods for compress and
> decompress to byte buffer. Compression settings should be placed in a
> configuration (Ignite configuration/discovery SPI and
> GridClientConfiguration).
>
> Any thoughts?
>
>
> 2017-11-28 10:39 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
>
> > Hi,
> > I've filed a ticket [1]. I'll try to share design details in a couple of
> > days.
> >
> > 1. https://issues.apache.org/jira/browse/IGNITE-7024
> >
> > 2017-11-23 18:31 GMT+03:00 Denis Magda <dm...@apache.org>:
> >
> >> Nikita,
> >>
> >> Sounds like a good plan. Please share the design details prior getting
> >> down to the implementation.
> >>
> >> —
> >> Denis
> >>
> >> > On Nov 23, 2017, at 4:38 AM, Nikita Amelchev <ns...@gmail.com>
> >> wrote:
> >> >
> >> > Hi Igniters!
> >> >
> >> > I’m working on the similar feature for my own project.
> >> > I would like to suggest use in-line compression and write encoded
> bytes
> >> in
> >> > network channel by bytes array buffer. It allows us avoiding expensive
> >> > memory allocation.
> >> > The described design may be implemented in TcpCommunicationSpi level.
> We
> >> > can introduce pluggable compressor on TCP level where we will be able
> to
> >> > describe our compression strategy, for example, exclude some small
> >> messages
> >> > and many other.
> >> >
> >> > If the community doesn't mind I will file the ticket and will start
> >> > implementing it.
> >> > Any thoughts?
> >> >
> >> > 2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >> >
> >> >> Denis,
> >> >>
> >> >> Regarding zipped marshaller - this would be inefficient, because
> >> >> compression rate will be lower.
> >> >>
> >> >> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org>
> >> wrote:
> >> >>
> >> >>> Nikita,
> >> >>>
> >> >>> Your solution sounds reasonable from the first glance. However, the
> >> >>> communication layer processes a dozen of small system messages that
> >> >> should
> >> >>> be excluded from the compression. Guess, that we will spend more
> time
> >> on
> >> >>> compressing/decompressing them thus diminishing the positive effect
> of
> >> >> the
> >> >>> compression.
> >> >>>
> >> >>> Alexey K., Vladimir O.,
> >> >>>
> >> >>> What if we create Zip version of the binary marshaller the same way
> we
> >> >>> implemented GridClientZipOptimizedMarshaller?
> >> >>>
> >> >>> —
> >> >>> Denis
> >> >>>
> >> >>>> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <
> akuznetsov@apache.org
> >> >
> >> >>> wrote:
> >> >>>>
> >> >>>> I think it is very useful feature.
> >> >>>> I also have experience when server nodes connected via fast
> network.
> >> >>>> But client nodes via very slow network.
> >> >>>>
> >> >>>> I implemeted GridClientZipOptimizedMarshaller and that solved my
> >> >> issue.
> >> >>>> But this marshaller works only with old
> >> >>>> and org.apache.ignite.internal.client.GridClient and has a lot of
> >> >>>> limitations.
> >> >>>> But compression was about 6-20x times.
> >> >>>>
> >> >>>> We need a solution for Ignite 2.x and client nodes.
> >> >>>>
> >> >>>>
> >> >>>> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <
> >> nsamelchev@gmail.com
> >> >>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> Hello, Igniters!
> >> >>>>>
> >> >>>>> I think it is a useful feature. I suggest to implement it to
> >> >>> communication
> >> >>>>> SPI like SSL encryption implemented. I have experience with this
> >> >> feature
> >> >>>>> and I can try to develop it.
> >> >>>>>
> >> >>>>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
> >> >> kukushkinalexey@gmail.com
> >> >>>> :
> >> >>>>>
> >> >>>>>> Forwarding to DEV list: Ignite developers, could you please share
> >> >> your
> >> >>>>>> thoughts on how hard it is to extend Ignite to compress data on
> the
> >> >>>>>> network.
> >> >>>>>>
> >> >>>>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> >> >>>>>> gordon.reid@ninemilefinancial.com> wrote:
> >> >>>>>>
> >> >>>>>>> Hi Igniters,
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> I see there is a lot of discussion in certain threads about
> >> >>>>> compression.
> >> >>>>>>> This seems to have diverged into conversations about object
> versus
> >> >>>>> field
> >> >>>>>>> compression, and even throwing encryption into the mix. For my
> use
> >> >>>>> case,
> >> >>>>>> I
> >> >>>>>>> am not interested in compressing the cache stored in memory, I
> >> have
> >> >>>>>> plenty
> >> >>>>>>> of memory for my application. What I don’t have is a good
> >> network. I
> >> >>>>>> have a
> >> >>>>>>> high latency, low bandwidth network between my C# ignite client
> >> and
> >> >> my
> >> >>>>>> Java
> >> >>>>>>> ignite server. I only want to compress data when it is sent over
> >> the
> >> >>>>>>> network to remote nodes. It should be stored in the local memory
> >> >>>>>>> uncompressed. How can we achive this? Can the
> TcpCommunicationSpi
> >> >>>>> support
> >> >>>>>>> compression?
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Thanks,
> >> >>>>>>>
> >> >>>>>>> Gordon.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> This email and any attachments are proprietary & confidential
> and
> >> >> are
> >> >>>>>>> intended solely for the use of the individuals to whom it is
> >> >>> addressed.
> >> >>>>>> Any
> >> >>>>>>> views or opinions expressed are solely for those of the author
> and
> >> >> do
> >> >>>>> not
> >> >>>>>>> necessarily reflect those of Nine Mile Financial Pty. Limited.
> If
> >> >> you
> >> >>>>>> have
> >> >>>>>>> received this email in error, please let us know immediately by
> >> >> reply
> >> >>>>>> email
> >> >>>>>>> and delete from your system. Nine Mile Financial Pty. Limited.
> >> ABN:
> >> >>> 346
> >> >>>>>>> 1349 0252
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> Best regards,
> >> >>>>>> Alexey
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> Best wishes,
> >> >>>>> Amelchev Nikita
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Alexey Kuznetsov
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Best wishes,
> >> > Amelchev Nikita
> >>
> >>
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hello, everybody.
I propose the following design for network compression.
I suggest to implement it like SSL implementation that already works. I add
compression filter to a chain of NIO filters. It changes the logic of
TcpCommunicationSpi.safeTcpHandshake() and
DirectNioClientWorker.processWrite() methods, where depending on whether
SSL and/or compression are turned on we compress and/or encrypt data and
messages using compress handler. Also, I will use application buffer
(implemented in "GridNioCompressHandler") for decompressing.
For compression verification, I have to write the header with a length of
compressed data (or get it from an algorithm headers) and a flag of
compression disabled (for small messages). When we are reading compressed
data from a channel, we check length, the same way as an isInboundDone flag
is checked in SSL implementation. It is conveniently to implement this flag
in "CompressEngine" with wrap and unwrap methods for compress and
decompress to byte buffer. Compression settings should be placed in a
configuration (Ignite configuration/discovery SPI and
GridClientConfiguration).
Any thoughts?
2017-11-28 10:39 GMT+03:00 Nikita Amelchev <ns...@gmail.com>:
> Hi,
> I've filed a ticket [1]. I'll try to share design details in a couple of
> days.
>
> 1. https://issues.apache.org/jira/browse/IGNITE-7024
>
> 2017-11-23 18:31 GMT+03:00 Denis Magda <dm...@apache.org>:
>
>> Nikita,
>>
>> Sounds like a good plan. Please share the design details prior getting
>> down to the implementation.
>>
>> —
>> Denis
>>
>> > On Nov 23, 2017, at 4:38 AM, Nikita Amelchev <ns...@gmail.com>
>> wrote:
>> >
>> > Hi Igniters!
>> >
>> > I’m working on the similar feature for my own project.
>> > I would like to suggest use in-line compression and write encoded bytes
>> in
>> > network channel by bytes array buffer. It allows us avoiding expensive
>> > memory allocation.
>> > The described design may be implemented in TcpCommunicationSpi level. We
>> > can introduce pluggable compressor on TCP level where we will be able to
>> > describe our compression strategy, for example, exclude some small
>> messages
>> > and many other.
>> >
>> > If the community doesn't mind I will file the ticket and will start
>> > implementing it.
>> > Any thoughts?
>> >
>> > 2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>> >
>> >> Denis,
>> >>
>> >> Regarding zipped marshaller - this would be inefficient, because
>> >> compression rate will be lower.
>> >>
>> >> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org>
>> wrote:
>> >>
>> >>> Nikita,
>> >>>
>> >>> Your solution sounds reasonable from the first glance. However, the
>> >>> communication layer processes a dozen of small system messages that
>> >> should
>> >>> be excluded from the compression. Guess, that we will spend more time
>> on
>> >>> compressing/decompressing them thus diminishing the positive effect of
>> >> the
>> >>> compression.
>> >>>
>> >>> Alexey K., Vladimir O.,
>> >>>
>> >>> What if we create Zip version of the binary marshaller the same way we
>> >>> implemented GridClientZipOptimizedMarshaller?
>> >>>
>> >>> —
>> >>> Denis
>> >>>
>> >>>> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <akuznetsov@apache.org
>> >
>> >>> wrote:
>> >>>>
>> >>>> I think it is very useful feature.
>> >>>> I also have experience when server nodes connected via fast network.
>> >>>> But client nodes via very slow network.
>> >>>>
>> >>>> I implemeted GridClientZipOptimizedMarshaller and that solved my
>> >> issue.
>> >>>> But this marshaller works only with old
>> >>>> and org.apache.ignite.internal.client.GridClient and has a lot of
>> >>>> limitations.
>> >>>> But compression was about 6-20x times.
>> >>>>
>> >>>> We need a solution for Ignite 2.x and client nodes.
>> >>>>
>> >>>>
>> >>>> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <
>> nsamelchev@gmail.com
>> >>>
>> >>>> wrote:
>> >>>>
>> >>>>> Hello, Igniters!
>> >>>>>
>> >>>>> I think it is a useful feature. I suggest to implement it to
>> >>> communication
>> >>>>> SPI like SSL encryption implemented. I have experience with this
>> >> feature
>> >>>>> and I can try to develop it.
>> >>>>>
>> >>>>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
>> >> kukushkinalexey@gmail.com
>> >>>> :
>> >>>>>
>> >>>>>> Forwarding to DEV list: Ignite developers, could you please share
>> >> your
>> >>>>>> thoughts on how hard it is to extend Ignite to compress data on the
>> >>>>>> network.
>> >>>>>>
>> >>>>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
>> >>>>>> gordon.reid@ninemilefinancial.com> wrote:
>> >>>>>>
>> >>>>>>> Hi Igniters,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I see there is a lot of discussion in certain threads about
>> >>>>> compression.
>> >>>>>>> This seems to have diverged into conversations about object versus
>> >>>>> field
>> >>>>>>> compression, and even throwing encryption into the mix. For my use
>> >>>>> case,
>> >>>>>> I
>> >>>>>>> am not interested in compressing the cache stored in memory, I
>> have
>> >>>>>> plenty
>> >>>>>>> of memory for my application. What I don’t have is a good
>> network. I
>> >>>>>> have a
>> >>>>>>> high latency, low bandwidth network between my C# ignite client
>> and
>> >> my
>> >>>>>> Java
>> >>>>>>> ignite server. I only want to compress data when it is sent over
>> the
>> >>>>>>> network to remote nodes. It should be stored in the local memory
>> >>>>>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
>> >>>>> support
>> >>>>>>> compression?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Thanks,
>> >>>>>>>
>> >>>>>>> Gordon.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> This email and any attachments are proprietary & confidential and
>> >> are
>> >>>>>>> intended solely for the use of the individuals to whom it is
>> >>> addressed.
>> >>>>>> Any
>> >>>>>>> views or opinions expressed are solely for those of the author and
>> >> do
>> >>>>> not
>> >>>>>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If
>> >> you
>> >>>>>> have
>> >>>>>>> received this email in error, please let us know immediately by
>> >> reply
>> >>>>>> email
>> >>>>>>> and delete from your system. Nine Mile Financial Pty. Limited.
>> ABN:
>> >>> 346
>> >>>>>>> 1349 0252
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Best regards,
>> >>>>>> Alexey
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Best wishes,
>> >>>>> Amelchev Nikita
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Alexey Kuznetsov
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Best wishes,
>> > Amelchev Nikita
>>
>>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hi,
I've filed a ticket [1]. I'll try to share design details in a couple of
days.
1. https://issues.apache.org/jira/browse/IGNITE-7024
2017-11-23 18:31 GMT+03:00 Denis Magda <dm...@apache.org>:
> Nikita,
>
> Sounds like a good plan. Please share the design details prior getting
> down to the implementation.
>
> —
> Denis
>
> > On Nov 23, 2017, at 4:38 AM, Nikita Amelchev <ns...@gmail.com>
> wrote:
> >
> > Hi Igniters!
> >
> > I’m working on the similar feature for my own project.
> > I would like to suggest use in-line compression and write encoded bytes
> in
> > network channel by bytes array buffer. It allows us avoiding expensive
> > memory allocation.
> > The described design may be implemented in TcpCommunicationSpi level. We
> > can introduce pluggable compressor on TCP level where we will be able to
> > describe our compression strategy, for example, exclude some small
> messages
> > and many other.
> >
> > If the community doesn't mind I will file the ticket and will start
> > implementing it.
> > Any thoughts?
> >
> > 2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >
> >> Denis,
> >>
> >> Regarding zipped marshaller - this would be inefficient, because
> >> compression rate will be lower.
> >>
> >> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org> wrote:
> >>
> >>> Nikita,
> >>>
> >>> Your solution sounds reasonable from the first glance. However, the
> >>> communication layer processes a dozen of small system messages that
> >> should
> >>> be excluded from the compression. Guess, that we will spend more time
> on
> >>> compressing/decompressing them thus diminishing the positive effect of
> >> the
> >>> compression.
> >>>
> >>> Alexey K., Vladimir O.,
> >>>
> >>> What if we create Zip version of the binary marshaller the same way we
> >>> implemented GridClientZipOptimizedMarshaller?
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <ak...@apache.org>
> >>> wrote:
> >>>>
> >>>> I think it is very useful feature.
> >>>> I also have experience when server nodes connected via fast network.
> >>>> But client nodes via very slow network.
> >>>>
> >>>> I implemeted GridClientZipOptimizedMarshaller and that solved my
> >> issue.
> >>>> But this marshaller works only with old
> >>>> and org.apache.ignite.internal.client.GridClient and has a lot of
> >>>> limitations.
> >>>> But compression was about 6-20x times.
> >>>>
> >>>> We need a solution for Ignite 2.x and client nodes.
> >>>>
> >>>>
> >>>> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <
> nsamelchev@gmail.com
> >>>
> >>>> wrote:
> >>>>
> >>>>> Hello, Igniters!
> >>>>>
> >>>>> I think it is a useful feature. I suggest to implement it to
> >>> communication
> >>>>> SPI like SSL encryption implemented. I have experience with this
> >> feature
> >>>>> and I can try to develop it.
> >>>>>
> >>>>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
> >> kukushkinalexey@gmail.com
> >>>> :
> >>>>>
> >>>>>> Forwarding to DEV list: Ignite developers, could you please share
> >> your
> >>>>>> thoughts on how hard it is to extend Ignite to compress data on the
> >>>>>> network.
> >>>>>>
> >>>>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> >>>>>> gordon.reid@ninemilefinancial.com> wrote:
> >>>>>>
> >>>>>>> Hi Igniters,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> I see there is a lot of discussion in certain threads about
> >>>>> compression.
> >>>>>>> This seems to have diverged into conversations about object versus
> >>>>> field
> >>>>>>> compression, and even throwing encryption into the mix. For my use
> >>>>> case,
> >>>>>> I
> >>>>>>> am not interested in compressing the cache stored in memory, I have
> >>>>>> plenty
> >>>>>>> of memory for my application. What I don’t have is a good network.
> I
> >>>>>> have a
> >>>>>>> high latency, low bandwidth network between my C# ignite client and
> >> my
> >>>>>> Java
> >>>>>>> ignite server. I only want to compress data when it is sent over
> the
> >>>>>>> network to remote nodes. It should be stored in the local memory
> >>>>>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
> >>>>> support
> >>>>>>> compression?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Gordon.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> This email and any attachments are proprietary & confidential and
> >> are
> >>>>>>> intended solely for the use of the individuals to whom it is
> >>> addressed.
> >>>>>> Any
> >>>>>>> views or opinions expressed are solely for those of the author and
> >> do
> >>>>> not
> >>>>>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If
> >> you
> >>>>>> have
> >>>>>>> received this email in error, please let us know immediately by
> >> reply
> >>>>>> email
> >>>>>>> and delete from your system. Nine Mile Financial Pty. Limited. ABN:
> >>> 346
> >>>>>>> 1349 0252
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Best regards,
> >>>>>> Alexey
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best wishes,
> >>>>> Amelchev Nikita
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Alexey Kuznetsov
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
>
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Denis Magda <dm...@apache.org>.
Nikita,
Sounds like a good plan. Please share the design details prior getting down to the implementation.
—
Denis
> On Nov 23, 2017, at 4:38 AM, Nikita Amelchev <ns...@gmail.com> wrote:
>
> Hi Igniters!
>
> I’m working on the similar feature for my own project.
> I would like to suggest use in-line compression and write encoded bytes in
> network channel by bytes array buffer. It allows us avoiding expensive
> memory allocation.
> The described design may be implemented in TcpCommunicationSpi level. We
> can introduce pluggable compressor on TCP level where we will be able to
> describe our compression strategy, for example, exclude some small messages
> and many other.
>
> If the community doesn't mind I will file the ticket and will start
> implementing it.
> Any thoughts?
>
> 2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>
>> Denis,
>>
>> Regarding zipped marshaller - this would be inefficient, because
>> compression rate will be lower.
>>
>> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org> wrote:
>>
>>> Nikita,
>>>
>>> Your solution sounds reasonable from the first glance. However, the
>>> communication layer processes a dozen of small system messages that
>> should
>>> be excluded from the compression. Guess, that we will spend more time on
>>> compressing/decompressing them thus diminishing the positive effect of
>> the
>>> compression.
>>>
>>> Alexey K., Vladimir O.,
>>>
>>> What if we create Zip version of the binary marshaller the same way we
>>> implemented GridClientZipOptimizedMarshaller?
>>>
>>> —
>>> Denis
>>>
>>>> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <ak...@apache.org>
>>> wrote:
>>>>
>>>> I think it is very useful feature.
>>>> I also have experience when server nodes connected via fast network.
>>>> But client nodes via very slow network.
>>>>
>>>> I implemeted GridClientZipOptimizedMarshaller and that solved my
>> issue.
>>>> But this marshaller works only with old
>>>> and org.apache.ignite.internal.client.GridClient and has a lot of
>>>> limitations.
>>>> But compression was about 6-20x times.
>>>>
>>>> We need a solution for Ignite 2.x and client nodes.
>>>>
>>>>
>>>> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <nsamelchev@gmail.com
>>>
>>>> wrote:
>>>>
>>>>> Hello, Igniters!
>>>>>
>>>>> I think it is a useful feature. I suggest to implement it to
>>> communication
>>>>> SPI like SSL encryption implemented. I have experience with this
>> feature
>>>>> and I can try to develop it.
>>>>>
>>>>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
>> kukushkinalexey@gmail.com
>>>> :
>>>>>
>>>>>> Forwarding to DEV list: Ignite developers, could you please share
>> your
>>>>>> thoughts on how hard it is to extend Ignite to compress data on the
>>>>>> network.
>>>>>>
>>>>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
>>>>>> gordon.reid@ninemilefinancial.com> wrote:
>>>>>>
>>>>>>> Hi Igniters,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I see there is a lot of discussion in certain threads about
>>>>> compression.
>>>>>>> This seems to have diverged into conversations about object versus
>>>>> field
>>>>>>> compression, and even throwing encryption into the mix. For my use
>>>>> case,
>>>>>> I
>>>>>>> am not interested in compressing the cache stored in memory, I have
>>>>>> plenty
>>>>>>> of memory for my application. What I don’t have is a good network. I
>>>>>> have a
>>>>>>> high latency, low bandwidth network between my C# ignite client and
>> my
>>>>>> Java
>>>>>>> ignite server. I only want to compress data when it is sent over the
>>>>>>> network to remote nodes. It should be stored in the local memory
>>>>>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
>>>>> support
>>>>>>> compression?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Gordon.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This email and any attachments are proprietary & confidential and
>> are
>>>>>>> intended solely for the use of the individuals to whom it is
>>> addressed.
>>>>>> Any
>>>>>>> views or opinions expressed are solely for those of the author and
>> do
>>>>> not
>>>>>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If
>> you
>>>>>> have
>>>>>>> received this email in error, please let us know immediately by
>> reply
>>>>>> email
>>>>>>> and delete from your system. Nine Mile Financial Pty. Limited. ABN:
>>> 346
>>>>>>> 1349 0252
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Alexey
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best wishes,
>>>>> Amelchev Nikita
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Kuznetsov
>>>
>>>
>>
>
>
>
> --
> Best wishes,
> Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hi Igniters!
I’m working on the similar feature for my own project.
I would like to suggest use in-line compression and write encoded bytes in
network channel by bytes array buffer. It allows us avoiding expensive
memory allocation.
The described design may be implemented in TcpCommunicationSpi level. We
can introduce pluggable compressor on TCP level where we will be able to
describe our compression strategy, for example, exclude some small messages
and many other.
If the community doesn't mind I will file the ticket and will start
implementing it.
Any thoughts?
2017-11-23 12:06 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Denis,
>
> Regarding zipped marshaller - this would be inefficient, because
> compression rate will be lower.
>
> On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org> wrote:
>
> > Nikita,
> >
> > Your solution sounds reasonable from the first glance. However, the
> > communication layer processes a dozen of small system messages that
> should
> > be excluded from the compression. Guess, that we will spend more time on
> > compressing/decompressing them thus diminishing the positive effect of
> the
> > compression.
> >
> > Alexey K., Vladimir O.,
> >
> > What if we create Zip version of the binary marshaller the same way we
> > implemented GridClientZipOptimizedMarshaller?
> >
> > —
> > Denis
> >
> > > On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <ak...@apache.org>
> > wrote:
> > >
> > > I think it is very useful feature.
> > > I also have experience when server nodes connected via fast network.
> > > But client nodes via very slow network.
> > >
> > > I implemeted GridClientZipOptimizedMarshaller and that solved my
> issue.
> > > But this marshaller works only with old
> > > and org.apache.ignite.internal.client.GridClient and has a lot of
> > > limitations.
> > > But compression was about 6-20x times.
> > >
> > > We need a solution for Ignite 2.x and client nodes.
> > >
> > >
> > > On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <nsamelchev@gmail.com
> >
> > > wrote:
> > >
> > >> Hello, Igniters!
> > >>
> > >> I think it is a useful feature. I suggest to implement it to
> > communication
> > >> SPI like SSL encryption implemented. I have experience with this
> feature
> > >> and I can try to develop it.
> > >>
> > >> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <
> kukushkinalexey@gmail.com
> > >:
> > >>
> > >>> Forwarding to DEV list: Ignite developers, could you please share
> your
> > >>> thoughts on how hard it is to extend Ignite to compress data on the
> > >>> network.
> > >>>
> > >>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> > >>> gordon.reid@ninemilefinancial.com> wrote:
> > >>>
> > >>>> Hi Igniters,
> > >>>>
> > >>>>
> > >>>>
> > >>>> I see there is a lot of discussion in certain threads about
> > >> compression.
> > >>>> This seems to have diverged into conversations about object versus
> > >> field
> > >>>> compression, and even throwing encryption into the mix. For my use
> > >> case,
> > >>> I
> > >>>> am not interested in compressing the cache stored in memory, I have
> > >>> plenty
> > >>>> of memory for my application. What I don’t have is a good network. I
> > >>> have a
> > >>>> high latency, low bandwidth network between my C# ignite client and
> my
> > >>> Java
> > >>>> ignite server. I only want to compress data when it is sent over the
> > >>>> network to remote nodes. It should be stored in the local memory
> > >>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
> > >> support
> > >>>> compression?
> > >>>>
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Gordon.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> This email and any attachments are proprietary & confidential and
> are
> > >>>> intended solely for the use of the individuals to whom it is
> > addressed.
> > >>> Any
> > >>>> views or opinions expressed are solely for those of the author and
> do
> > >> not
> > >>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If
> you
> > >>> have
> > >>>> received this email in error, please let us know immediately by
> reply
> > >>> email
> > >>>> and delete from your system. Nine Mile Financial Pty. Limited. ABN:
> > 346
> > >>>> 1349 0252
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>> Alexey
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Best wishes,
> > >> Amelchev Nikita
> > >>
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> >
> >
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Denis,
Regarding zipped marshaller - this would be inefficient, because
compression rate will be lower.
On Thu, Nov 23, 2017 at 1:01 AM, Denis Magda <dm...@apache.org> wrote:
> Nikita,
>
> Your solution sounds reasonable from the first glance. However, the
> communication layer processes a dozen of small system messages that should
> be excluded from the compression. Guess, that we will spend more time on
> compressing/decompressing them thus diminishing the positive effect of the
> compression.
>
> Alexey K., Vladimir O.,
>
> What if we create Zip version of the binary marshaller the same way we
> implemented GridClientZipOptimizedMarshaller?
>
> —
> Denis
>
> > On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <ak...@apache.org>
> wrote:
> >
> > I think it is very useful feature.
> > I also have experience when server nodes connected via fast network.
> > But client nodes via very slow network.
> >
> > I implemeted GridClientZipOptimizedMarshaller and that solved my issue.
> > But this marshaller works only with old
> > and org.apache.ignite.internal.client.GridClient and has a lot of
> > limitations.
> > But compression was about 6-20x times.
> >
> > We need a solution for Ignite 2.x and client nodes.
> >
> >
> > On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <ns...@gmail.com>
> > wrote:
> >
> >> Hello, Igniters!
> >>
> >> I think it is a useful feature. I suggest to implement it to
> communication
> >> SPI like SSL encryption implemented. I have experience with this feature
> >> and I can try to develop it.
> >>
> >> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <kukushkinalexey@gmail.com
> >:
> >>
> >>> Forwarding to DEV list: Ignite developers, could you please share your
> >>> thoughts on how hard it is to extend Ignite to compress data on the
> >>> network.
> >>>
> >>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> >>> gordon.reid@ninemilefinancial.com> wrote:
> >>>
> >>>> Hi Igniters,
> >>>>
> >>>>
> >>>>
> >>>> I see there is a lot of discussion in certain threads about
> >> compression.
> >>>> This seems to have diverged into conversations about object versus
> >> field
> >>>> compression, and even throwing encryption into the mix. For my use
> >> case,
> >>> I
> >>>> am not interested in compressing the cache stored in memory, I have
> >>> plenty
> >>>> of memory for my application. What I don’t have is a good network. I
> >>> have a
> >>>> high latency, low bandwidth network between my C# ignite client and my
> >>> Java
> >>>> ignite server. I only want to compress data when it is sent over the
> >>>> network to remote nodes. It should be stored in the local memory
> >>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
> >> support
> >>>> compression?
> >>>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Gordon.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> This email and any attachments are proprietary & confidential and are
> >>>> intended solely for the use of the individuals to whom it is
> addressed.
> >>> Any
> >>>> views or opinions expressed are solely for those of the author and do
> >> not
> >>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If you
> >>> have
> >>>> received this email in error, please let us know immediately by reply
> >>> email
> >>>> and delete from your system. Nine Mile Financial Pty. Limited. ABN:
> 346
> >>>> 1349 0252
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Alexey
> >>>
> >>
> >>
> >>
> >> --
> >> Best wishes,
> >> Amelchev Nikita
> >>
> >
> >
> >
> > --
> > Alexey Kuznetsov
>
>
Re: Transport compression (not store compression)
Posted by Denis Magda <dm...@apache.org>.
Nikita,
Your solution sounds reasonable from the first glance. However, the communication layer processes a dozen of small system messages that should be excluded from the compression. Guess, that we will spend more time on compressing/decompressing them thus diminishing the positive effect of the compression.
Alexey K., Vladimir O.,
What if we create Zip version of the binary marshaller the same way we implemented GridClientZipOptimizedMarshaller?
—
Denis
> On Nov 22, 2017, at 5:36 AM, Alexey Kuznetsov <ak...@apache.org> wrote:
>
> I think it is very useful feature.
> I also have experience when server nodes connected via fast network.
> But client nodes via very slow network.
>
> I implemeted GridClientZipOptimizedMarshaller and that solved my issue.
> But this marshaller works only with old
> and org.apache.ignite.internal.client.GridClient and has a lot of
> limitations.
> But compression was about 6-20x times.
>
> We need a solution for Ignite 2.x and client nodes.
>
>
> On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <ns...@gmail.com>
> wrote:
>
>> Hello, Igniters!
>>
>> I think it is a useful feature. I suggest to implement it to communication
>> SPI like SSL encryption implemented. I have experience with this feature
>> and I can try to develop it.
>>
>> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <ku...@gmail.com>:
>>
>>> Forwarding to DEV list: Ignite developers, could you please share your
>>> thoughts on how hard it is to extend Ignite to compress data on the
>>> network.
>>>
>>> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
>>> gordon.reid@ninemilefinancial.com> wrote:
>>>
>>>> Hi Igniters,
>>>>
>>>>
>>>>
>>>> I see there is a lot of discussion in certain threads about
>> compression.
>>>> This seems to have diverged into conversations about object versus
>> field
>>>> compression, and even throwing encryption into the mix. For my use
>> case,
>>> I
>>>> am not interested in compressing the cache stored in memory, I have
>>> plenty
>>>> of memory for my application. What I don’t have is a good network. I
>>> have a
>>>> high latency, low bandwidth network between my C# ignite client and my
>>> Java
>>>> ignite server. I only want to compress data when it is sent over the
>>>> network to remote nodes. It should be stored in the local memory
>>>> uncompressed. How can we achive this? Can the TcpCommunicationSpi
>> support
>>>> compression?
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Gordon.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This email and any attachments are proprietary & confidential and are
>>>> intended solely for the use of the individuals to whom it is addressed.
>>> Any
>>>> views or opinions expressed are solely for those of the author and do
>> not
>>>> necessarily reflect those of Nine Mile Financial Pty. Limited. If you
>>> have
>>>> received this email in error, please let us know immediately by reply
>>> email
>>>> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
>>>> 1349 0252
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Alexey
>>>
>>
>>
>>
>> --
>> Best wishes,
>> Amelchev Nikita
>>
>
>
>
> --
> Alexey Kuznetsov
Re: Transport compression (not store compression)
Posted by Alexey Kuznetsov <ak...@apache.org>.
I think it is very useful feature.
I also have experience when server nodes connected via fast network.
But client nodes via very slow network.
I implemeted GridClientZipOptimizedMarshaller and that solved my issue.
But this marshaller works only with old
and org.apache.ignite.internal.client.GridClient and has a lot of
limitations.
But compression was about 6-20x times.
We need a solution for Ignite 2.x and client nodes.
On Wed, Nov 22, 2017 at 7:48 PM, Nikita Amelchev <ns...@gmail.com>
wrote:
> Hello, Igniters!
>
> I think it is a useful feature. I suggest to implement it to communication
> SPI like SSL encryption implemented. I have experience with this feature
> and I can try to develop it.
>
> 2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <ku...@gmail.com>:
>
> > Forwarding to DEV list: Ignite developers, could you please share your
> > thoughts on how hard it is to extend Ignite to compress data on the
> > network.
> >
> > On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> > gordon.reid@ninemilefinancial.com> wrote:
> >
> > > Hi Igniters,
> > >
> > >
> > >
> > > I see there is a lot of discussion in certain threads about
> compression.
> > > This seems to have diverged into conversations about object versus
> field
> > > compression, and even throwing encryption into the mix. For my use
> case,
> > I
> > > am not interested in compressing the cache stored in memory, I have
> > plenty
> > > of memory for my application. What I don’t have is a good network. I
> > have a
> > > high latency, low bandwidth network between my C# ignite client and my
> > Java
> > > ignite server. I only want to compress data when it is sent over the
> > > network to remote nodes. It should be stored in the local memory
> > > uncompressed. How can we achive this? Can the TcpCommunicationSpi
> support
> > > compression?
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Gordon.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > This email and any attachments are proprietary & confidential and are
> > > intended solely for the use of the individuals to whom it is addressed.
> > Any
> > > views or opinions expressed are solely for those of the author and do
> not
> > > necessarily reflect those of Nine Mile Financial Pty. Limited. If you
> > have
> > > received this email in error, please let us know immediately by reply
> > email
> > > and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> > > 1349 0252
> > >
> >
> >
> >
> > --
> > Best regards,
> > Alexey
> >
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>
--
Alexey Kuznetsov
Re: Transport compression (not store compression)
Posted by Nikita Amelchev <ns...@gmail.com>.
Hello, Igniters!
I think it is a useful feature. I suggest to implement it to communication
SPI like SSL encryption implemented. I have experience with this feature
and I can try to develop it.
2017-11-22 12:01 GMT+03:00 Alexey Kukushkin <ku...@gmail.com>:
> Forwarding to DEV list: Ignite developers, could you please share your
> thoughts on how hard it is to extend Ignite to compress data on the
> network.
>
> On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
> gordon.reid@ninemilefinancial.com> wrote:
>
> > Hi Igniters,
> >
> >
> >
> > I see there is a lot of discussion in certain threads about compression.
> > This seems to have diverged into conversations about object versus field
> > compression, and even throwing encryption into the mix. For my use case,
> I
> > am not interested in compressing the cache stored in memory, I have
> plenty
> > of memory for my application. What I don’t have is a good network. I
> have a
> > high latency, low bandwidth network between my C# ignite client and my
> Java
> > ignite server. I only want to compress data when it is sent over the
> > network to remote nodes. It should be stored in the local memory
> > uncompressed. How can we achive this? Can the TcpCommunicationSpi support
> > compression?
> >
> >
> >
> > Thanks,
> >
> > Gordon.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > This email and any attachments are proprietary & confidential and are
> > intended solely for the use of the individuals to whom it is addressed.
> Any
> > views or opinions expressed are solely for those of the author and do not
> > necessarily reflect those of Nine Mile Financial Pty. Limited. If you
> have
> > received this email in error, please let us know immediately by reply
> email
> > and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> > 1349 0252
> >
>
>
>
> --
> Best regards,
> Alexey
>
--
Best wishes,
Amelchev Nikita
Re: Transport compression (not store compression)
Posted by Alexey Kukushkin <ku...@gmail.com>.
Forwarding to DEV list: Ignite developers, could you please share your
thoughts on how hard it is to extend Ignite to compress data on the network.
On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
gordon.reid@ninemilefinancial.com> wrote:
> Hi Igniters,
>
>
>
> I see there is a lot of discussion in certain threads about compression.
> This seems to have diverged into conversations about object versus field
> compression, and even throwing encryption into the mix. For my use case, I
> am not interested in compressing the cache stored in memory, I have plenty
> of memory for my application. What I don’t have is a good network. I have a
> high latency, low bandwidth network between my C# ignite client and my Java
> ignite server. I only want to compress data when it is sent over the
> network to remote nodes. It should be stored in the local memory
> uncompressed. How can we achive this? Can the TcpCommunicationSpi support
> compression?
>
>
>
> Thanks,
>
> Gordon.
>
>
>
>
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
--
Best regards,
Alexey
Re: Transport compression (not store compression)
Posted by Alexey Kukushkin <ku...@gmail.com>.
Forwarding to DEV list: Ignite developers, could you please share your
thoughts on how hard it is to extend Ignite to compress data on the network.
On Wed, Nov 22, 2017 at 10:04 AM, Gordon Reid (Nine Mile) <
gordon.reid@ninemilefinancial.com> wrote:
> Hi Igniters,
>
>
>
> I see there is a lot of discussion in certain threads about compression.
> This seems to have diverged into conversations about object versus field
> compression, and even throwing encryption into the mix. For my use case, I
> am not interested in compressing the cache stored in memory, I have plenty
> of memory for my application. What I don’t have is a good network. I have a
> high latency, low bandwidth network between my C# ignite client and my Java
> ignite server. I only want to compress data when it is sent over the
> network to remote nodes. It should be stored in the local memory
> uncompressed. How can we achive this? Can the TcpCommunicationSpi support
> compression?
>
>
>
> Thanks,
>
> Gordon.
>
>
>
>
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
--
Best regards,
Alexey