Re: Ignite Transaction performance

Hello, can some one please submit an alternative? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5419.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite Transaction performance

I have made all caches Atomic which need to be in transaction. Still the performance is no where near a singke node. I get 2 inserts / sec on a single node now, and around 2000-2500 on a 2 node setup. Is there any thing I can do to increase performance ? I am open to adding to one more node or

Re: Ignite Transaction performance

Val, Thanks for the tips.But I saw very little gains 4-10%. For a large set of nodes this does provid ebenefit. However we plan to deploy two nodes and then take it from there as demand grows. is there any other way I can imporve what is known in RDBMS terms insert throughput? -- View this mess

Re: Ignite Transaction performance

Val, Some of our caches have to REPLICATED , as they are mostly read only caches. I will try Primary_SYNC and try. Regards -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5317.html Sent from the Apache Ignite Users mailing

Re: Ignite Transaction performance

Hi, Some of your caches are both REPLICATED and FULL_SYNC. This means that each time you update one of these caches, you will send synchronous request to all the nodes, so the latency will almost linearly grow. You can try switching synchronization mode to PRIMARY_SYNC. In this case you will not

Re: Ignite Transaction performance

He disruptor.zip The disruptorserver is to be run first. The app is the client , sends in 10, requests at a time. I get a TPS of 1 when I run the disruptor server only. However when I run the IgniteMain to add a

Re: Ignite Transaction performance

I am creating the test cases. I saw that doing inserts increase the latency severely. I have a question does Ignite treat inserts the same as updates ? My isolation level is OPTIMISTIC with serializable -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Tran

Re: Ignite Transaction performance

Val, Will do that, but meanwhile can I increase performance incresing System Thread pool etc? My machine has CPU and bandwidth limit is still not reached -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5226.html Sent from

Re: Ignite Transaction performance

Hi, With a single node without a client, there is no network, so latency is of course lower than when you add network. According to you description, your test is more complicated than code snippets your provided before. So please provide a project that I will be able to run and reproduce the perf

Re: Ignite Transaction performance

Lastly is there any thread count number to be increased to help in high throughput commit messages...liek does increasing the system threads increase performance? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5222.html Sent

Re: Ignite Transaction performance

Server Node. Disabled Backups. But all changes are SYNCED synchronously. Caches are all partitioned and there are 4 caches. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5199.html Sent from the Apache Ignite Users mailing

Re: Ignite Transaction performance

Are you executing transactions from a client node or from a server node? Do you have backups? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5195.html Sent from the Apache Ignite Users mailing list archive at Nabble.co

Re: Ignite Transaction performance

Val, Its correct that its so. Hwoever If I add one more node, this adds serious overhead. if I add more threads and start giving more concurrent inputs some transactions start slowing down with some going more than 3 seconds !!!. However I read about affinity key, does it help while inserting dat

Re: Ignite Transaction performance

Do you mean that it takes 22 seconds to execute 10 transactions? This means around 0.2ms per transaction, which seems to be good latency. Note that you're executing them synchronously in a single thread, waiting for the network each time. If you need to increase throughput, you should run more

Re: Ignite Transaction performance

I start one node with the same cache configs as above. I do not execute it . And in another cache I start a ignite node and us ethe code below IgniteCache cache = ignite.getOrCreateCache(cfg1); IgniteCache cache2 = ignite.getOrCreateCache(cfg1); IgniteCache cache3 = ignite.getOrCreateC

Re: Ignite Transaction performance

Val, Understand that. I will try to come up with some code. I think by Friday I will have something that can be replicated... Lastly one thing what can be the none causes of something like this ? Regards -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Tr

Re: Ignite Transaction performance

There are too many variables to say if this performance is OK or not without having the code. So please provide the test if you want someone in the community to help you. BTW, 1.6 is released, you can try it: ignite.apache.org/download.cgi#binaries -Val -- View this message in context: http:/

Re: Ignite Transaction performance

I will try to. But the code is difficult to replicate for obvious reasons. The cache keys are Long and the values are Java POJO's. There are two nodes running on different systems. There is however a massive amount of concurrent transactions. I saw there is an optimization in Ignite 1.6 RC1 for thi

Re: Ignite Transaction performance

Hi, Can you provide your benchmark so that someone can take a look and investigate? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Transaction-performance-tp5085p5101.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.