Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds test for blockheight for all endpoints #141

Merged

Conversation

yashasvi-ranawat
Copy link
Contributor

@yashasvi-ranawat yashasvi-ranawat commented Apr 21, 2024

A method is added to NetworkAPI that sanitizes the endpoints; where the endpoints that are unreachable or are un-synced (based on their given blockheight) are removed.

This fixes issues like #140

@yashasvi-ranawat
Copy link
Contributor Author

Why didn't the tests trigger?

@merc1er
Copy link
Member

merc1er commented Apr 22, 2024

Why didn't the tests trigger?

Good question. We've always had this issue I believe. The tests are supposed to run on your fork. I'll see if there's some settings preventing this in this repo.

@merc1er
Copy link
Member

merc1er commented Apr 22, 2024

Settings look OK...
Screenshot 2024-04-22 at 10 08 07

Anyway, I'll review and test locally for now.

@ssmycelium
Copy link

This is very clever! Nice work!

Copy link
Member

@merc1er merc1er left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yashasvi-ranawat thank you for this PR 🙏🏻

I have been testing it, and it's working great so far. But it is now taking much longer to perform any network action.

For example, get_balance():

In [7]: import time
   ...: 
   ...: start_time = time.time()
   ...: key.get_balance()
   ...: end_time = time.time()
   ...: elapsed_time = end_time - start_time
   ...: print("Time to get balance: " + str(elapsed_time) + " seconds")

# BEFORE
Time to get balance: 0.37384819984436035 seconds

# AFTER
Time to get balance: 2.398766279220581 seconds

The difference is too important. I'm thinking a way to mitigate this would be to cache the provider so the block height is not fetched every time.

@yashasvi-ranawat
Copy link
Contributor Author

yashasvi-ranawat commented Apr 25, 2024

I'm thinking a way to mitigate this would be to cache the provider so the block height is not fetched every time.

I implemented a time-to-live cache for blockheight with cache time limit of 120s.

Implementation Wall time
No blockheight based sanitation 365ms
Cached blockheight, first hit 2.71s
Cached blockheight, second hit 1.05s
Cached blockheight, no unresponsive bitcoin.com api, first hit 1.34s
Cached blockheight, no unresponsive bitcoin.com api, second hit 514ms

We can remove the second default API in BitcoinDotComAPI, which is the, now unresponsive, rest.bitcoin.com. It causes much delay in blockheight retrieval.

@yashasvi-ranawat
Copy link
Contributor Author

yashasvi-ranawat commented Apr 25, 2024

oh python 3.8 functools does not have cache! Although it'll be at its end-of-life this October; don't know if I want to implement a custom cache for it.

@merc1er
Copy link
Member

merc1er commented Apr 26, 2024

Thanks! Yes we can definitely remove rest.Bitcoin.com and drop Python 3.8 support.

However, there is already a caching system present in BitCash for currency conversion support: set_rate_cache_time

Why not use something like this instead? Just a question, no need to re-implement everything. I can submit a PR removing rest.Bitcoin.com in the meantime.

@merc1er
Copy link
Member

merc1er commented Apr 26, 2024

@yashasvi-ranawat I have prepared a PR removing rest.Bitcoin.com. Feel free to review it if you have the time (I completely understand if not; in which case I will merge).

#143

@yashasvi-ranawat
Copy link
Contributor Author

However, there is already a caching system present in BitCash for currency conversion support: set_rate_cache_time

yeah, good idea! I'll have a look.

@yashasvi-ranawat
Copy link
Contributor Author

I had a look at the cache setup for rates API! It was similar to the one I added to utils, but was specific to use for rates API. I refactored the one in utils to cache multiple entries with LRU cache. This is now usable by both blockheight caching and rates caching. I updated the tests accordingly.

@yashasvi-ranawat
Copy link
Contributor Author

yashasvi-ranawat commented May 5, 2024

I further refactored to caching of sanitized endpoints, instead of endpoint's blockheight. This drastically improves wall time.

Implementation Wall time
No blockheight based sanitisation 365 ms
Cached sanitized endpoints, first hit 1.28 s
Cached sanitized endpoints, second hit 198 ms

This PR is ready for review!

Improves implementation speed drastically.
Copy link
Member

@merc1er merc1er left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Outstanding work, thank you for yet another contribution!

Everything is working for me, it's much faster after the first call, and the code looks good, so I am approving.

Note that https://demo.chaingraph.cash/v1/graphql has been out of sync for a very long time, so I may consider removing it at some point.


Blockheight for <bitcash.network.APIs.ChaingraphAPI.ChaingraphAPI object at 0x10561f020>: 844258
Blockheight for <bitcash.network.APIs.ChaingraphAPI.ChaingraphAPI object at 0x10561f260>: 844477
Blockheight for <bitcash.network.APIs.BitcoinDotComAPI.BitcoinDotComAPI object at 0x105708bc0>: 844477
(<bitcash.network.APIs.ChaingraphAPI.ChaingraphAPI object at 0x10561f260>, <bitcash.network.APIs.BitcoinDotComAPI.BitcoinDotComAPI object at 0x105708bc0>)

@merc1er merc1er merged commit aa93bd6 into pybitcash:master May 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants