אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
בקשות ה-API שמוגשות על ידי אפליקציות הלקוח עוברות דרך רכיבים שונים ב-Apigee Edge לפני שהן מגיעות לשירותי הקצה העורפי. רוב אפליקציות הלקוח מצפות לקבל את התשובות לבקשות האלה בזמן.
כדי לקבל תשובות בזמן, ערכי הזמן הקצוב לתפוגה של הקלט/פלט מוגדרים בכל אחד מהרכיבים שבהם עוברות בקשות ה-API. אם אחד מהרכיבים בתהליך נמשך יותר זמן מהרכיב הקודם, הרכיב הקודם יפוג הזמן שלו ויחזיר שגיאות 504 Gateway Timeout.
כשמגדירים את הזמן הקצוב לתפוגה, צריך להגדיר את הערכים בכל אחד מהרכיבים בזהירות רבה, אחרת זה עלול להוביל ל שגיאות 504 Gateway Timeout.
במסמך הזה מפורטות שיטות מומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט ברכיבים שונים שבהם עוברות בקשות ה-API ב-Apigee Edge.
שיטות מומלצות להגדרת זמן קצוב לתפוגה של קלט/פלט
כדאי להשתמש בשיטות המומלצות הבאות כשמגדירים את זמן הקצאת הזמן לתפוגה של קלט/פלט:
- הרכיב הראשון: תמיד צריך להשתמש במכסת הזמן הקצובה הארוכה ביותר לתפוגה ברכיב הראשון בתהליך הבקשה ל-API, שהוא אפליקציית הלקוח ב-Apigee Edge.
- הרכיב האחרון: תמיד צריך להשתמש במכסת הזמן הקצרה ביותר לתפוגה ברכיב האחרון בתהליך הבקשה של ה-API, שהוא שירות הקצה העורפי ב-Apigee Edge.
- בין רכיבים: חשוב לוודא שיש הבדל של לפחות 2-3 שניות בערך הזמן הקצוב לתפוגה (timeout) שמוגדר בכל רכיב בין הרכיב הראשון לרכיב האחרון בתהליך.
- נתב: תמיד מומלץ להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של הקלט/פלט לארח וירטואלי ספציפי, במקום להגדיר אותו בנתב. כך אפשר לוודא שערך הזמן הקצוב החדש לתפוגה ישפיע רק על שרתי ה-API Proxy שמשתמשים במארח הווירטואלי הספציפי, ולא על כל שרתי ה-API Proxy שמקבלים שירות מהנתב.
מגדירים (משנים) את זמן הקצאת הזמן לתפוגה של הקלט/פלט בנתב רק אם אתם בטוחים לחלוטין שערך זמן הקצאת הזמן החדש לתפוגה של הקלט/פלט נדרש או רלוונטי לכל שרתי ה-API Proxy שפועלים בנתב.
- Message Processor: תמיד מומלץ להגדיר (לשנות) את ערך הזמן הקצוב לתפוגה של הקלט/פלט בשרת proxy ספציפי של API, במקום להגדיר אותו ב-Message Processor. כך תוכלו לוודא שהערך החדש של הזמן הקצוב לתפוגה ישפיע רק על שרת ה-API הספציפי ולא על כל שרתי ה-API שמעבירים את הבקשות דרך Message Processor.
מגדירים (משנים) את זמן הקצאת הזמן לתפוגה של הקלט/פלט במעבד ההודעות רק אם אתם בטוחים לחלוטין שהערך החדש של זמן הקצאת הזמן לתפוגה של הקלט/פלט נדרש או רלוונטי לכל שרתי ה-API proxy שפועלים במעבד ההודעות.
תרחישים לדוגמה
התרחישים שבקטע הזה יכולים לעזור לכם להבין איך להגדיר נכון את ערכי הזמן הקצוב לתפוגה של קלט/פלט.
תרחיש 1: בקשות ל-Apigee Edge מאפליקציות לקוח ישירות
בקטע הזה מתוארות שיטות מומלצות להגדרת ערכי הזמן הקצוב לתפוגה בהגדרה של Apigee Edge, כשאין רכיבים ביניים בין אפליקציית הלקוח ל-Apigee Edge ובין Apigee Edge לשרת הקצה העורפי.
הגדרה לדוגמה של Apigee ללא רכיבים ביניים
אם הגדרתם את Apigee Edge כפי שמוצג בתרשים שלמעלה, ללא רכיבים ביניים, כדאי להשתמש בשיטות המומלצות הבאות:
- אפליקציית הלקוח היא הרכיב הראשון בתהליך. צריך להגדיר את הערך highest timeout בצד הלקוח.
- שרת הקצה העורפי הוא הרכיב האחרון בתהליך. צריך להגדיר את הערך של הזמן הקצוב לתפוגה הנמוך ביותר בשרת הקצה העורפי.
- מגדירים את ערכי הזמן הקצוב לתפוגה בכל אחד מהרכיבים לפי הסדר הבא:
בדוגמה הבאה מוצגים ערכי זמן קצוב להמתנה שמוגדרים ברכיבים השונים בהתאם להנחיות שלמעלה, כדי למנוע בעיות:
תרחיש 2: בקשות ל-Apigee Edge מאפליקציות לקוח דרך רכיבים ביניים
בקטע הזה מתוארות שיטות מומלצות להגדרת ערכי הזמן הקצוב לתפוגה בהגדרה של Apigee Edge, שבה יש רכיב ביניים אחד או יותר בין אפליקציית הלקוח לבין Apigee Edge, וגם בין Apigee Edge לשרת הקצה העורפי.
הרכיבים הביניים יכולים להיות מאזן עומסים, רשת להצגת תוכן (CDN), NGINX וכו'.
הגדרת Apigee לדוגמה עם רכיב ביניים אחד בין הלקוח ל-Apigee Edge, ובין Apigee Edge לשרת הקצה העורפי
אם הגדרתם את Apigee Edge כפי שמוצג בתרשים שלמעלה, עם רכיב ביניים אחד או יותר, כדאי להשתמש בשיטות המומלצות הבאות:
- אפליקציית הלקוח היא הרכיב הראשון בתהליך. צריך להגדיר את הערך הגבוה ביותר של זמן הקצוב לתפוגה בצד הלקוח.
- שרת הקצה העורפי הוא הרכיב האחרון בתהליך. צריך להגדיר את הערך הנמוך ביותר של זמן הקצוב לתפוגה בשרת הקצה העורפי.
- מגדירים את ערכי הזמן הקצוב לתפוגה בכל אחד מהרכיבים, כולל הרכיבים הביניים, לפי הסדר הבא:
בדוגמה הבאה מוצגים ערכי זמן קצוב להמתנה שמוגדרים ברכיבים השונים בהתאם להנחיות שלמעלה, כדי למנוע בעיות:
