Bunch of notes from me:
- Some API nodes (like mine) might have rate limiting enabled
- There's no point in using
SKIP_BY_TX_ID=ONthese days - There's no need using such frequent
get_dynamic_propertiescalls, blocks won't come faster than once per 3 seconds - You can use
transaction_status_apito track status of transactions, it should be way cheaper in matter of computer resources - You could use local instance of a simple consensus node with
transaction_status_apiwhere you could run frequent calls against, while still using public node with account history for other calls.
Thanks @gtg for your points.
That explains why there is a variation in the response times.
Yes - We may need to create a post and inform everyone that the RocksDB based plugin works just fine irrespective either options.
I got confused by this one big time. At first ended up concluding the disparity from the TESTNET and the mainnet is this option. Only handful of nodes have this option using at this point.
The last 3 points ---> Yes, we are trying to use different calls and optimizing the workflow and it looks like the performance of the listener is much better now.
As for the local node, these nodes already runs a graphene based chain and we are trying to reduce the over all expense to run the sidechain nodes. This is one of the reasons to go with the public nodes.
Further it looks like HAF may make things even better and we can ignore the account history altogether.