Slow Transaction Performance

classic Classic list List threaded Threaded
6 messages Options
pragmaticbigdata pragmaticbigdata
Reply | Threaded
Open this post in threaded view
|

Slow Transaction Performance

I am executing my tests with apache ignite 1.6. With a 5 node cluster (servers=5, clients=0, CPUs=16, heap=17.0GB), I create a partitioned cache that is preloaded with 1 million entries (IgniteCache<String, JavaPojo>).

Updating 11k records in this partitioned cache is taking between 1.6 secs while it takes 17 secs to perform the same update when the cache atomicity mode is changed to TRANSACTIONAL and the updates (putAll operation) are executed in a transaction (OPTIMISTIC, READ_COMMITTED).

What are some of the options to improve the transaction performance from 17 secs?

Thanks,
Amit.
amitpa amitpa
Reply | Threaded
Open this post in threaded view
|

Re: Slow Transaction Performance

Setting PRIMARY_SYNC helps for partitioned caches.
It should be faster.
pragmaticbigdata pragmaticbigdata
Reply | Threaded
Open this post in threaded view
|

Re: Slow Transaction Performance

I forgot to mention that I have set backups as 0 in order to benchmark the best possible performance.  So setting primary_sync does not have any effect.

Do you have any of your test cases that are resulting in better numbers?
amitpa amitpa
Reply | Threaded
Open this post in threaded view
|

Re: Slow Transaction Performance

It has..I think primarkSync allows to sync with one node, the primary, otherwise all nodes are synced.
In case backups are configured it will be backups + primary node
Denis Magda Denis Magda
Reply | Threaded
Open this post in threaded view
|

Re: Slow Transaction Performance

Hi,

In case with the primary sync mode that data will be always synced up on a primary node only. The backups will be synced up asynchronously.

To answer on your initial question on how to improve the performance of transactions more details are needed:

- do you execute transactions in parallel? Usually if keys that are used in transactions are not intersected you can start several Thread an execute transactions from them simultaneously.

- how do you measure and how your code looks like? Also don’t forget about VM warmup before starting gathering performance statistics.

- what is the reason why you started measuring this particular transactions? Do you have any specific use case? If you use case is just to preload that cache as fast as possible you can use IgniteDataStreamer for that
https://apacheignite.readme.io/docs/data-streamers
 

Denis

> On Jun 10, 2016, at 6:37 PM, amitpa <[hidden email]> wrote:
>
> It has..I think primarkSync allows to sync with one node, the primary,
> otherwise all nodes are synced.
> In case backups are configured it will be backups + primary node
>
>
>
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Slow-Transaction-Performance-tp5548p5580.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Denis Magda Denis Magda
Reply | Threaded
Open this post in threaded view
|

Re: Slow Transaction Performance

Hi,

If every transaction updates around 11K entries it’s not surprisingly that the performance will suffer especially if there are multiple transactions that are executed in parallel and work with the same subset of the keys.

My suggestion is to split such huge transaction on a smaller ones if it’s possible on your side. If this doesn’t work for you use case try to use OPTIMISTIC/SERIALIZABLE transactions that should work faster. Also please see the difference for isolation levels [1] because I’m not sure that OPTIMISTIC/READ_COMMITTED should work for you.

Affinity run/call may work if you collocate caches [2] around some entity and send update to a node that keeps all the data avoiding data transfer over the wire.


Denis

On Jun 13, 2016, at 2:32 PM, pragmaticbigdata <[hidden email]> wrote:

Thanks for the replies

do you execute transactions in parallel? Usually if keys that are used in
transactions are not intersected you can start several Thread an execute
transactions from them simultaneously.

The timings I posed are to update 11k entries in a cache that was pre-loaded
with 1 million records. A single transaction was started around this update.
Also this update uses bulk methods (i.e. cache.putAll()) to update all 11k
entries in the cache. I had observed a tremendous performance improvement in
doing a bulk update.

how do you measure and how your code looks like? Also don’t forget about
VM warmup before starting gathering performance statistics.

I monitor it by loggers. Its a standalone application code for POC purpose.
The code basically serially updates cache entries from single or multiple
caches. A snippet of the relevant code is shared here -
http://pastebin.com/ENv6q7Ni

what is the reason why you started measuring this particular transactions?
Do you have any specific use case? If you use case is just to preload that
cache as fast as possible you can use IgniteDataStreamer for that
https://apacheignite.readme.io/docs/data-streamers

Our use case is to update cache entries on an user event. This update
practically triggers updates in multiple caches which in-turn again triggers
updates is other caches and so and so forth. A graph dependency framework is
implemented to determine what are the next set of updates.
All these updates are to be implemented in one transaction. I tried using
the affinity features of ignite but experienced a very slow performance with
ignite.compute().affinityCall().

Let me know if you need more details.
Thanks.



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Slow-Transaction-Performance-tp5548p5614.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.