מאמרי עזרה בנושא appengine-web.xml

מזהה אזור

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

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

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

אפליקציות Java ב-App Engine משתמשות בקובץ תצורה בשם appengine-web.xml כדי לציין מידע על האפליקציה ולזהות אילו קבצים בקובץ WAR של האפליקציה הם קבצים סטטיים (כמו תמונות) ואילו הם קובצי משאבים שמשמשים את האפליקציה.

תחביר

באפליקציית Java של App Engine צריך להיות קובץ בשם appengine-web.xml ב-WAR, בספרייה WEB-INF/. זהו קובץ XML שרכיב הבסיס שלו הוא <appengine-web-app>.

אפשר למצוא את הגדרת סוג המסמך ואת מפרטי הסכימה של appengine-web.xml בספרייה docs/ של ה-SDK.

רכיב	תיאור
`<application>`	לא נדרש אם פורסים את האפליקציה באמצעות כלים שמבוססים על Google Cloud SDK, כמו הפקודה `gcloud app deploy`, תוספים של IntelliJ, תוספים של Maven או Gradle. הכלים שמבוססים על Google Cloud SDK מתעלמים מהרכיב הזה ומקבלים את מזהה הפרויקט מהמאפיין gcloud config project. שימו לב: למרות שאפשר לשנות את מזהה הפרויקט באמצעות Google Cloud CLI, הפעולה הזו מגדירה מזהה פרויקט לכל המכונה, וזה עלול לגרום לבלבול אם אתם מפתחים כמה פרויקטים. הרכיב `<application>` מכיל את מזהה הפרויקט של האפליקציה. זה מזהה הפרויקט שאתם רושמים כשאתם יוצרים את הפרויקט ב- Google Cloud console.
`<app-engine-apis>`	זה שינוי אופציונלי. אם רוצים להשתמש בשירותים מדור קודם של App Engine שצורפו לזמני ריצה מהדור השני, צריך להגדיר את השדה הזה לערך `true`.
`<entrypoint>`	אופציונלי ורק לזמני ריצה מהדור השני. ההגדרה הזו מבטלת את נקודת הכניסה שמוגדרת כברירת מחדל, שהיא שורת הפקודה של התהליך שמפעילה את אפליקציית Java. כברירת מחדל, נקודת הכניסה שנוצרת לסוג מכונה F4 (הגדרות הזיכרון מחושבות מסוג המכונה) שווה להגדרה הבאה: <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <entrypoint> java -showversion -Xms32M -Xmx819M -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:+PrintCommandLineFlags --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.logging/java.util.logging=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED -Dclasspath.runtimebase=/base/java_runtime -Djava.class.path=/base/java_runtime/runtime-main.jar -Djava.library.path=/base/java_runtime: com/google/apphosting/runtime/JavaRuntimeMainWithDefaults --fixed_application_path=/workspace /base/java_runtime </entrypoint> </appengine-web-app> אפשר לשנות את ההגדרה כדי להוסיף דגלים נוספים של תהליך JVM או להגדיר תהליך משלכם להפעלה. שימו לב שהאפליקציה נפרסת בספרייה `/workspace`, ושקובצי ה-JAR של זמן הריצה נמצאים בספרייה `/base/java_runtime`. איך משתמשים במשתני סביבה כדי להתאים אישית את נקודת הכניסה לזמן הריצה של Java
`<async-session-persistence>`	זה שינוי אופציונלי. אפשר להקטין את זמן האחזור של הבקשה על ידי הגדרת האפליקציה כך שתכתוב נתונים של סשנים ב-HTTP ב-Datastore באופן אסינכרוני: <async-session-persistence enabled="true" /> אם מפעילים את התכונה 'המשכיות סשן אסינכרונית', App Engine ישלח משימה לתור המשימות כדי לכתוב את נתוני הסשן ב-Datastore לפני כתיבת הנתונים ב-memcache. כברירת מחדל, המשימה תוגש לתור 'default'. אם רוצים להשתמש בתור אחר, מוסיפים את המאפיין queue-name: <async-session-persistence enabled="true" queue-name="myqueue"/> נתוני ביקורים תמיד נכתבים באופן סינכרוני ל-memcache. אם בקשה מנסה לקרוא את נתוני הסשן כש-Memcache לא זמין (או כשנתוני הסשן נמחקו), היא תעבור ל-Datastore, שבו יכול להיות שעדיין לא יהיו נתוני הסשן העדכניים ביותר. המשמעות היא ששמירת סשן אסינכרונית יכולה לגרום לאפליקציה שלכם לראות נתוני סשן לא עדכניים. עם זאת, ברוב האפליקציות, היתרון של השהייה נמוכה עולה בהרבה על הסיכון.
`<auto-id-policy>`	זה שינוי אופציונלי. אם הגדרתם מזהים של ישויות באופן אוטומטי, תוכלו לשנות את השיטה שבה נעשה שימוש על ידי הגדרת מדיניות המזהים האוטומטיים. אלה האפשרויות התקינות: `default` ברירת מחדל. משתמש במזהים אוטומטיים מפוזרים שהם מספרים שלמים גדולים ומפוזרים היטב, אבל קטנים מספיק כדי להיות מיוצגים על ידי מספרים ממשיים של 64 ביט. `legacy` האפשרות הקודמת תוצא משימוש בגרסה עתידית ותוסר בסופו של דבר. מידע נוסף זמין בפוסט בבלוג שבו הודענו על השינוי הזה.
`<automatic-scaling>`	זה שינוי אופציונלי. להסבר מלא, ראה את הקטע בנושא התאמה אוטומטית לעומס.
`<basic-scaling>`	זה שינוי אופציונלי. הסבר מלא מופיע בקטע שינוי גודל בסיסי.
`<env-variables>`	זה שינוי אופציונלי. בקובץ `appengine-web.xml` אפשר להגדיר משתני סביבה שמוגדרים כשהאפליקציה פועלת. <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> כדי למנוע התנגשויות עם הסביבה המקומית, שרת הפיתוח לא מגדיר משתני סביבה על סמך הקובץ הזה, ונדרש שמשתנים אלה כבר יוגדרו בסביבה המקומית לערכים תואמים. export DEFAULT_ENCODING="UTF-8" dev_appserver war כשפורסים את האפליקציה ב-App Engine, הסביבה נוצרת עם המשתנים האלה שכבר מוגדרים. כדי לקבוע כמה זמן חיבור נשאר בלי פעילות בלי העברת נתונים לפני שהלקוח סוגר אותו, צריך להגדיר זמן קצוב לתפוגה למצב המתנה באמצעות התחביר הבא: <env-variables> <env-var name="APPENGINE_API_CALLS_IDLE_TIMEOUT_MS" value="TIMEOUT_IN_MS" /> </env-variables> מחליפים את `TIMEOUT_IN_MS` בערך הזמן הקצוב לתפוגה שנדרש במילישניות. כדי להתאים למועד האחרון הכולל של 60 שניות לבקשה או לאחזור כתובת URL, מגדירים את הערך ל-`60000`. לחלופין, כדאי להגדיר את הערך הזה קצת פחות מהזמן הקצוב לתפוגה בצד השרת (לרוב 60 שניות), למשל `59000`. ערך ברירת המחדל הנוכחי הוא `58000` אלפיות השנייה. הגדרת הזמן הקצוב לתפוגה של חוסר פעילות לא זהה לזמן הקצוב הכולל לתפוגה של בקשה לצורך שינוי גודל, או לזמן הקצוב לתפוגה של URL Fetch API שמוגדר באמצעות `appengine.api.urlfetch.defaultDeadline`.
`<inbound-services>`	זה שינוי אופציונלי. כדי שאפליקציה תוכל לקבל אימייל, צריך להגדיר אותה כך שהשירות יופעל. כדי להפעיל את השירות באפליקציית Java, צריך לכלול קטע `<inbound-services>` בקובץ `appengine-web.xml`. השירות הנכנס הבא זמין: `mail` מאפשרת לאפליקציה לקבל אימייל.
`<instance-class>`	זה שינוי אופציונלי. גודל מחלקת המופעים של המודול הזה. אלה המחלקות של המופעים שזמינות כשמציינים אפשרויות שונות של שינוי גודל: `automatic_scaling` כשמשתמשים בהתאמה אוטומטית לעומס, אפשר להשתמש בסוגי המכונות F1,‏ F2,‏ F4 ו-F4_1G. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `automatic_scaling`, מוקצה F1. `basic_scaling` כשמשתמשים בהגדלת קיבולת בסיסית, אפשר להשתמש בסוגי המופעים B1,‏ B2,‏ B4,‏ B4_1G ו-B8. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `basic_scaling`, מוקצה B2. `manual_scaling` כשמשתמשים בהתאמת קנה מידה ידנית, אפשר להשתמש בסוגי המכונות B1,‏ B2,‏ B4,‏ B4_1G ו-B8. ברירת מחדל: אם לא מציינים סוג מכונה יחד עם הרכיב `manual_scaling`, מוקצה B2. הערה: אם הערך של `instance-class` מוגדר כ-`F2` ומעלה, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של `max-concurrent-requests` כערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה.
`<manual-scaling>`	זה שינוי אופציונלי. הסבר מלא זמין בקטע שינוי גודל ידני.
`<precompilation-enabled>`	זה שינוי אופציונלי. ‫App Engine משתמש בתהליך של "קומפילציה מראש" עם קוד הבייטים של Java באפליקציה כדי לשפר את הביצועים של האפליקציה בסביבת זמן הריצה של Java. קוד שעבר קומפילציה מראש פועל בדיוק כמו הבייטקוד המקורי. אם מסיבה כלשהי אתם מעדיפים שהאפליקציה לא תשתמש בהידור מראש, אתם יכולים להשבית את התכונה על ידי הוספת הקוד הבא לקובץ `appengine-web.xml`: <precompilation-enabled>false</precompilation-enabled>
`<module>`	הערה: השם של המודולים הוא עכשיו Services, והשירותים עדיין מוצהרים בקובצי `appengine-web.xml` כמודולים, לדוגמה: `<module>service_name</module>`. חובה אם יוצרים שירות. אופציונלי לשירות ברירת המחדל. לכל שירות ולכל גרסה צריך להיות שם. שם יכול להכיל מספרים, אותיות ומקפים. השם לא יכול להיות ארוך מ-63 תווים, הוא לא יכול להתחיל או להסתיים במקף, והוא לא יכול להכיל את המחרוזת ‎ `-dot`‎. צריך לבחור שם ייחודי לכל שירות ולכל גרסה. אל תשתמשו באותם שמות בשירותים ובגרסאות שונים. אפשר לעיין גם בשירות.
`<public-root>`	זה שינוי אופציונלי. ‫`<public-root>` היא תיקייה באפליקציה שמכילה את הקבצים הסטטיים של האפליקציה. כשמתקבלת בקשה לקובץ סטטי, ה-`<public-root>` של האפליקציה שלכם מתווסף לתחילת נתיב הבקשה. השדה הזה מציין את הנתיב של קובץ אפליקציה שמכיל את התוכן המבוקש. ערך ברירת המחדל `<public-root>` הוא `/`. לדוגמה, המיפוי הבא ימפה את נתיב כתובת ה-URL‏ `/index.html` לנתיב האפליקציה `/static/index.html`: <public-root>/static</public-root>
`<resource-files>`	זה שינוי אופציונלי. אפשר לגשת לקבצים שמפורטים ברכיב `<resource-files>` באמצעות קוד האפליקציה דרך מערכת הקבצים. הקבצים האלה מאוחסנים בשרתי האפליקציות עם האפליקציה, בניגוד לאופן שבו קבצים סטטיים מאוחסנים ומוצגים. רכיב `<resource-files>` יכול להכיל את הרכיבים הבאים: `<include>` רכיב `<include>` מציין שהקבצים הם קובצי משאבים ושהם זמינים לקוד האפליקציה. הקבצים האלה זמינים לקוד רק לקריאה, ולא להצגת תנועה. הכללה והחרגה של קבצים. `<exclude>` קבצים וספריות שתואמים לתבניות `<exclude>` לא יועלו ולא יהיו זמינים לקוד האפליקציה. עם זאת, האפליקציה עדיין תוכל לגשת לקבצים ולספריות האלה כשהיא פועלת בשרת הפיתוח המקומי. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. לדוגמה: <resource-files> <include path="/.xml" /> <exclude path="/feeds/.xml" /> </resource-files> בדוגמה הזו אנחנו מראים איך להגדיר את כל קובצי `.xml` כקבצי משאבים, למעט הקבצים בספרייה `feeds/` ובכל ספריות המשנה שלה. קובצי משאבים של App Engine נקראים באמצעות `java.io.File` או `javax.servlet.ServletContext.getResource/getResourceAsStream`. אי אפשר לגשת אליהם באמצעות `Class.getResourceAsStream()`.
`<runtime>`	כדי להשתמש בגרסת Java העדכנית ביותר שנתמכת, צריך לציין את הערך הזה עם הערך `java25`. לדוגמה: <runtime>java25</runtime>
`<service>`	השירותים נקראו בעבר מודולים. הגדרת שירות באופן הבא: `<service>service_name</service >` נתמכת רק בפקודות של gcloud app.
`<service-account>`	זה שינוי אופציונלי. רכיב `<service-account>` מאפשר לציין חשבון שירות שמנוהל על ידי משתמש כזהות של הגרסה. חשבון השירות שצוין ישמש לגישה לשירותים אחרים של Google Cloud Google ולביצוע משימות. לדוגמה: <service-account>[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com</service-account>
`<sessions-enabled>`	זה שינוי אופציונלי. ‫App Engine כולל הטמעה של סשנים באמצעות ממשק הסשן של servlet. ההטמעה מאחסנת את נתוני הסשן ב-Datastore לצורך שמירה, ומשתמשת גם ב-memcache כדי להגביר את המהירות. בדומה לרוב מאגרי ה-servlet האחרים, מאפייני הסשן שמוגדרים באמצעות ‎ `session.setAttribute()`‎ במהלך הבקשה נשמרים בסוף הבקשה. התכונה הזו מושבתת כברירת מחדל. כדי להפעיל את האפשרות, מוסיפים את השורה הבאה אל `appengine-web.xml`: לדוגמה: <sessions-enabled>true</sessions-enabled> ההטמעה יוצרת ישויות Datastore מסוג `_ah_SESSION`, ורשומות במטמון באמצעות מפתחות עם הקידומת `_ahs`. אפשר למחוק את הישויות האלה באמצעות תבנית Dataflow. הערה: מכיוון ש-App Engine מאחסן נתוני סשנים ב-Datastore וב-memcache, כל הערכים שמאוחסנים בסשן צריכים להטמיע את הממשק `java.io.Serializable`. במאמר בנושא רכיב `async-session-persistence` מוסבר איך לקצר את זמן האחזור של אחסון נתוני הסשן.
`<ssl-enabled>`	זה שינוי אופציונלי. כברירת מחדל, כל משתמש יכול לגשת לכל כתובת URL באמצעות HTTP או HTTPS. אפשר להגדיר אפליקציה כך שתידרש HTTPS לכתובות URL מסוימות בקובץ תיאור הפריסה. לעיון במאמר בנושא תיאור פריסה: כתובות URL מאובטחות אם רוצים לאסור את השימוש ב-HTTPS באפליקציה, צריך להוסיף את השורה הבאה לקובץ `appengine-web.xml`: <ssl-enabled>false</ssl-enabled> בסביבת זמן הריצה של Java, אין אפשרות להשבית את השימוש ב-HTTPS עבור נתיבי כתובות URL מסוימים ולא עבור אחרים.
`<static-error-handlers>`	זה שינוי אופציונלי. כשמתרחשות שגיאות מסוימות, App Engine מציג דף שגיאה גנרי. אתם יכולים להגדיר את האפליקציה כך שתציג קובץ סטטי מותאם אישית במקום דפי השגיאה הכלליים האלה, בתנאי שנתוני השגיאה המותאמים אישית קטנים מ-10 קילובייט. אפשר להגדיר קבצים סטטיים שונים שיוצגו לכל קוד שגיאה נתמך. כדי לעשות זאת, צריך לציין את הקבצים בקובץ `appengine-web.xml` של האפליקציה. כדי להציג דפי שגיאה מותאמים אישית, מוסיפים קטע `<static-error-handlers>` ל-`appengine-web.xml`, כמו בדוגמה הזו: <static-error-handlers> <handler file="default_error.html" /> <handler file="over_quota.html" error-code="over_quota" /> </static-error-handlers> אזהרה: חשוב לוודא שהנתיב לקובץ תגובת השגיאה לא חופף לנתיבים של קבצים סטטיים. כל ערך `file` מציין קובץ סטטי שצריך להציג במקום תגובת השגיאה הגנרית. התג `error-code` מציין איזה קוד שגיאה צריך לגרום להצגת הקובץ המשויך. אלה קודי השגיאה הנתמכים: `over_quota` מציין שהאפליקציה חרגה ממכסת משאבים. `timeout` המודעה מוצגת אם מגיע מועד סיום לפני שמתקבלת תשובה מהאפליקציה. השדה `error-code` הוא אופציונלי. אם לא מציינים אותו, הקובץ שצוין הוא תגובת השגיאה שמוגדרת כברירת מחדל לאפליקציה. אפשר גם לציין `mime-type` שבו ישתמשו כשמוצגת השגיאה המותאמת אישית. רשימה מלאה של סוגי MIME
`<static-files>`	זה שינוי אופציונלי. רכיב `<static-files>` מציין תבניות שתואמות לנתיבי קבצים שצריך לכלול או להחריג מרשימת הקבצים הסטטיים, ומבטל או משנה את התנהגות ברירת המחדל. קובץ סטטי מוגש ממטמון ומשרתים ייעודיים שמופרדים משרתי האפליקציות, והוא שימושי להגשת תוכן סטטי כמו תמונות, גיליונות סגנון של CSS או קובצי JavaScript. רכיב `<static-files>` יכול להכיל את הרכיבים הבאים: `<include>` רכיב `<include>` מבטל את התנהגות ברירת המחדל של הכללת כל הקבצים שאינם JSP. רכיב `<include>` יכול לציין כותרות HTTP לשימוש בתגובה לבקשה למשאבים שצוינו. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. אפשר לבטל את ברירת המחדל של תפוגת המטמון הסטטי על ידי ציון המאפיין `expiration` ברכיב include. הערך הוא מחרוזת של מספרים ויחידות, שמופרדים ברווחים. היחידות יכולות להיות `d` לימים, `h` לשעות, `m` לדקות ו-`s` לשניות. לדוגמה, `"4d 5h"` מגדיר את תפוגת המטמון ל-4 ימים ו-5 שעות אחרי שהקובץ נדרש בפעם הראשונה. מידע נוסף זמין במאמר בנושא תפוגה של מטמון. `<exclude>` קבצים וספריות שתואמים לתבניות `<exclude>` לא יועלו כשפורסים את האפליקציה ב-App Engine. עם זאת, האפליקציה עדיין תוכל לגשת לקבצים ולספריות האלה כשהיא פועלת בשרת הפיתוח המקומי. מידע נוסף זמין במאמר בנושא הכללה והחרגה של קבצים. דוגמה <static-files> <include path="/my_static-files" > <http-header name="Access-Control-Allow-Origin" value="http://example.org" /> </include> </static-files>
`<system-properties>`	זה שינוי אופציונלי. בקובץ `appengine-web.xml` אפשר להגדיר מאפייני מערכת ומשתני סביבה שמוגדרים כשהאפליקציה פועלת. <system-properties> <property name="myapp.maximum-message-length" value="140" /> <property name="myapp.notify-every-n-signups" value="1000" /> <property name="myapp.notify-url" value="http://www.example.com/signupnotify" /> </system-properties> <env-variables> <env-var name="DEFAULT_ENCODING" value="UTF-8" /> </env-variables> זה שינוי אופציונלי. אתם יכולים להגדיר מחבר HTTP כדי לשפר את ניצול המעבד והזיכרון. אם האפליקציה שלכם מבצעת אינטראקציה עם פעולות של Datastore או של Task Queues, כדאי להגדיר מעקב כדי לעקוב אחרי ההשפעות על הביצועים וההתנהגות אחרי הפעלת התכונה הזו. <system-properties> <property name="appengine.use.httpconnector" value="true"/> </system-properties> זה שינוי אופציונלי. אפשר להגדיר את זמן הריצה הבסיסי של Java 17 כך שיפעל ב-EE 8, את Java 21 ב-EE 10 או את Java 25 ב-EE 11 באמצעות מאפיין המערכת הבא. מידע נוסף על תמיכה ב-EE זמין במאמר בנושא שדרוג Java בגרסה תואמת של Enterprise Edition‏ (EE). <system-properties> <property name="appengine.use.EE11" value="true"/><!--only for Java 25--> </system-properties> החל מ-Java 21, אפשר להגדיר את שרת האינטרנט של Java לשימוש בשרשורים וירטואליים. לדוגמה: <system-properties> <property name="appengine.use.virtualthreads" value="true"/> </system-properties> מידע נוסף על תמיכה בשרשורים זמין במאמר Jetty 12 – Virtual Threads Support.
`<url-stream-handler>`	זה שינוי אופציונלי. הערכים האפשריים הם `native` או `urlfetch`. ערך ברירת המחדל הוא `native`, כלומר מחלקות רשת רגילות של Java משתמשות בהעברת HTTP(S) רגילה של Java. כדי להשתמש בהגדרה הזו, צריך להפעיל את החיוב באפליקציה. אחרת, יתקבלו חריגים, שמפורטים במאמר בנושא בקשות לבעיות. אם מגדירים את `url-stream-handler` ל-`urlfetch`,‏ `URL.openConnection` ושיטות קשורות ישתמשו באחזור כתובות URL להעברת נתונים של `http` ו-`https`. <url-stream-handler>urlfetch</url-stream-handler>
`<version>`	הרכיב `<version>` מכיל את מזהה הגרסה של הגרסה האחרונה של קוד האפליקציה. מזהה הגרסה יכול להכיל אותיות קטנות, ספרות ומקפים. השם לא יכול להתחיל בקידומת ah- והשמות default ו-latest שמורים ואי אפשר להשתמש בהם. שמות הגרסאות צריכים להתחיל באות, כדי להבדיל אותם ממופעים מספריים שתמיד מצוינים על ידי מספר. כך נמנעת דו-משמעות בכתובות URL כמו `123.my-module.uc.r.appspot.com`, שאפשר לפרש אותן בשתי דרכים: אם קיימת גרסה 123, היעד יהיה גרסה 123 של המודול הנתון. אם הגרסה הזו לא קיימת, היעד יהיה מופע מספר 123 של גרסת ברירת המחדל של המודול.
`<warmup-requests-enabled>`	זה שינוי אופציונלי. ברירת מחדל: true. בקשות חימום מופעלות כברירת מחדל באפליקציות Java. אם מפעילים <href=" appengine="" configuring-warmup-requests"="" docs="" standard="">בקשות הפעלה מראש, התשתית של App Engine מנפיקה בקשות GET ל-`/_ah/warmup`, ומפעילה סרוולטים של `<load-on-startup>`,‏ `ServletContextListeners` וסרוולטים מותאמים אישית של הפעלה מראש, שמאפשרים להפעיל את הקוד של האפליקציה לפי הצורך. יכול להיות שתצטרכו להטמיע את ה-handler שלכם עבור `/_ah/warmup`, בהתאם לשיטה שתבחרו. </href="> כדי להשבית את בקשות החימום, מציינים `false` ברכיב הזה: <warmup-requests-enabled>false</warmup-requests-enabled>
`<vpc-access-connector>`	זה שינוי אופציונלי. הכלי מגדיר את האפליקציה כך שתשתמש במחבר Serverless VPC Access, וכך האפליקציה תוכל לשלוח בקשות למשאבים פנימיים ברשת ה-VPC. מציינים את השם המלא של המחבר ברכיב `<name>`: <vpc-access-connector> <name>projects/[PROJECT_ID]/locations/[REGION]/connectors/[CONNECTOR_NAME]</name> </vpc-access-connector> מידע נוסף זמין במאמר התחברות למשאבים פנימיים ברשת VPC.

שינוי הגודל של אלמנטים

בטבלה הבאה מפורטות האפשרויות להגדרת האופן שבו האפליקציה שלכם צריכה להתרחב.

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

רכיב תיאור

רכיב	תיאור
`<automatic-scaling>`	זה שינוי אופציונלי. כברירת מחדל, המערכת מניחה שמתבצע התאמה אוטומטית לעומס (automatic scaling) עם סוג ברירת מחדל של מופע `F1`, אלא אם צוין אחרת. רכיב `automatic_scaling` מגדיר רמות מינימליות ומקסימליות של מספר המופעים, זמן האחזור והחיבורים בו-זמנית של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<target-cpu-utilization>` אופציונלי. מציינים ערך בין 0.5 ל-0.95. הפרמטר הזה מציין את סף השימוש במעבד שמעליו יופעלו מופעים חדשים כדי לטפל בתנועה. כך אפשר לאזן בין ביצועים לעלות. ערכים נמוכים יותר משפרים את הביצועים ומגדילים את העלות, וערכים גבוהים יותר מפחיתים את הביצועים אבל גם את העלות. לדוגמה, ערך של 0.7 אומר שמופעים חדשים יופעלו אחרי ששימוש המעבד יגיע ל-70%. `<target-throughput-utilization>` אופציונלי. מציינים ערך בין 0.5 ל-0.95. משמש עם `max-concurrent-requests` כדי לציין מתי מופעלת אינטס חדשה בגלל בקשות מקבילות. כאשר מספר הבקשות בו-זמנית מגיע לערך ששווה ל-`max-concurrent-requests` כפול `target-throughput-utilization`, מתזמן המשימות מפעיל מופע חדש. `<max-instances>` אופציונלי. מספר המופעים המקסימלי ש-App Engine יכול ליצור עבור גרסת האפליקציה הזו. האפשרות הזו שימושית להגבלת העלויות של מודול. מציינים ערך בין 0 ל-2147483647. `<min-instances>` אופציונלי. המספר המינימלי של מופעים ש-App Engine יוצר עבור גרסת המודול הזו. המופעים האלה מציגים תנועה כשהבקשות מגיעות, וממשיכים להציג תנועה גם כשמופעים נוספים מופעלים לפי הצורך כדי לטפל בתנועה. מציינים ערך בין 0 ל-1,000. אפשר להגדיר את הפרמטר לערך 0 כדי לאפשר שינוי גודל ל-0 מופעים, וכך להפחית את העלויות כשלא מתבצעות בקשות. הערה: אתם מחויבים על מספר המופעים שצוין, בין אם הם מקבלים תנועה ובין אם לא. `<max-concurrent-requests>` זה שינוי אופציונלי. מספר הבקשות בו-זמניות שמופע של התאמה אוטומטית לעומס יכול לקבל לפני שהמתזמן יוצר מופע חדש (ברירת מחדל: 10, מקסימום: 80). אם ההגדרה הזו גבוהה מדי, יכול להיות שזמן האחזור של ה-API יתארך. שימו לב: יכול להיות שהמתזמן ייצור מופע חדש לפני שיושג המספר המקסימלי בפועל של בקשות. הערה: אם הערך של `instance-class` מוגדר כ-`F2` ומעלה, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של `max-concurrent-requests` כערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה. `<max-idle-instances>` המספר המקסימלי של מופעים בלי פעילות ש-App Engine צריך לשמור לגרסה הזו. ערך ברירת המחדל הוא 'אוטומטי'. חשוב לזכור: ערך מקסימלי גבוה יקטין את מספר המופעים בלי פעילות בצורה הדרגתית יותר כשרמות העומס יחזרו למצב נורמלי אחרי נקודת שיא. השיטה הזו עוזרת לאפליקציה לשמור על ביצועים יציבים גם כשיש תנודות בעומס הבקשות, אבל היא גם מגדילה את מספר המופעים הלא פעילים (ואת עלויות ההפעלה שנובעות מכך) בתקופות של עומס כבד. מגבלה נמוכה על המקסימום שומרת על עלויות ההפעלה נמוכות יותר, אבל עלולה לפגוע בביצועים במקרה של רמות עומס משתנות. הערה: כשחוזרים לרמות רגילות אחרי עלייה פתאומית בעומס, יכול להיות שמספר המופעים בלי פעילות יעלה באופן זמני על המספר המקסימלי שצוין. עם זאת, לא נחייב אתכם על יותר מופעים מהמספר המקסימלי שציינתם. `<max-pending-latency>` כמות הזמן המקסימלית שאפליקציית App Engine צריכה לאפשר לבקשה להמתין בתור להמתנה לפני הפעלת מופעים נוספים לטיפול בבקשות, כדי לצמצם את זמן האחזור של בקשות בהמתנה. ערך נמוך של המקסימום אומר ש-App Engine יתחיל מופעים חדשים מוקדם יותר עבור בקשות בהמתנה, מה שישפר את הביצועים אבל יעלה את עלויות ההפעלה. ערך מקסימלי גבוה אומר שהמשתמשים עלולים לחכות יותר זמן עד שהבקשות שלהם יטופלו, אם יש בקשות בהמתנה ואין מופעים לא פעילים שיכולים לטפל בהן, אבל העלות של הפעלת האפליקציה תהיה נמוכה יותר. `<min-idle-instances>` מספר המקרים שצריכים להמשיך לפעול ולהיות מוכנים להצגת תנועה.ההגדרה הזו חלה רק על הגרסה שמקבלת את רוב התנועה. חשוב לזכור: סף מינימלי נמוך עוזר לצמצם את עלויות ההפעלה בתקופות של חוסר פעילות, אבל המשמעות היא שפחות מופעים יהיו זמינים באופן מיידי כדי להגיב לעלייה פתאומית בעומס. ערך מינימלי גבוה מאפשר לכם להכין את האפליקציה לעליות חדות ומהירות בעומס הבקשות. ‫App Engine שומר על מספר המינימום של מופעים שפועלים כדי לטפל בבקשות נכנסות. החיוב הוא על מופעים, בין אם הם מטפלים בבקשות ובין אם לא. כדי שהתכונה הזו תפעל כמו שצריך, צריך לוודא ש בקשות חימום מופעלות ושהאפליקציה מטפלת בבקשות חימום. אם מגדירים מספר מינימלי של מופעים בלי פעילות, לזמן המתנה תהיה השפעה פחותה על ביצועי האפליקציה. מכיוון ש-App Engine שומר מופעים במצב המתנה, סביר להניח שבקשות לא ייכנסו לתור ההמתנה, אלא אם יהיו עליות חדות בעומס. כדי לקבוע את מספר המופעים האידיאלי שצריך לשמור, תצטרכו לבדוק את האפליקציה ואת נפח התנועה הצפוי. `<min-pending-latency>` משך הזמן המינימלי בשניות שבו מערכת App Engine צריכה לאפשר לבקשה להמתין בתור להמתנה לפני שהיא מתחילה מופע חדש כדי לטפל בה. מציינים ערך בין 0.01 ל-15. מינימום נמוך אומר שהבקשות צריכות לבלות פחות זמן בתור להמתנה כשהמופעים הקיימים פעילים. הפעולה הזו משפרת את הביצועים, אבל מגדילה את העלות של הפעלת האפליקציה. אם המינימום גבוה, הבקשות יישארו בהמתנה למשך זמן ארוך יותר אם כל המקרים הקיימים פעילים. כך אפשר להקטין את עלויות ההפעלה, אבל המשתמשים צריכים לחכות יותר זמן עד שהבקשות שלהם יטופלו. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>F2</instance-class> <automatic-scaling> <target-cpu-utilization>0.65</target-cpu-utilization> <min-instances>5</min-instances> <max-instances>100</max-instances> <max-concurrent-requests>50</max-concurrent-requests> </automatic-scaling> </appengine-web-app>
`<basic-scaling>`	זה שינוי אופציונלי. רכיב `<basic-scaling>` מגדיר את מספר המופעים של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<idle-timeout>` אופציונלי. המופע יושבת אחרי פרק הזמן הזה, אחרי קבלת הבקשה האחרונה שלו. ברירת המחדל היא 5 דקות. `<max-instances>` חובה. מספר המכונות המקסימלי ש-App Engine יכול ליצור עבור גרסת המודול הזו. האפשרות הזו שימושית להגבלת העלויות של מודול. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <basic-scaling> <max-instances>11</max-instances> <idle-timeout>10m</idle-timeout> </basic-scaling> </appengine-web-app>
`<manual-scaling>`	זה שינוי אופציונלי. האלמנט `<manual-scaling>` מאפשר שינוי גודל ידני של מודול ומגדיר את מספר המופעים של מודול. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<instances>` מספר המופעים להקצאה למודול בהתחלה. דוגמה <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>simple-app</application> <module>default</module> <version>uno</version> <instance-class>B8</instance-class> <manual-scaling> <instances>5</instances> </manual-scaling> </appengine-web-app>

<automatic-scaling>

זה שינוי אופציונלי. כברירת מחדל, המערכת מניחה שמתבצע התאמה אוטומטית לעומס (automatic scaling) עם סוג ברירת מחדל של מופע F1, אלא אם צוין אחרת.

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

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<target-cpu-utilization>

אופציונלי. מציינים ערך בין 0.5 ל-0.95.

הפרמטר הזה מציין את סף השימוש במעבד שמעליו יופעלו מופעים חדשים כדי לטפל בתנועה. כך אפשר לאזן בין ביצועים לעלות. ערכים נמוכים יותר משפרים את הביצועים ומגדילים את העלות, וערכים גבוהים יותר מפחיתים את הביצועים אבל גם את העלות. לדוגמה, ערך של 0.7 אומר שמופעים חדשים יופעלו אחרי ששימוש המעבד יגיע ל-70%.

<target-throughput-utilization>

אופציונלי. מציינים ערך בין 0.5 ל-0.95.

משמש עם max-concurrent-requests כדי לציין מתי מופעלת אינטס חדשה בגלל בקשות מקבילות. כאשר מספר הבקשות בו-זמנית מגיע לערך ששווה ל-max-concurrent-requests כפול target-throughput-utilization, מתזמן המשימות מפעיל מופע חדש.

<max-instances>

אופציונלי. מספר המופעים המקסימלי ש-App Engine יכול ליצור עבור גרסת האפליקציה הזו. האפשרות הזו שימושית להגבלת העלויות של מודול. מציינים ערך בין 0 ל-2147483647.

<min-instances>

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

מציינים ערך בין 0 ל-1,000. אפשר להגדיר את הפרמטר לערך 0 כדי לאפשר שינוי גודל ל-0 מופעים, וכך להפחית את העלויות כשלא מתבצעות בקשות. הערה: אתם מחויבים על מספר המופעים שצוין, בין אם הם מקבלים תנועה ובין אם לא.

<max-concurrent-requests>

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

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

הערה: אם הערך של instance-class מוגדר כ-F2 ומעלה, אפשר לבצע אופטימיזציה של המופעים על ידי הגדרת הערך של max-concurrent-requests כערך גבוה מ-10, שהוא ערך ברירת המחדל. כדי למצוא את הערך האופטימלי, מגדילים אותו בהדרגה ועוקבים אחרי הביצועים של האפליקציה.

<max-idle-instances>

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

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

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

<max-pending-latency>

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

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

<min-idle-instances>

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

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

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

<min-pending-latency>

משך הזמן המינימלי בשניות שבו מערכת App Engine צריכה לאפשר לבקשה להמתין בתור להמתנה לפני שהיא מתחילה מופע חדש כדי לטפל בה. מציינים ערך בין 0.01 ל-15.

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

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>F2</instance-class>
  <automatic-scaling>
    <target-cpu-utilization>0.65</target-cpu-utilization>
    <min-instances>5</min-instances>
    <max-instances>100</max-instances>
    <max-concurrent-requests>50</max-concurrent-requests>
  </automatic-scaling>
</appengine-web-app>

<basic-scaling>

זה שינוי אופציונלי. רכיב <basic-scaling> מגדיר את מספר המופעים של מודול.

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<idle-timeout>: אופציונלי. המופע יושבת אחרי פרק הזמן הזה, אחרי קבלת הבקשה האחרונה שלו. ברירת המחדל היא 5 דקות.
<max-instances>: חובה. מספר המכונות המקסימלי ש-App Engine יכול ליצור עבור גרסת המודול הזו. האפשרות הזו שימושית להגבלת העלויות של מודול.

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <basic-scaling>
    <max-instances>11</max-instances>
    <idle-timeout>10m</idle-timeout>
  </basic-scaling>
</appengine-web-app>

<manual-scaling>

זה שינוי אופציונלי. האלמנט <manual-scaling> מאפשר שינוי גודל ידני של מודול ומגדיר את מספר המופעים של מודול.

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<instances>: מספר המופעים להקצאה למודול בהתחלה.

דוגמה

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>simple-app</application>
  <module>default</module>
  <version>uno</version>
  <instance-class>B8</instance-class>
  <manual-scaling>
    <instances>5</instances>
  </manual-scaling>
</appengine-web-app>

רכיבי Staging

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

רכיב תיאור

רכיב	תיאור
`<staging>`	זה שינוי אופציונלי. ברוב האפליקציות אין צורך לשנות את התנהגות ברירת המחדל. רכיב ההעברה לבדיקה מאפשר לציין הגדרת העברה לבדיקה ספציפית אם נדרשת כזו לפריסה. האלמנט הזה יכול להכיל את האלמנטים הבאים: `<enable-jar-splitting>` זה שינוי אופציונלי. מפצלים קובצי JAR גדולים (גדולים מ-10 מגה-בייט) לחלקים קטנים יותר. (ברירת מחדל: true). `<jar-splitting-excludes>` מציינת רשימה מופרדת בפסיקים של סיומות קבצים. אם האפשרות `enable-jar-splitting` מופעלת, כל הקבצים שתואמים לסיומות לא ייכללו בכל קובצי ה-JAR. `<disable_jar_jsps>` לא ליצור קובץ JAR של כיתות שנוצרו מ-JSP. (ברירת מחדל: false). `<enable-jar-classes>` יוצרים קובץ JAR של התוכן של WEB-INF/classes. (ברירת מחדל: true). `<delete-jsps>` מוחקים את קובצי המקור של JSP אחרי ההידור. (ברירת מחדל: true). `<compile-encoding>` קידוד הקלט של קובצי המקור לקומפילציה. (ברירת מחדל: utf-8). לדוגמה: <staging> <delete-jsps>false</delete-jsps> </staging>

<staging>

זה שינוי אופציונלי. ברוב האפליקציות אין צורך לשנות את התנהגות ברירת המחדל.

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

האלמנט הזה יכול להכיל את האלמנטים הבאים:

<enable-jar-splitting>: זה שינוי אופציונלי. מפצלים קובצי JAR גדולים (גדולים מ-10 מגה-בייט) לחלקים קטנים יותר. (ברירת מחדל: true).
<jar-splitting-excludes>: מציינת רשימה מופרדת בפסיקים של סיומות קבצים. אם האפשרות enable-jar-splitting מופעלת, כל הקבצים שתואמים לסיומות לא ייכללו בכל קובצי ה-JAR.
<disable_jar_jsps>: לא ליצור קובץ JAR של כיתות שנוצרו מ-JSP. (ברירת מחדל: false).
<enable-jar-classes>: יוצרים קובץ JAR של התוכן של WEB-INF/classes. (ברירת מחדל: true).
<delete-jsps>: מוחקים את קובצי המקור של JSP אחרי ההידור. (ברירת מחדל: true).
<compile-encoding>: קידוד הקלט של קובצי המקור לקומפילציה. (ברירת מחדל: utf-8).

לדוגמה:

        <staging>
          <delete-jsps>false</delete-jsps>
        </staging>

ברירות מחדל של אפשרויות ההעברה לסביבת הפיתוח

הגדרות ברירת המחדל לאפשרויות ההעברה לבמה משתנות בהתאם לשימוש בכלי שמבוסס על Google Cloud SDK, כמו ה-CLI של gcloud, או בתוספים Maven,‏ Gradle או IntelliJ שמבוססים על Google Cloud SDK.

רכיב Staging	הגדרות ברירת מחדל שמבוססות על SDK של App Engine –	ברירות מחדל שמבוססות על Google Cloud SDK
`enable-jar-splitting`	`false`	`true`
`jar-splitting-excludes`	לא רלוונטי	לא רלוונטי
`disable-jar-jsps`	`false`	`false`
`enable-jar-classes`	`false`	‫`true`. זה יכול להשפיע על סדר טעינת המחלקות, לכן אם האפליקציה שלכם תלויה בסדר מסוים באמצעות ברירת המחדל הקודמת `false`, אתם יכולים להגדיר את זה ל-`false`.
`delete-jsps`	`false`	`true`
`compile-encoding`	`utf-8`	`utf-8`

תחביר של הכללה והחרגה

תבניות נתיבים מצוינות באמצעות אפס רכיבי <include> ו-<exclude> או יותר. בתבנית, '*' מייצג אפס או יותר מכל תו בשם של קובץ או ספרייה, ו-** מייצג אפס או יותר ספריות בנתיב. קבצים וספריות שתואמים לתבניות <exclude> לא יועלו כשפורסים את האפליקציה ב-App Engine. עם זאת, הקבצים והספריות האלה עדיין יהיו נגישים לאפליקציה שלכם כשהיא תפעל בשרת הפיתוח המקומי.

רכיב <include> מבטל את התנהגות ברירת המחדל של הכללת כל הקבצים. רכיב <exclude> חל אחרי כל התבניות של <include> (וגם אחרי ברירת המחדל אם לא סופק <include> מפורש).

בדוגמה הבאה מוסבר איך להגדיר את כל הקבצים מסוג png כקבצים סטטיים (חוץ מאלה שבספרייה data/ ובכל תיקיות המשנה שלה):

<static-files>
  <include path="/**.png" />
  <exclude path="/data/**.png" />
</static-files>

אפשר גם להגדיר כותרות HTTP לשימוש בתגובה לבקשות למשאבים סטטיים.

<static-files>
  <include path="/my_static-files" >
    <http-header name="Access-Control-Allow-Origin"
                 value="http://example.org" />
  </include>
</static-files>

סוגי MIME לקבצים סטטיים

כברירת מחדל, קבצים סטטיים מוגשים באמצעות סוג MIME שנבחר על סמך הסיומת של שם הקובץ. אתם יכולים לשייך סוגי MIME מותאמים אישית לתוספי שמות קבצים עבור קבצים סטטיים באמצעות רכיבי mime-mapping ב-web.xml.

פסק זמן ב-URLFetch

אפשר להגדיר מועד אחרון לכל בקשת URLFetch. כברירת מחדל, הדדליין לאחזור הוא 5 שניות. אפשר לשנות את ברירת המחדל הזו על ידי הכללת ההגדרה הבאה בקובץ התצורה appengine-web.xml. מציינים את הזמן הקצוב לתפוגה בשניות:

<system-properties>
    <property name="appengine.api.urlfetch.defaultDeadline" value="10"/>
</system-properties>

מאמרי עזרה בנושא appengine-web.xml קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מזהה אזור

תחביר

שינוי הגודל של אלמנטים

רכיבי Staging

ברירות מחדל של אפשרויות ההעברה לסביבת הפיתוח

תחביר של הכללה והחרגה

סוגי MIME לקבצים סטטיים

פסק זמן ב-URLFetch

מאמרי עזרה בנושא appengine-web.xml