This is a fantastic explanation of the problem that should be user digestible.
I really like the solution of migrating the poor performing traffic so most of the traffic is unaffected.
You are viewing a single comment's thread from:
This is a fantastic explanation of the problem that should be user digestible.
I really like the solution of migrating the poor performing traffic so most of the traffic is unaffected.
Well, I'm sure parts of it will be pretty hard to digest, such as "worker threads", but hopefully the gist of it will be understandable.
It makes enough sense to a noob (me) that I can understand what is happening and why :)
I just picture a disoriented Roomba trying to play cards (52 Pickup) and getting clogged. Am I close?
Close enough, the hived was getting clogged up by bad traffic (the cards), so it couldn't handle even the good traffic (dust).
And although I didn't mention it in the post, perhaps surprisingly, even the bad traffic processes better without having the read-only traffic on the same node. The two types of traffic don't mix well due to some weaknesses in hived's current database locking mechanism.
HAF-based applications will help a lot with this latter issue too, because most of our read-only traffic will be migrating from the hived node to the HAF node. We've done this a lot already with our earlier optimization work on hived and hivemind, but HAF will allow us to migrate more API calls away from hived nodes so that they can focus on their primary job which is processing transactions.
No point in jamming the squares and triangles through the round holes if you don't have to. Those are blocks, this is a blockchain; see what I did there?
52 Pickup is the only game I know how to play.
What's your high score?
Less than the Roomba