-
Notifications
You must be signed in to change notification settings - Fork 0
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
Switch from requests to httpx #10
Labels
enhancement
New feature or request
Comments
import logging
import threading
import time
import httpx
logging.basicConfig(format='%(asctime)s %(threadName)s %(filename)s:%(lineno)s] %(message)s',
level=logging.DEBUG)
client = httpx.Client(http2=True, timeout=15)
t = threading.Thread(target=lambda: logging.info('%s', client.get('https://httpbin.org/delay/10')))
t.start()
time.sleep(5)
logging.info('%s', client.get('https://httpbin.org/get'))
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Splitting this out from #9.
I haven't done a lot of testing, but 0045680 seems to have intermittently but significantly reduced response time, presumably by eliminating both the TCP handshake (to the Netherlands) and TLS negotiation for some requests.
Right now, each thread gets its own
requests.Session
, so each bot's long-pollSession
stays active pretty much constantly but the main thread'sSession
(and any connections it maintains) can go idle potentially for hours at a time (and hence time out and need to be reestablished before a response can be delivered).encode/httpx#1633 (comment)
However, changing
requests.py
to:consistently gives:
which suggests that requests to the same host are serialized (the
editMessageCaption
didn't complete until 1 ms after a previousgetUpdates
completed). A quick test seems to confirm this is an actual effect, not just a discrepancy in the logging:The exact timing (
getUpdates
returning at1724451079.5572999
andgetMe
returning at1724451079.5575902
, 290 µs — not ms — later) suggests the requests did actually go out as requested, but something caused the responses to stack up. I haven't dug deeply enough to figure out if this is actually happening in the HTTP/2 stream or if this is happening somewhere inside httpx.Even more worryingly:
but I have not been able to reliably reproduce this, so I don't know if this is something like a really tight race in httpx or if TBA just decided to dump a connection at the perfect wrong time. Either way, though, I think this is showing that both requests were canceled, i.e. if TBA dumped the connection during
getUpdates
it caused the subsequentgetMe
to fail too, rather than trigger a reconnect 🙁.The text was updated successfully, but these errors were encountered: