Peter Argue

I think integrating this as an optional validation step for submitted transactions on an Access node should be simple enough. The unknown is what kind of performance impact it would...

> I think this does solve half of the problem ... after HCU scripts ran at lesser block height will have the same problem. yea, we hadn't come up with...

> I remember commenting on this ( or creating an issue ) but somehow couldn't find now. (edit: found #961 ) > > Here is what I remember maybe it...

Another interesting section from a CPU profile: This is showing bitswap using 18% of the node's CPU calculating the size of blobs. It's possible to add a cache for bitswap...

Profiles from one of the ANs experiencing slow response times: CPU: Note: * 17% of CPU is used by bitswap looking up the size of recent data blobs * 10%...

Here's an execution trace from a node experiencing slow response times: Note: while there are large blocks of time where a majority of the available cores are used by long...

I attempted to reproduce this on testnet pushing one AN to 87% CPU utilization with: * 1000 request per second across calls to get blocks, events, txresults and accounts. *...

Next steps: * Experiment with disabling DHT on mainnet nodes (lower baseline CPU) * Experiment with directing public traffic to a Flow Foundation access node to test if the issue...

We disabled the DHT on several nodes, but were never able to reproduce this issue on the flow foundation ANs. After migrating to new infra, profiles from the QN nodes...

I noticed that we missed upgrading 3 more ipfs libraries that were moved to the `ipfs/boxo` repo, and opened PRs to upgrade: https://github.com/onflow/flow-go/pull/5774 (master) https://github.com/onflow/flow-go/pull/5777 (feature/stable-cadence) I upgraded one of...