Re: Long transaction suspended

[jjimeno]

Hello!

FYI: https://issues.apache.org/jira/browse/IGNITE-14165




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Long transaction suspended

[jjimeno]

Hello!

Answering to myself:

Should I get a better performance in a multi-node cluster? Of course!  

We have switched to a 4-node cluster and reading times dropped drastically. 
We are really looking forward the PutAll bug to be fixed to perform writing
tests.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Long transaction suspended

[jjimeno]

Hi, thanks for pointing it out

This confirms our tests... moving from a single-node cluster to a two-nodes
one dropped the read timings to less than the half!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Long transaction suspended

[Stephen Darlington]

I’ve not been following this thread closely, so I apologise if I’ve missed 
something.

>  - Should I get a better performance in a multi-node cluster? Read/Write/Both?

As per the documentation: 

“Ignite is designed and optimized for distributed computing scenarios. Deploy 
and benchmark a multi-node cluster rather than a single-node one.” 
(https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips)

So yes, all else being equal, more nodes will give you better performance. 
Keeping the volume of data the same, doubling the number of nodes will roughly 
halve the number of reads/writes going to each node. But even there, things 
like the use of transactions and thin clients will limit your throughput to 
well below what Ignite is capable of “flat out."

Without analysing your architecture it’s difficult to give specific advice, but 
best write performance is achieved with many nodes, fast disks, JVM tuning and 
thick clients using the data streamer API.

Regards,
Stephen

> On 11 Feb 2021, at 07:08, jjimeno  wrote:
> 
> Hello!
> 
> That's exactly the reason why we would prefer to choose Ignite over RocksDB. 
> Otherwise, we will have to implement scalability by ourselves and, believe
> me, that's not something we would like to do.
> 
> We also know they're not directly comparable. We would agree to pay the
> price for scalability with slightly worse performance but, based on our
> tests, it's too big.
> 
> For instance:
>  - Single node cluster in the same host as the application (no
> communication over the wire, trying to get closer to an embedded database)
>  - A single user (no multiple users working either on the application or
> the database)
> 
> A transactional commit with 1.8M keys and 1GB in size takes 97 seconds with
> NO persistence, and this time is doubled if persistence is enabled.  RocksDB
> takes around 100 seconds to perform a transaction with 4M keys and 4GB in
> size, persistence included.  As you can see, there is a huge difference.
> 
> On the other hand, limitations like the ones we have found in one month of
> research:
>  -  PutAll performance in transactional cache
>   
>  -  Not asynchronous tcp connection
>   
>  - The maximum transaction size of 1GB we are discussing in this thread
> 
> don't really help to go for Ignite, at least in our kind of project.
> 
> But we would still like to do more tests to be 100% sure about our decision,
> that's why I'd like to ask you: 
>  - Should I get a better performance in a multi-node cluster?
> Read/Write/Both?
>  - Should I do the tests in a different way?
> 
> Thanks in advance!
> 
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Re[2]: Long transaction suspended

[jjimeno]

Great!... I'm really looking forward it :)



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Re[2]: Long transaction suspended

[jjimeno]

Hello!

I'm sorry hearing that.
Would you think it could be fixed to reach these 2GB? Currently it's only
1GB in the C++ Thin Client

Regards



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/