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

Go Java Node.js PHP Python Ruby

מזהה אזור

‫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 מסוףGoogle Cloud מופיעים גם הערכים Secure Requests, ‏ Secure Incoming Bandwidth ו-Secure Outgoing Bandwidth בנפרד, למטרות מידע. רק בקשות HTTPS נספרות בערכים האלה. מידע נוסף זמין בדף מכסות.

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

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

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

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

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

• הגודל של תשובות דינמיות מוגבל ל-32MB. אם מעבד הסקריפט יוצר תגובה גדולה יותר מהמגבלה הזו, השרת מחזיר תגובה ריקה עם קוד הסטטוס 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.

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

מידע נוסף זמין במאמר בנושא Request responses.

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

‫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, מפתח המטמון הוא כתובת ה-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.

תוקף המטמון

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

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

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

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

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

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

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

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

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

זהירות: לקוחות שקיבלו את הכותרת בעבר יסרבו להתחבר אם https לא יפעל או יושבת מסיבה כלשהי. מידע נוסף זמין בדף התרמית הזה בנושא HTTP Strict Transport Security.

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

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

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

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

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

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

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

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

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