Httpx 5 second delay
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- python
- Lĩnh vực
- backend, networking
Hướng nghiên cứu
Bắt đầu với handler get_all_sites_health và hàm perform_get_probe được cung cấp, tái hiện các yêu cầu đồng thời đến khoảng 100 URL bằng httpx và so sánh chúng với aiohttp. Theo dõi hành vi DNS và kết nối dưới tải này; được xem là hoàn tất khi đã xác định được nguyên nhân của các độ trễ lặp lại năm giây và các lỗi DNS của Docker, đồng thời hành vi bị ảnh hưởng được bao phủ bởi một kiểm tra hồi quy phù hợp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Originally opened by
@dhensenon 2023-12-15 22:05:14 in encode/httpx
Hi all,
Httpx version: I'm still on httpx 24.1 because I had to downgrade because of https://github.com/encode/httpx/pull/2929
Expectation:
I expect my http calls not to get delayed by a constant 5 seconds.
Actual:
My http calls are delayed with a constant 5 seconds, plus I get DNS related logs from dockerd.
Long story
I noticed in my system logs weird docker dns issues:
Click to see logs
Dec 15 22:53:44 my-hostname dockerd[1601]: time="2023-12-15T22:53:44.285539223+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;gameboy2023.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:53713->192.168.50.1:53: i/o timeout" Dec 15 22:53:44 my-hostname dockerd[1601]: time="2023-12-15T22:53:44.296076826+01:00" level=error msg="[resolver] failed to query DNS server: 1.1.1.1:53, query: ;ht.my-site-ommitted.nl.\tIN\t A" error="read udp 172.28.0.105:43077->1.1.1.1:53: i/o timeout" Dec 15 22:53:44 my-hostname dockerd[1601]: time="2023-12-15T22:53:44.296120525+01:00" level=error msg="[resolver] failed to query DNS server: 1.1.1.1:53, query: ;ht.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.105:60254->1.1.1.1:53: i/o timeout" Dec 15 22:53:44 my-hostname dockerd[1601]: time="2023-12-15T22:53:44.305453453+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;theultimatenerdconf.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:49108->192.168.50.1:53: i/o timeout" Dec 15 22:53:48 my-hostname dockerd[1601]: time="2023-12-15T22:53:48.364826590+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;zongaatonder.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:48923->192.168.50.1:53: i/o timeout" Dec 15 22:53:48 my-hostname dockerd[1601]: time="2023-12-15T22:53:48.366090453+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;top10movies.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:56201->192.168.50.1:53: i/o timeout" Dec 15 22:53:52 my-hostname dockerd[1601]: time="2023-12-15T22:53:52.496770882+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;gameboy2023.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:49707->192.168.50.1:53: i/o timeout" Dec 15 22:53:52 my-hostname dockerd[1601]: time="2023-12-15T22:53:52.508179669+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;ergotherapie2.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:51178->192.168.50.1:53: i/o timeout" Dec 15 22:53:56 my-hostname dockerd[1601]: time="2023-12-15T22:53:56.515096544+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;theultimatenerdconf.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:33374->192.168.50.1:53: i/o timeout" Dec 15 22:53:56 my-hostname dockerd[1601]: time="2023-12-15T22:53:56.590845767+01:00" level=error msg="[resolver] failed to query DNS server: 192.168.50.1:53, query: ;zongaatonder.my-site-ommitted.nl.\tIN\t AAAA" error="read udp 172.28.0.3:60863->192.168.50.1:53: i/o timeout"
It always used to happen when I was doing health probes on about a 100 websites asynchronous as the same moment. I discovered this issue 2 weeks ago, but today got the time to dig into this. I suspected it was httpx, but I had no proof other than running into long timeouts for http calls to sites that were supposed to be fast.
I also ran while true; do dig "https://$(tr -dc 'a-zA-Z0-9' </dev/urandom | head -c 10).my-site-ommittedd.nl"; done on my host and inside docker on that same host to see if there is a docker related DNS issue. Running this large amount of DNS lookups do not result into the same system logs I saw from when my api was doing lookups using httpx. So httpx became my prime suspect.
I then changed up my implementation to retrieve all my site urls (there are a little over 100 in db) and make it so I can swap httpx for aiohttp (I'm sorry, I can image reading this hurts 💔 )
With aiohttp my problem disappears and I get normal response times. All 106 response times are below 1.2 seconds, with the lowest being 0.07.
With httpx about 64 out of 106 come with the 5.xx seconds (out of 106 calls only 1 fails, so no TimeoutException) AND system logs appear. Now I think those logs are trying to tell that the dns query wasn't read, hence the i/o timeout at the end of each log line.
So my bug is about what is httpx doing with regards to DNS? What could lead to the issues I'm describing.
This is an excerpt of my code (based on Sanic):
async def get_all_site_urls(conn):
async with conn.cursor(aiomysql.DictCursor) as cur:
await cur.execute("SELECT site_url FROM site_config")
site_configs = await cur.fetchall()
return [x["site_url"] for x in site_configs]
`@app`.get("/all_sites_health/<client_type>", name="get all sites health")
async def get_all_sites_health(request, client_type: str):
site_urls = await get_all_site_urls(request.ctx.conn)
# TODO set better timeouts on teh http clients, use defaults for now
if client_type == "aiohttp":
http_client_cls = aiohttp.ClientSession
# timeout 5 seconds per conn/read/write/pool
else:
http_client_cls = httpx.AsyncClient
# timeout 300 seconds by default
async with http_client_cls() as http_client:
tasks = []
for url in site_urls:
task = asyncio.create_task(perform_get_probe(http_client, url))
tasks.append(task)
results = await asyncio.gather(*tasks)
return response.json({"res": results})
async def perform_get_probe(http_client, site_url: str):
start = perf_counter()
try:
res = await http_client.get(site_url)
try:
healthy = res.status_code == 200 # httpx
except AttributeError:
healthy = res.status == 200 # aiohttp
except (httpx.RequestError, aiohttp.ClientError):
healthy = False
duration = perf_counter() - start
return site_url, healthy, duration
- Ngôn ngữ chính
- Python
- Star
- 1.6k
- Fork
- 103
- Merge trung bình
- 1 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của pydantic/httpx2
-
Please revert aiter_bytes signature to AsyncIteratorCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
pydantic/httpx2#1158 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Export AutoBackendCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
pydantic/httpx2#1131 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Mention header name error message for invalid header encodingsCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
pydantic/httpx2#864 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Support DigestAuth with "x-www-authenticate" in first response headerCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của pydantic/httpx2
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
OCA/account-invoicing#2529 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area/ci
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ImageGen generate-batch aborts valid JSONL jobs containing a Unicode line separator in poster textĐang mởbug imagen skills
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Email validation accepts a trailing newlineCó thể đã có người làm @marcello-pichini đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày