iquidus
Massive performance improvement...
.. for index page and address view page. Don't forget that these additional mongo indexes must be created to achieve the level of performance of http://lcp.altcoinwarz.com/
db.txes.createIndex({total: 1})
db.txes.createIndex({total: -1})
db.txes.createIndex({blockindex: 1})
db.txes.createIndex({blockindex: -1})
addresstxes
db.addresstxes.createIndex({a_id: 1, blockindex: -1})```
it should be noted that there is a diff between count and countDocuments, and by virtue of mongos documentation this should be avoided.
Do you want me to set it back to countDocuments ?
it should be noted that there is a diff between count and countDocuments, and by virtue of mongos documentation this should be avoided.
Do you want me to set it back to countDocuments ?
I'm not entirely sure yet. I need to go through and double check its usage. My fear is improper shutdowns will cause the count to be off, but this is simply the total count of txes for an address. It's not something I deem mission critical compared to say the actual values of transactions/amounts/etc.
Performance wise, count is indeed much faster, but it's also susceptible to inaccuracies.
it should be noted that there is a diff between count and countDocuments, and by virtue of mongos documentation this should be avoided.
Do you want me to set it back to countDocuments ?
I'm not entirely sure yet. I need to go through and double check its usage. My fear is improper shutdowns will cause the count to be off, but this is simply the total count of txes for an address. It's not something I deem mission critical compared to say the actual values of transactions/amounts/etc.
Performance wise, count is indeed much faster, but it's also susceptible to inaccuracies.
That's exactly what I thought. It's the same as count without lock on MySQL InnoDB, the count is not accurate but is very fast. In this case, worst that can happen is the the page number display is not accurate. But transactions per address are slow, I guess we could live with that given the cost of the countDocuments().
it should be noted that there is a diff between count and countDocuments, and by virtue of mongos documentation this should be avoided.
Do you want me to set it back to countDocuments ?
I'm not entirely sure yet. I need to go through and double check its usage. My fear is improper shutdowns will cause the count to be off, but this is simply the total count of txes for an address. It's not something I deem mission critical compared to say the actual values of transactions/amounts/etc. Performance wise, count is indeed much faster, but it's also susceptible to inaccuracies.
That's exactly what I thought. It's the same as count without lock on MySQL InnoDB, the count is not accurate but is very fast. In this case, worst that can happen is the the page number display is not accurate. But transactions per address are slow, I guess we could live with that given the cost of the countDocuments().
I agree. I would however counter to provide a settings config so that explorer admins can choose to have accuracy. The performance impact from if/then statements would be negligible.
Any update on the ETA of this pull request being finalized and merged?
Also, @typhoonsimon where does the need come to index both descending and ascending directions, does it really give the desired result?
.. Don't forget that these additional mongo indexes must be created to achieve the level of performance of http://lcp.altcoinwarz.com/
db.txes.createIndex({total: 1}) db.txes.createIndex({total: -1}) db.txes.createIndex({blockindex: 1}) db.txes.createIndex({blockindex: -1})
I'm going to add this to my testing and merges with uaktags:explorer#58. Once testing is complete, I'll push accept and merge this. Hopefully end of week for an eta
Merged the index declarations to 'main' here: https://github.com/iquidus/explorer/commit/3f81b753945cb1987b4ad5aeb69ede3588d700a9 - these alone seem to have improved paging performance for me so thanks for that @typhoonsimon
https://github.com/iquidus/explorer/commit/d611f8f48e56bd1d9984bd001c35185bf3022a5f This patch seems to add a mild speed improvement until we resolve this PR but thanks for your help so far @typhoonsimon
Difficulty display fixed: https://github.com/iquidus/explorer/commit/b7180dc9224adcda0c75845e77aab0bfc8734347