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

מזהה אזור

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

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

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

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

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

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

‫App Engine מריץ כמה מופעים של האפליקציה, ולכל מופע יש שרת אינטרנט משלו לטיפול בבקשות. כל בקשה יכולה להיות מנותבת לכל מופע, כך שבקשות עוקבות מאותו משתמש לא בהכרח נשלחות לאותו מופע. מופע יכול לטפל בכמה בקשות בו-זמנית. מספר המכונות יכול להשתנות אוטומטית בהתאם לשינויים בתעבורה. אפשר גם לשנות את מספר הבקשות המקבילות שמופע יכול לטפל בהן על ידי הגדרת הרכיב max_concurrent_requests בקובץ app.yaml או בקובץ appengine-web.xml אם משתמשים בשירותים המצורפים מדור קודם של App Engine.

בדוגמה הבאה מוצג סקריפט Python שמגיב לכל בקשת HTTP בהודעה Hello World!.

# Copyright 2018 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

from flask import Flask


# If `entrypoint` is not defined in app.yaml, App Engine will look for an app
# called `app` in `main.py`.
app = Flask(__name__)


@app.route("/")
def hello():
    """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. You
    # can configure startup instructions by adding `entrypoint` to app.yaml.
    app.run(host="127.0.0.1", port=8080, debug=True)

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

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

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

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

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

גם בקשות HTTP וגם בקשות HTTPS (מאובטחות) נספרות במגבלות של בקשות, רוחב פס נכנס (לחיוב) ורוחב פס יוצא (לחיוב). בדף פרטי המכסה בGoogle Cloud מסוף מופיעים גם הערכים בקשות מאובטחות, רוחב פס נכנס מאובטח ורוחב פס יוצא מאובטח, למטרות מידע. רק בקשות HTTPS נספרות בערכים האלה. מידע נוסף זמין בדף מכסות.

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

הגבלה סכום
גודל הבקשה ‫32 מגה-בייט
גודל התשובה ‫32 מגה-בייט
משך הבקשה הסתיים תלוי בסוג ההתאמה לגודל המסך שבו נעשה שימוש באפליקציה
מספר הקבצים הכולל המקסימלי (קבצי אפליקציה וקבצים סטטיים) ‫10,000 בסך הכול
‫1,000 לכל ספרייה
הגודל המקסימלי של קובץ בקשה ‫32 מגה-בייט
הגודל המקסימלי של קובץ סטטי ‫32 מגה-בייט
הגודל הכולל המקסימלי של כל הקבצים הסטטיים וקבצי האפליקציה הגיגה-בייט הראשון הוא בחינם
‎$ 0.026 לגיגה-בייט לחודש אחרי הגיגה-בייט הראשון
הזמן הקצוב לתפוגת בקשה בהמתנה ‫10 שניות
הגודל המקסימלי של שדה כותרת בקשה יחיד ‫8 קילובייט עבור סביבות זמן ריצה מהדור השני בסביבה הרגילה. בקשות לסביבות זמן הריצה האלה עם שדות כותרת שגודלם עולה על 8 קילובייט יחזירו שגיאות HTTP 400.

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

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

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

  • התשובות הדינמיות מוגבלות ל-32MB. אם רכיב handler של סקריפט יוצר תגובה שגדולה מהמגבלה הזו, השרת מחזיר תגובה ריקה עם קוד הסטטוס 500 Internal Server Error (שגיאת שרת פנימית). המגבלה הזו לא חלה על תגובות שמציגות נתונים מ-Cloud Storage או מ-Blobstore API מדור קודם, אם הוא זמין בסביבת זמן הריצה שלכם.

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

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

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

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

טיפול בזמן קצוב לתפוגת בקשה

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

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

תשובות

‫App Engine קורא לסקריפט של ה-handler עם Request ומחכה שהסקריפט יחזיר ערך. כל הנתונים שנכתבים לזרם הפלט הרגיל נשלחים כתגובת ה-HTTP.

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

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

הצגת התשובות באופן שוטף

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

דחיסת תשובות

אם התנאים הבאים מתקיימים, App Engine דוחס את הנתונים בתגובות שמוחזרות על ידי הקוד:

  • הבקשה מכילה את הכותרת Accept-Encoding שכוללת את gzip כערך.
  • התגובה מכילה נתונים מבוססי-טקסט כמו HTML,‏ CSS או JavaScript.

במקרה של תגובות שמוחזרות על ידי מטפל בקובץ או בספרייה סטטיים ב-App Engine, נתוני התגובה נדחסים אם כל התנאים הבאים מתקיימים:

  • הבקשה כוללת את הפרמטר Accept-Encoding עם gzip כאחד מהערכים שלו.
  • הלקוח יכול לקבל את נתוני התגובה בפורמט דחוס. רכיב הקצה הקדמי של Google‏ (GFE) מנהל רשימה של לקוחות שידוע שיש להם בעיות בתגובות דחוסות. הלקוחות האלה לא יקבלו נתונים דחוסים ממטפלים סטטיים באפליקציה, גם אם כותרות הבקשה מכילות את Accept-Encoding: gzip.
  • התגובה מכילה נתונים מבוססי-טקסט כמו HTML,‏ CSS או JavaScript.

שימו לב לנקודות הבאות:

  • לקוח יכול לכפות דחיסה של סוגי תוכן מבוססי-טקסט על ידי הגדרת שני ראשי הבקשה Accept-Encoding ו-User-Agent לערך gzip.

  • אם בבקשה לא מצוין gzip בכותרת Accept-Encoding,‏ App Engine לא יכווץ את נתוני התגובה.

  • ממשק הקצה של Google‏ (GFE) שומר במטמון תגובות ממטפלי קבצים סטטיים ומספריות ב-App Engine. בהתאם למגוון גורמים, כמו סוג נתוני התגובה שנשמרים במטמון קודם, אילו כותרות Vary ציינתם בתגובה ואילו כותרות נכללות בבקשה, יכול להיות שלקוח יבקש נתונים דחוסים אבל יקבל נתונים לא דחוסים, ולהפך. מידע נוסף מופיע במאמר בנושא שמירת תשובות במטמון.

שמירת תשובות במטמון

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

ב-Google Front End, מפתח המטמון הוא כתובת ה-URL המלאה של הבקשה.

שמירה של תוכן סטטי במטמון

כדי להבטיח שהלקוחות תמיד יקבלו תוכן סטטי מעודכן ברגע שהוא מתפרסם, מומלץ להציג תוכן סטטי מספריית גרסאות, כמו css/v1/styles.css. הקצה הקדמי של Google לא יאמת את המטמון (לא יבדוק אם יש תוכן מעודכן) עד שתוקף המטמון יפוג. גם אחרי שתוקף המטמון יפוג, המטמון לא יתעדכן עד שהתוכן בכתובת ה-URL של הבקשה ישתנה.

כותרות התגובה הבאות שאפשר להגדיר ב-app.yaml משפיעות על האופן שבו Google Front End שומר תוכן במטמון ומתי הוא עושה זאת:

  • ‫Cache-Control צריך להיות מוגדר ל-public כדי שממשק הקצה של Google ישמור תוכן במטמון. יכול להיות שהתוכן יישמר במטמון גם אם לא תציינו הוראה Cache-Control private או no-store. אם לא מגדירים את הכותרת הזו ב-app.yaml, ‏ App Engine מוסיף אותה באופן אוטומטי לכל התגובות שמטופלות על ידי קובץ סטטי או על ידי handler של ספרייה. מידע נוסף זמין במאמר כותרות שנוספו או הוחלפו.

  • ‫Vary: כדי לאפשר למטמון להחזיר תגובות שונות לכתובת URL על סמך כותרות שנשלחות בבקשה, צריך להגדיר ערך אחד או יותר מהערכים הבאים בכותרת התגובה Vary: ‏Accept, ‏Accept-Encoding, ‏Origin או X-Origin

    בגלל הפוטנציאל לעוצמה גבוהה, הנתונים לא יישמרו במטמון עבור ערכי Vary אחרים.

    לדוגמה:

    1. מציינים את כותרת התגובה הבאה:

      Vary: Accept-Encoding

    2. האפליקציה מקבלת בקשה שמכילה את הכותרת Accept-Encoding: gzip. ‫App Engine מחזיר תגובה דחוסה, ו-Google Front End שומר במטמון את הגרסה הדחוסה של נתוני התגובה. כל הבקשות הבאות לכתובת ה-URL הזו שמכילות את הכותרת Accept-Encoding: gzip יקבלו את הנתונים הדחוסים מהמטמון עד שהמטמון יבוטל (בגלל שינוי התוכן אחרי שתוקף המטמון יפוג).

    3. האפליקציה שלך מקבלת בקשה שלא מכילה את הכותרת Accept-Encoding. ‫App Engine מחזיר תגובה לא דחוסה, ו-Google Frontend שומר במטמון את הגרסה הלא דחוסה של נתוני התגובה. כל הבקשות הבאות לכתובת ה-URL הזו שלא מכילות את הכותרת Accept-Encoding מקבלות נתונים לא דחוסים מהמטמון עד שהמטמון הופך ללא תקף.

    אם לא מציינים כותרת תגובה של Vary, ה-Google Front End יוצר רשומה אחת במטמון עבור כתובת ה-URL וישתמש בה לכל הבקשות, ללא קשר לכותרות בבקשה. לדוגמה:

    1. לא מציינים את כותרת התגובה Vary: Accept-Encoding.
    2. בקשה מכילה את הכותרת Accept-Encoding: gzip, והגרסה של נתוני התגובה שדחוסה ב-gzip תישמר במטמון.
    3. הבקשה השנייה לא מכילה את הכותרת Accept-Encoding: gzip. עם זאת, מכיוון שהמטמון מכיל גרסה דחוסה של נתוני התגובה, התגובה תהיה דחוסה גם אם הלקוח ביקש נתונים לא דחוסים.

גם הכותרות בבקשה משפיעות על השמירה במטמון:

  • אם הבקשה מכילה כותרת Authorization, התוכן לא יישמר במטמון על ידי Google Front End.

תוקף המטמון

כברירת מחדל, כותרות ה-caching שמטפלי הקבצים הסטטיים והספריות של App Engine מוסיפים לתגובות, מנחות את הלקוחות ואת שרתי ה-proxy באינטרנט, כמו Google Front End, להפסיק את ה-cache אחרי 10 דקות.

אחרי שקובץ מועבר עם זמן תפוגה מסוים, בדרך כלל אין אפשרות לנקות אותו ממטמוני פרוקסי של אינטרנט, גם אם המשתמש מנקה את מטמון הדפדפן שלו. פריסה מחדש של גרסה חדשה של האפליקציה לא תאפס את המטמונים. לכן, אם אתם מתכננים לשנות קובץ סטטי, כדאי להגדיר לו זמן תפוגה קצר (פחות משעה). ברוב המקרים, זמן התפוגה שמוגדר כברירת מחדל (10 דקות) מתאים.

אפשר לשנות את תאריך התפוגה שמוגדר כברירת מחדל לכל רכיבי ה-handler של קבצים וספריות סטטיים על ידי ציון הרכיב default_expiration בקובץ app.yaml. כדי להגדיר תאריכי תפוגה ספציפיים לרכיבי handler בודדים, צריך לציין את הרכיב expiration בתוך רכיב ה-handler בקובץ app.yaml.

הערך שמציינים ברכיבי התפוגה time ישמש להגדרת כותרות תגובת ה-HTTP ‏Cache-Control ו-Expires.

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

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

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

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

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

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

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

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

קביעת סדרי עדיפויות בתור ההמתנה של App Engine

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

  • מערכת App Engine נותנת עדיפות לבקשות אחרות בתור על פני בקשות ממתינות בתור מתור המשימות. גם בקשות מ-App Engine Cloud Tasks חולקות את ההתנהגות הזו של תור בהמתנה, מסיבות של תאימות.

  • בתור הממתין, App Engine מתייחס לבקשות מ-HTTP target Cloud Tasks כאל תנועת HTTP רגילה. הבקשות של HTTP target לא מקבלות עדיפות נמוכה יותר.

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