Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 4 commits
- 17 files changed
- 4 contributors
Commits on Apr 17, 2024
-
Preallocate the LruCache inside the
TrieCacheand use a Mutex for t……rie caches (#10995) This achieves two distinct things: 1. With the Mutex-based lock around the hashmap of `TrieCache`s we now only hold the lock strictly for as long as necessary, which *may* be as long as it is necessary to create a `TrieCache`, but that's a one-time occurrence outside of resharding scenarios as far as I can tell. 2. With the pre-allocation of the `LruCache` we get rid of the occasionally-very-expensive reallocation of the backing store of this data. --- I haven't been running this code for very long, but these are what the graphs look now (lowpass filter of 5ms for the bottom graph which shows span durations, so for the new graph this means that most of the stuff is under 5ms;; the top graph shows the "current" size of the shard trie caches.) Old(?; I don't actually know what code this node is running):  New:  Most notably gone are the occasional blips up-and-above 200ms range per call. Fixes #10992 --------- Co-authored-by: Bowen Wang <bowen@near.org>
-
routing: remove offloading of unreachable components to DB (#11018)
This behavior was intended as a performance optimization for the specific case in which we lose and regain connectivity to a large component of nodes. Such a thing should not occur except in the case of malicious behavior. There seems to be some problem with the implementation. We observe [traces of Graph::update](https://nearinc.grafana.net/explore?schemaVersion=1&panes=%7B%221j5%22%3A%7B%22datasource%22%3A%22grafanacloud-traces%22%2C%22queries%22%3A%5B%7B%22refId%22%3A%22A%22%2C%22datasource%22%3A%7B%22type%22%3A%22tempo%22%2C%22uid%22%3A%22grafanacloud-traces%22%7D%2C%22queryType%22%3A%22traceqlSearch%22%2C%22limit%22%3A1000%2C%22tableType%22%3A%22spans%22%2C%22query%22%3A%22%22%2C%22filters%22%3A%5B%7B%22id%22%3A%22b341b756%22%2C%22operator%22%3A%22%3D%22%2C%22scope%22%3A%22span%22%2C%22value%22%3A%5B%5D%2C%22valueType%22%3A%22string%22%7D%2C%7B%22id%22%3A%22span-name%22%2C%22tag%22%3A%22name%22%2C%22operator%22%3A%22%3D%22%2C%22scope%22%3A%22span%22%2C%22value%22%3A%5B%22Store%3A%3Acommit%22%5D%2C%22valueType%22%3A%22string%22%7D%2C%7B%22id%22%3A%22min-duration%22%2C%22tag%22%3A%22duration%22%2C%22operator%22%3A%22%3E%22%2C%22valueType%22%3A%22duration%22%2C%22value%22%3A%2250ms%22%7D%2C%7B%22id%22%3A%22service-name%22%2C%22tag%22%3A%22service.name%22%2C%22operator%22%3A%22%3D%22%2C%22scope%22%3A%22resource%22%2C%22value%22%3A%5B%22neard%3Aed25519%3A4XcKemsduTYReCTvWYppWBbeduQKFcyFTCygzBq8Ucdo%22%5D%2C%22valueType%22%3A%22string%22%7D%5D%2C%22spss%22%3A3000%7D%5D%2C%22range%22%3A%7B%22from%22%3A%22now-6h%22%2C%22to%22%3A%22now%22%7D%7D%2C%22z7x%22%3A%7B%22datasource%22%3A%22grafanacloud-traces%22%2C%22queries%22%3A%5B%7B%22query%22%3A%22c6409ed42ee8b1e2909fb6a8df5303f6%22%2C%22queryType%22%3A%22traceql%22%2C%22refId%22%3A%22A%22%2C%22limit%22%3A20%2C%22tableType%22%3A%22traces%22%2C%22datasource%22%3A%7B%22type%22%3A%22tempo%22%2C%22uid%22%3A%22grafanacloud-traces%22%7D%7D%5D%2C%22range%22%3A%7B%22from%22%3A%221712751432916%22%2C%22to%22%3A%221712773032916%22%7D%2C%22panelsState%22%3A%7B%22trace%22%3A%7B%22spanId%22%3A%2236d308fc410f4dc3%22%7D%7D%7D%7D&orgId=1) in which >2s is spent on pop_component after which >2s is spent on push_component. It is not clear what, if anything, we are gaining from this optimization, and the whole routing implementation is planned for deprecation anyway. Rather than spend time digging into this, we should just delete it. --- There is a comment and a test suggesting that there is some benefit of this feature during node startup because we can avoid broadcasting edges which were previously known. Given that only the unreachable edges are stored to DB however, this feature did not actually solve that problem.
-
-
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 1.39.0...1.39.1