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

מזהה אזור

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

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

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

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

הטיפול בבקשות

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

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

אפליקציית Flask הבאה מגיבה לכל הבקשות מלקוחות אינטרנט לנתיב הבסיס ('/') ל-Python בגרסה 3.8 ואילך. חשוב לזכור שצריך לעדכן את הקובץ 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 (מאובטחות) נספרות במגבלות של בקשות, רוחב פס נכנס (לחיוב) ורוחב פס יוצא (לחיוב). בדף פרטי המכסה בGoogle Cloud מסוף מופיעים גם הערכים בקשות מאובטחות, רוחב פס נכנס מאובטח ורוחב פס יוצא מאובטח, למטרות מידע. רק בקשות 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 הן ארוכות טווח ומחזירות תשובה רק אחרי סיום של עבודה אסינכרונית.