HTTPX PoolTimeout אינו פסק זמן של חיבור לפרוקסי

PoolTimeout אומר ש-HTTPX לא הצליח לקבל חיבור מהמאגר בתוך זמן ההמתנה שהוגדר. זו אינה הוכחה שפג הזמן של חיבור TCP חדש לפרוקסי. הבקשה השנייה אולי עדיין ממתינה בתוך התהליך שלכם.

קל לשחזר זאת כשהלקוח מאפשר חיבור אחד והתגובה המוזרמת הראשונה נשארת פתוחה. התחלת בקשה נוספת אינה משחררת את החיבור הזה מעצמה.

הבהירו מי אחראי לתגובה המוזרמת

import httpx

limits = httpx.Limits(
    max_connections=1,
    max_keepalive_connections=1,
)
timeout = httpx.Timeout(
    connect=5, read=10, write=10, pool=1
)

with httpx.Client(
    proxy="http://203.0.113.10:8080",
    trust_env=False,
    limits=limits,
    timeout=timeout,
) as client:
    with client.stream("GET", "https://example.com/") as response:
        print(response.status_code)
        for chunk in response.iter_bytes():
            print(len(chunk))

    next_response = client.get("https://example.com/")
    print(next_response.status_code)

החליפו את כתובת הפרוקסי לצורכי תיעוד לפני ההרצה. הבקשה הבאה מתחילה אחרי היציאה מהקשר הזרם. היציאה סוגרת את התגובה גם אם הקוד יוצא מהלולאה או מעלה חריגה.

בהזרמה ידנית, כמו client.send(request, stream=True), הקוד שלכם אחראי לסגירה הסופית. ב-AsyncClient ממתינים לניקוי הידני המקביל באמצעות response.aclose(). סגירת תגובה שלא נקראה מפנה קיבולת, אבל עשויה לחייב השלכת החיבור שבבסיסה במקום שימוש חוזר בו.

קראו את שם החריגה

ConnectTimeout נוגע להקמת חיבור. ReadTimeout נוגע להמתנה לנתוני תגובה. PoolTimeout נוגע לקבלת מקום לחיבור. תיעוד של «פסק זמן בפרוקסי» בלבד מאבד את ההבחנה הנחוצה לבחירת תיקון.

בדקו תגובות פתוחות, משימות מקבילות ומגבלות חיבור לפני החלפת כתובות IP של נקודות קצה. מאגר גדול יותר עשוי להתאים לעומס מקבילי מוצדק, אבל אינו מתקן תגובות שמעולם לא נסגרות. הוא רק נותן ליישום יותר קיבולת לתפוס.

שמרו את הלקוח לשימוש חוזר לאורך עומס העבודה. יצירתו מחדש כדי שכל בקשה תיראה פועלת עלולה להסתיר בעיית מחזור חיים ולאבד שימוש חוזר בחיבורים.