Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve vote tally performance #803

Closed
2 tasks done
abitmore opened this issue Apr 2, 2018 · 7 comments
Closed
2 tasks done

Improve vote tally performance #803

abitmore opened this issue Apr 2, 2018 · 7 comments
Assignees
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3c Enhancement Classification indicating a change to the functionality of the existing imlementation 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 UX Impact flag identifying the User Interface (UX) 9c Large Effort estimation indicating TBD performance

Comments

@abitmore
Copy link
Member

abitmore commented Apr 2, 2018

Vote tally performance affects maintenance block producing (#504) as well as overall sync/replay time.

  • Things we can do in short term:
    • skip those who are not voting,
    • skip those whose core_in_orders + core_balance is zero.

- [ ] Long term solution to be figured out.
- The mechanism used by Steem could be an option, but I think it only positively impacts maintenance block producing but probably negatively impacts overall sync/replay performance.

This is a sub-task of #982.

Update: moved long term job to issue #1204.

@abitmore abitmore added this to the Future Non-Consensus-Changing Release milestone Apr 2, 2018
@ryanRfox ryanRfox added 1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3c Enhancement Classification indicating a change to the functionality of the existing imlementation 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 UX Impact flag identifying the User Interface (UX) labels May 24, 2018
@oxarbitrage
Copy link
Member

maybe it worth a new issue but can also fit here for initial conversation.

bitshares/open-explorer#31 (comment)

need to confirm if it is exactly whats happening but according to reported we may need to add a recalculating of votes into committee_members(and witnesses?) that are not active to update their voting count.

@abitmore
Copy link
Member Author

Perhaps add a startup option or something that also update votes for inactive ones as well. Block producing nodes should not enable the option for better performance, but API nodes likely want to enable it..

@oxarbitrage
Copy link
Member

yes, i added the comment in here as it will affect maint block latency even more but with the startup option it should not be a problem. thanks, making new issue for this and continue there, leaving this for increase performance only.

@abitmore
Copy link
Member Author

abitmore commented Jun 23, 2018

Replay profiling data: https://pastebin.com/abmzjruy

---------------------- first 27 M blocks ----------------------------
1138060ms th_a db_management.cpp:124 reindex ] Done reindexing, elapsed time: 13812.88650899999993271 sec

Flat profile:
 
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 25.25   1009.85  1009.85    22671     0.04     0.08  graphene::chain::database::perform_chain_maintenance(graphene::chain::signed_block const&, graphene::chain::global_property_object const&)
 11.16   1456.36   446.51 2148827443     0.00     0.00  graphene::chain::database::get_balance(graphene::db::object_id<(unsigned char)1, (unsigned char)2, graphene::chain::account_object>, graphene::db::object_id<(unsigned char)1, (unsigned char)3, graphene::chain::asset_object>) const
  7.27   1747.17   290.81 310082501     0.00     0.00  graphene::db::simple_index<graphene::chain::account_statistics_object>::find(graphene::db::object_id_type) const
  6.60   2011.04   263.87 386682199     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_balance_object, ... >::modify(graphene::db::object const&, std::function<void (graphene::db::object&)> const&)
  5.04   2212.54   201.50 722779832     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_object, ...  >::find(graphene::db::object_id_type) const
  4.33   2385.56   173.02 20731743387     0.00     0.00  graphene::chain::operator>(graphene::chain::price const&, graphene::chain::price const&)
  2.90   2501.68   116.12 390785433     0.00     0.00  graphene::chain::database::adjust_balance(graphene::db::object_id<(unsigned char)1, (unsigned char)2, graphene::chain::account_object>, graphene::chain::asset)
  2.60   2605.58   103.90 22967573183     0.00     0.00  graphene::chain::operator<(graphene::chain::price const&, graphene::chain::price const&)

@abitmore
Copy link
Member Author

abitmore commented Jun 23, 2018

Profiling data of PR #1085 pasted in #1083, quoting here:

Flat profile:

Each sample counts as 0.01 seconds.
 %   cumulative   self              self     total
