2

Task Compute some fields for all table rows when action called contract::priceupdate(price)

Input data: Table with 10000 rows

Problem Cpu limit 30ms so i cant update whole table in 1 transaction

Idea batch update rows by 100 per transaction

create transactions(rows / 100) in action priceupdate.

Question What is best practices for my case how to avoid cpu limits?

Improve this question

2 Answers 2

Reset to default
2

Your idea is along the right lines. Either do batch updates, where you keep track using a seperate table to indicate current progress. Or right an action which takes the primary key as an argument, and prepare many actions using a script to update table rows one at a time by primary key.

Improve this answer
2
  • Thank for answer. I think about use field updated_at(indexed timestamp) and read sorted by this field. if (time() - timestamp > 60) compute fields. And run in the background transaction monitor for relaunch(with backoff policy) transaction if error cpu usage limit
    – v.tsurka
    Commented Feb 21, 2019 at 0:07
  • Or right an action which takes the primary key as an argument, and prepare many actions using a script to update table rows one at a time by primary key. This solution also good but provide more depends on backend process i try to reduce such deps in system design. Because its additional point of failure
    – v.tsurka
    Commented Feb 21, 2019 at 2:18
2

I ran into this issue as well. The batch updating and is a good solution, but maybe slow if you only perform one batch per transaction. If your records are independent you can use a Flooding/Recursive approach which will run multiple batches per transaction.

I described this in a similar question where I wanted to delete all entries of a large table. Check it out here:

Delete all multi_index records without iterator?

Like @Phillip Hamnett - EOS42 said it also maybe good to store the current progress in a separate table.

Improve this answer
2
  • thank for share ur experience. As i right understand u got some issues with deferred transaction. So we cant rely on creation internal transaction and we need to flood in offchain? cleos push action mycontract dtseq '['7', '0']' -p mycontract@active
    – v.tsurka
    Commented Feb 25, 2019 at 8:01
  • Yeah. Deferred transactions are not guaranteed to be executed. That's why Phillip Hamnett suggests keeping track in another table. By flooding you increase the probability of accepted deferred transactions and you may speed up the process by executing multiple instances of your action per block.
    – tmm ♦
    Commented Feb 26, 2019 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.