Comments (4)
Traffic Today (Analysis)
I've looked at what mainnet traffic currently looks like. Very roughly, the summary is:
- 60% of receipts involve
token.sweat
record_batch
byoracle.sweat
makes up about 20% of that but is gas heavier than the average tx- account funding by
sweat_welcome.near
makes up about 15% - another 15% are claims in tge-lockup
- the remaining 50% are probably
ft_transfer
receipts, triggered by claims or other sources
- 20% aurora
- 13% nearcrowd
- 4% spin.fi
- 3% ref-finance
Proposed Benchmark Workload
Based on that rough analysis, I want to create a benchmark with 20M daily transactions distributed like this:
- 5M SocialDB (all on a single contract)
- 5M Sweat (90% simple calls, 10% record batch which will test our storage, all on a single contract with large state)
- 5M non-Sweat FT (spread across multiple contracts)
- 3M aurora (single contract, only workload on aurora shard)
- 2M nearcrowd (multiple contracts)
This tries to project how traffic could grow from today (300k daily tx) to 20M daily tx.
One assumption we established at the start of the quarter was 5M of that should be from social DB.
The remainder I have now defined.
I allocate 10M to FT use cases because Sweat today already takes >50% of TPS.
But instead of forcing it all onto a single account, I want to spread the load across shards, so I split it evenly between Sweat and "other" FTs. That could also simulate more loyalty-program-like use cases coming to near, which isn't unlikely given the success of Sweat.
Then I thought aurora and nearcrowd shouldn't be missing either, given they have >10% of the tx volume each. Aurora is slightly larger today, so I think 3M aurora & 2M nearcrowd makes sense. Note that aurora transactions also consume much more gas than nearcrowd transactions.
Notably, de-fi is missing completely. We could add that later but for now I want to focus on the more common and more performance-critical use cases.
cc @akhi3030 @bowenwang1996 please let me know if you have concerns regarding my proposed benchmark workload
from nearcore.
This seems like a good approach to me.
from nearcore.
Currently the plan is to:
- Integrate the SWEAT workload (only a couple more PRs, code is mostly ready)
- Don't integrate aurora / nearcrowd for now. If we want to extend the benchmark in the future, this could be done but it's currently not the highest priority.
from nearcore.
I have been running with Sweatcoin batches for a while now and I managed to make it work. However, there is one remaining annoying issue: record_batch
can only be called by a registered oracle account, and registering an oracle can only be done by the owner of the contract account.
Currently I create one oracle for each worker. The problem then is that all users of the worker will share one oracle. This results in nonce conflicts. Sometimes this results in a simple retry and things work fine after that. But the most annoying case is where the RPC node accepts the transaction, as the nonce would be valid at the time, but the validator filters it out in its tx pool. Then the user ends up waiting forever (cut off is currently at 30min) and never see a useful error.
I think I can resolve it by using multiple keys per oracle but I'm not sure if I'm willing to spend the extra effort on this just yet.
from nearcore.
Related Issues (20)
- Header sync incorrectly disregards peers at startup
- [Epoch Sync] EpochInfoAggregator treatment is awkward at the epoch sync boundary
- [Epoch Sync] Implement EpochSyncProof validation
- [Epoch Sync] Network message size optimization
- [Epoch Sync] Implement deriving EpochSyncProof from an older EpochSyncProof
- [Epoch Sync] Error in gc: DB Not Found Error: BLOCK HEADER: 11111111111111111111111111111111
- [Epoch Sync] Implement network rate limiting and caching for EpochSyncRequest
- [Epoch Sync] Minor: Header sync progress is misleading after epoch sync
- Spoofed compute costs metrics
- Chunk endorsement by shard metrics must use shards chunks-endorsed, instead of shard chunks-produced
- Tracking issue for fixing minimal required stake HOT 2
- [Epoch Sync] Blocks received during state sync marked as invalid
- mainnet: synced node has regular Downloading blocks logs HOT 3
- [ReshardingV3] Receipts Reassignment HOT 1
- [EpochSync] Defend against malicious peers sending invalid epoch sync
- Difficulties Managing Gas Allocation for Chained Cross-Contract Calls HOT 2
- publishing: add a CI task to test packaging/building of all published crates individually HOT 1
- High cardinality metric HOT 4
- Downloading blocks stuck at 0.00% HOT 3
- Removing the validator key and then sending SIGHUP to the neard process does not appear to stop it validating
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nearcore.