time   seconds   seconds    calls   s/call   s/call  name
22.90    574.86   574.86 948058596     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_object ...  >::find(graphene::db::object_id_type) const
10.99    850.85   275.99 391901309     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_balance_object, ...  >::modify(graphene::db::object const&, std::function<void (graphene::db::object&)> const&)
 6.41   1011.89   161.04 20731743387     0.00     0.00  graphene::chain::operator>(graphene::chain::price const&, graphene::chain::price const&)
 4.31   1119.98   108.09 390785433     0.00     0.00  graphene::chain::database::adjust_balance(graphene::db::object_id<(unsigned char)1, (unsigned char)2, graphene::chain::account_object>, graphene::chain::asset)
 4.18   1224.80   104.82    22671     0.00     0.01  graphene::chain::database::perform_chain_maintenance(graphene::chain::signed_block const&, graphene::chain::global_property_object const&)
 3.56   1314.29    89.50 22967573183     0.00     0.00  graphene::chain::operator<(graphene::chain::price const&, graphene::chain::price const&)
 3.40   1399.71    85.42 307443552     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_statistics_object, ...  >::find(graphene::db::object_id_type) const

---------------------- first 27 M blocks ----------------------------
522577ms th_a db_management.cpp:124 reindex ] Done reindexing, elapsed time: 6112.74653399999988324 sec

@abitmore
Copy link
Member Author

abitmore commented Jun 23, 2018

New profiling data after added more commits to #1085:

---------------------- first 27 M blocks ----------------------------
1486171ms th_a db_management.cpp:124 reindex ] Done reindexing, elapsed time: 5633.52932400000008784 sec

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 13.89    382.25   382.25 391901309     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_balance_object, ... >::modify(graphene::db::object const&, std::function<void (graphene::db::object&)> const&)
  8.92    627.59   245.34 448458421     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_object, ... >::find(graphene::db::object_id_type) const
  8.00    847.80   220.21 20731743387     0.00     0.00  graphene::chain::operator>(graphene::chain::price const&, graphene::chain::price const&)
  5.43    997.08   149.28 390785433     0.00     0.00  graphene::chain::database::adjust_balance(graphene::db::object_id<(unsigned char)1, (unsigned char)2, graphene::chain::account_object>, graphene::chain::asset)
  4.39   1117.86   120.78 22967573183     0.00     0.00  graphene::chain::operator<(graphene::chain::price const&, graphene::chain::price const&)
  4.28   1235.73   117.87 307448392     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_statistics_object, ... >::find(graphene::db::object_id_type) const
  3.74   1338.50   102.77                             sha256_block_data_order_avx
  3.36   1431.04    92.54 3183637020     0.00     0.00  graphene::chain::generic_index<graphene::chain::asset_bitasset_data_object, ... >::find(graphene::db::object_id_type) const
  3.04   1514.78    83.74 805850110     0.00     0.00  graphene::chain::generic_index<graphene::chain::asset_object, ... >::find(graphene::db::object_id_type) const
  2.56   1585.22    70.44 245765371     0.00     0.00  graphene::chain::generic_index<graphene::chain::account_statistics_object, ... >::modify(graphene::db::object const&, std::function<void (graphene::db::object&)> const&)
  2.48   1653.40    68.18 27000000     0.00     0.00  graphene::chain::database::update_expired_feeds()
  2.10   1711.27    57.87 72953692     0.00     0.00  boost::multi_index::detail::ordered_index<boost::multi_index::composite_key<graphene::chain::limit_order_object, ... >::link_point( ... )
  1.94   1764.72    53.45 72953692     0.00     0.00  graphene::chain::generic_index<graphene::chain::limit_order_object, ... >::create(std::function<void (graphene::db::object&)> const&)
  1.87   1816.27    51.55 78522251     0.00     0.00  graphene::chain::database::get_balance(graphene::chain::account_object const&, graphene::chain::asset_object const&) const
  1.60   1860.23    43.96                             ripemd160_block_data_order

abitmore added a commit that referenced this issue Jun 25, 2018
nanomobile pushed a commit to nanomobile/bitshares-core that referenced this issue Jul 1, 2018
@abitmore abitmore added 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 9c Large Effort estimation indicating TBD labels Jul 1, 2018
@abitmore
Copy link
Member Author

Short term jobs have been done with #982. Created issue #1204 for long term job. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1b User Story The User Story details a requirement. It may reference a parent Epic. It may reference child Task(s) 2b Gathering Requirements Status indicating currently refining User Stories and defining Requirements 3c Enhancement Classification indicating a change to the functionality of the existing imlementation 4b Normal Priority Priority indicating the moderate impact to system/user -OR- existing workaround is costly to perform 6 Performance Impacts flag identifying system/user efficiency, performance, etc. 6 UX Impact flag identifying the User Interface (UX) 9c Large Effort estimation indicating TBD performance
Projects
None yet
Development

No branches or pull requests

3 participants