-
Notifications
You must be signed in to change notification settings - Fork 1
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
Combine async and multiproc for speedup #6
Comments
It would no longer be possible to avoid these superfluous GET requests if the GET requests for episode metadata become asynchronous (or more optimistically: it would not be possible within an async batch) Nevertheless I expect it would give a speedup, so I will retain both forms when refactoring the synchronous approach to an async one (so I can compare before/after) The current time to load the past 30 days is about 40-60 seconds |
The problem as it stands is that the We can defer this from happening on init ( |
Error (timeout?) occurring due to bug in the HTTP2 implementation in httpx encode/httpx#841 Click to show traceback
The last line in particular: "NO_ERROR", "additional_data:None" Consider switching http2 off for the broadcasts (or... batch/retry?) Solution: RTFM! As mentioned on the above issue tracker thread, it's not a bug but a feature of client = httpx.Client() # Use a default 5s timeout everywhere.
client = httpx.Client(timeout=10.0) # Use a default 10s timeout everywhere.
client = httpx.Client(timeout=None) # Disable all timeouts by default. Upon setting this, I'm still seeing timeout errors (hanging indefinitely if set to None), even with HTTP/1, so it's not due to HTTP/2 specifically (I'd suggest a retry mechanism in that case) I don't get the timeouts so frequently when I set the task limit lower (I tried increasing from 30 to 100, definitely saw more hangs/timeouts at 100)
|
Still obtaining an error (rarely) from HTTP/1.1 (this one?)
|
Fixed the async bugs with up to 3 retries (now silent), no need for multiproc, async processing with |
Look into the aioprocessing library
ChannelListings
waits for all requests to return (even though they are handled asynchronously and could therefore use a callback)aioprocessing
would mean the batches begin before the last GET request is returned: meaning they would surely finish soonerThe text was updated successfully, but these errors were encountered: