Extremely slow openmonero

[ghost]

I noticed that openmonero is EXTREMELY slow. Is there any hints that would help to improve performance. Maybe I need to edit configuration file somehow.

[moneroexamples]

Slow as compared to what? To some its prior version, or official monero wallet?

The performance issues has been explained in readme before:

https://github.com/moneroexamples/openmonero#performance

The option that can have effect on tx scanning search is this one:

https://github.com/moneroexamples/openmonero/blob/master/config/config.json#L56

It sets how many blocks should be fetched from the blockchain at once to search for your txs. Higher values means more blocks are read, and subsequently less frequent access to the blockchain. Lower values mean less blocks are being read. It results in more frequent access to the blockchain, but all the data structures and memory requirements of the scanning procedure are lower.

So you can tweak this parameter and find good value for you.

There is also:

https://github.com/moneroexamples/openmonero/blob/master/config/config.json#L61

But this primary should have effect if you have many multiple concurrent users scanning for their txs. The higher the value, the more threads are available for accessing blockchain. With one thread and many users, the user's requests to blockchain are queued.

[ghost]

Thank you for such a good response!

Is it ok to run multiple openmonero clients on different machines and point them to the same mysql database? Will it improve performance? Is there some things to consider when doing this?

I realized that perfomance has dropped drastically when I reset mysql db and had to import all the wallets again. So that was the reason, this importing takes a lot of computations, especially, if you don't know the exact block number a wallet account was created at, so you need to start scanning from the very first block!

[ghost]

Actually one of the mistakes was to make a log of get_unspent_outs requests to server. For some reason it's very slow, it's much better to invoke get_address_info instead if you want to get balances.

[moneroexamples]

Thank you for such a good response!

No problem.

Is it ok to run multiple openmonero clients on different machines and point them to the same mysql database?

I don't think it will work well without changes to how search threads work. Different machines could have search threads running for same account, trying to concurrently write to same database. This would lead to race conditions. A search thread removes a tx if its already present in db, as it happens when re-scanning blockchian. So one machine would be adding txs for a given account, second one would removing them for the same account, and trying to re-add. There could be other issues, like search threads "thinking" there are duplicates in data.

Is there some things to consider when doing this?

The better would be having a common front-end gateway, which would distribute load to different in independent machines. For examples, users whos xmr address ends with 1 are directed to one machine, those that end with 2 are redirected to other one, and so on. There was a post in issues made about making it in nginx, but it got deleted.

importing takes a lot of computations

Yes it does, because without spendkey, OM has to scan every ring member in every key image, in every tx, to try to "guess" user's outgoing txs.

if you don't know the exact block number a wallet account was created at, so you need to start scanning from the very first block!

That's why there are time based imports, scan from last month, last 6 months, etc. So if a user roughly knows how old is his/hers wallet, this can speed things up considerably. You can change the default max value (about 6 months) using this option:

https://github.com/moneroexamples/openmonero/blob/master/config/config.json#L58

make a log of get_unspent_outs requests to server. For some reason it's very slow,

Interesting. Do you have some rough idea how much slower it is? Maybe there is some performance bug there? I wouldn't expect it to be terribly slow.