-
Notifications
You must be signed in to change notification settings - Fork 52
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
Bluesky: look into optimizing API calls #1597
Comments
No it does! I just was unaware of how the caching works to begin with. Happy to have a look :) |
Actually it looks like Bluesky is already using the cache for replies, reposts and likes? |
You're right, granary reads and writes it, and it gets passed through from the Lines 132 to 144 in 8c809d2
...and yet it's not working. Hmm. 😐 Maybe first check if any of the |
OH |
This might actually be (part of?) the cause of #1592 |
Huh, you're probably right! Great catch. |
(@JoelOtter you should hopefully be able to see the dashboard too, feel free to poke around: https://console.cloud.google.com/monitoring/dashboards/builder/0e3a0a00-ce6f-4f3e-a907-4ddabd3288a6;duration=PT24H?project=brid-gy&dashboardBuilderState=%257B%2522editModeEnabled%2522%3Afalse%257D ) |
Wow! Bluesky only has 26 users, ~1% of all active users that we poll, but it's already the solid majority of all outbound HTTP requests! We should eventually look into optimizing those. First step would be to get the like/repost cache working, based on counts, and only fetch those when the count increases...but I'm not sure the Bluesky API gives us those counts? cc @JoelOtter
The text was updated successfully, but these errors were encountered: