איך אנחנו מטפלים בבקשות

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, REGION_ID.r נכלל בכתובות URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

במאמר הזה מוסבר איך אפליקציית App Engine מקבלת בקשות ושולחת תשובות. פרטים נוספים זמינים במאמר בנושא כותרות של בקשות.

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

טיפול בבקשות

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

‫App Engine מריץ כמה מופעים של האפליקציה, ולכל מופע יש שרת אינטרנט משלו לטיפול בבקשות. כל בקשה יכולה להיות מנותבת לכל מופע, כך שבקשות עוקבות מאותו משתמש לא בהכרח נשלחות לאותו מופע. מופע יכול לטפל בכמה בקשות בו-זמנית. מספר המכונות יכול להשתנות אוטומטית בהתאם לשינויים בתעבורה.

אפליקציית Flask הבאה מגיבה לכל הבקשות מלקוחות אינטרנט לנתיב הבסיס ('/') לגרסה 3.8 ואילך של Python. חשוב לזכור שצריך לעדכן את הקובץ app.yaml כדי להשתמש בגרסה החדשה. מידע נוסף על השימוש בגרסאות החדשות זמין במאמר בנושא Python runtime.

גרסה 3.8 ואילך

from flask import Flask


app = Flask(__name__)


@app.route("/")
def hello() -> str:
    """Return a friendly HTTP greeting.

    Returns:
        A string with the words 'Hello World!'.
    """
    return "Hello World!"


if __name__ == "__main__":
    # This is used when running locally only. When deploying to Google App
    # Engine, a webserver process such as Gunicorn will serve the app.
    app.run(host="127.0.0.1", port=8080, debug=True)

מכסות ומגבלות

‫App Engine מקצה משאבים לאפליקציה באופן אוטומטי ככל שהתנועה גדלה. עם זאת, יש הגבלות:

‫App Engine שומר קיבולת של התאמה אוטומטית לעומס לאפליקציות עם זמן אחזור נמוך, שבהן האפליקציה מגיבה לבקשות תוך פחות משנייה.
יכול להיות שגם אפליקציות שדורשות הרבה משאבי CPU יסבלו מתוספת של זמן אחזור, כדי לשתף משאבים ביעילות עם אפליקציות אחרות באותם שרתים. בקשות לקבצים סטטיים פטורות ממגבלות ההשהיה האלה.

כל בקשה נכנסת לאפליקציה נספרת במסגרת המגבלה של בקשות. הנתונים שנשלחים בתגובה לבקשה נספרים במסגרת המגבלה של רוחב פס יוצא (ניתן לחיוב).

גם בקשות HTTP וגם בקשות HTTPS (מאובטחות) נספרות במגבלות Requests,‏ Incoming Bandwidth (billable) ו-Outgoing Bandwidth (billable). בדף פרטי המכסה בGoogle Cloud מסוףGoogle Cloud מופיעים גם הערכים Secure Requests, ‏ Secure Incoming Bandwidth ו-Secure Outgoing Bandwidth בנפרד, למטרות מידע. רק בקשות HTTPS נספרות בערכים האלה. מידע נוסף זמין בדף מכסות.

המגבלות הבאות חלות באופן ספציפי על השימוש ב-request handlers:

מגבלות על בקשות

הגודל המקסימלי של כותרות הבקשה הוא ‎~15KB.
הגודל הכולל של הבקשה מוגבל ל-32MB בערך.
כל הבקשות מסוג HTTP/2 יתורגמו לבקשות מסוג HTTP/1.1 כשהן יועברו לשרת האפליקציות.
חיבורי SSL מסתיימים במאזן העומסים. התנועה ממאזן העומסים נשלחת למופע דרך ערוץ מוצפן, ואז מועברת לשרת האפליקציה דרך HTTP. הכותרת X-Forwarded-Proto מאפשרת לכם להבין אם בקשת המקור הייתה HTTP או HTTPS.

מגבלות על תשובות

התשובות נשמרות בזיכרון המטמון בבלוקים של 64k.
גודל התשובה הוא בלתי מוגבל.
הגבלת זמן התגובה היא שעה אחת.
המגבלה על כותרת התגובה היא 64KB. כותרות תגובה שחורגות מהמגבלה הזו יחזירו שגיאות HTTP 502, ויוצגו ביומנים upstream sent too big header while reading response header from upstream.

בקשות HTTP שלא נתמכות

התכונות הבאות לא נתמכות בסביבה הגמישה של App Engine:

תעבורת HTTP/2 לשירות הקצה העורפי.
בקשות HTTP שמאפשרות גישה ישירה למופעים.

כותרות של בקשות

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

מידע נוסף זמין במאמר בנושא כותרות של בקשות.

השבתת תהליך אגירת הנתונים

כברירת מחדל, כל התגובות מ-App Engine נשמרות בזיכרון זמני בבלוקים של 64k. במקרים מסוימים, כדאי להשבית את האגירה בזיכרון ולשדר ישירות בסטרימינג בייטים ללקוח. בדרך כלל עדיף להשתמש בשיטה הזו כשמשתמשים בבקשות GET תלויות או באירועים שנשלחים מהשרת (SSE). כדי להשבית את השמירה בזיכרון, אפשר להגדיר את כותרת התגובה X-Accel-Buffering לערך no.

הפעלת חיבורי HTTPS

מטעמי אבטחה, כל האפליקציות צריכות לעודד את הלקוחות להתחבר באמצעות https. כדי להנחות את הדפדפן להעדיף https על פני http בדף מסוים או בדומיין שלם, צריך להגדיר את הכותרת Strict-Transport-Security בתגובות. לדוגמה:

Strict-Transport-Security: max-age=31536000; includeSubDomains

כדי להגדיר את הכותרת הזו לתשובות שנוצרות מהקוד שלכם, משתמשים בספרייה flask-talisman.

טיפול בעבודות אסינכרוניות ברקע

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

לגבי משימות שפועלות לאורך זמן, מומלץ להשתמש ב-Cloud Tasks. ב-Cloud Tasks, בקשות HTTP הן ארוכות טווח ומחזירות תשובה רק אחרי סיום של עבודה אסינכרונית.