הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
מדיניות SpikeArrest מגנה מפני עליות פתאומיות בתנועה באמצעות הרכיב <Rate>. האלמנט הזה מגביל את מספר הבקשות שמעובדות על ידי proxy ל-API ונשלחות אל ה-backend, וכך מגן מפני עיכובים בביצועים והשבתה.
המדיניות הזו היא מדיניות רגילה ואפשר לפרוס אותה בכל סוג של סביבה. מידע על סוגי המדיניות והזמינות שלהם בכל סוג סביבה זמין במאמר סוגי מדיניות.
ההבדל בין SpikeArrest לבין Quota
מדיניות המכסות מגדירה את מספר הודעות הבקשה שאפליקציית לקוח יכולה לשלוח ל-API במהלך שעה, יום, שבוע או חודש. מדיניות המכסות אוכפת מגבלות על צריכת משאבים באפליקציות לקוח, באמצעות שמירה על מונה מבוזר שסופר את הבקשות הנכנסות.
מומלץ להשתמש במכסת השימוש כדי לאכוף חוזים עסקיים או הסכמי רמת שירות (SLA) עם מפתחים ושותפים, ולא לניהול תנועה תפעולית. משתמשים ב-SpikeArrest כדי להגן מפני עליות פתאומיות בתנועת ה-API. כדאי לעיין גם במאמר השוואה בין מכסות ומדיניות של SpikeArrest.
סרטונים
בסרטונים האלה מוסבר על תרחישי שימוש במדיניות הזו:
למה צריך את זה
השוואה בין מדיניות מכסות
רכיב <SpikeArrest>
הגדרת המדיניות SpikeArrest.
| ערך ברירת המחדל | מידע נוסף מופיע בכרטיסייה מדיניות ברירת המחדל שבהמשך. |
| חובה? | אופציונלי |
| סוג | אובייקט מורכב |
| רכיב אב | לא רלוונטי |
| רכיבי צאצא |
<Identifier><MessageWeight><Rate> (חובה)<UseEffectiveCount> |
תחביר
רכיב <SpikeArrest> משתמש בתחביר הבא:
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <DisplayName>display_name</DisplayName> <Properties/> <Identifier ref="flow_variable"/> <MessageWeight ref="flow_variable"/> <Rate ref="flow_variable">rate[pm|ps]</Rate> <UseEffectiveCount>[false|true]</UseEffectiveCount> </SpikeArrest>
מדיניות ברירת המחדל
בדוגמה הבאה מוצגות הגדרות ברירת המחדל כשמוסיפים מדיניות SpikeArrest לזרימה בממשק המשתמש:
<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1"> <DisplayName>Spike Arrest-1</DisplayName> <Properties/> <Identifier ref="request.header.some-header-name"/> <MessageWeight ref="request.header.weight"/> <Rate>30ps</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>
לרכיב הזה יש את המאפיינים הבאים שמשותפים לכל המדיניות:
| מאפיין | ברירת מחדל | חובה? | תיאור |
|---|---|---|---|
name |
לא רלוונטי | חובה |
השם הפנימי של המדיניות. הערך של מאפיין אפשר להשתמש ברכיב |
continueOnError |
FALSE | אופציונלי | מגדירים את הערך false כדי להחזיר שגיאה אם המדיניות נכשלת. זו התנהגות צפויה ברוב המקרים. הגדרה ל-true מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים:
|
enabled |
TRUE | אופציונלי | מגדירים את הערך true כדי לאכוף את המדיניות, או את הערך false כדי להשבית את המדיניות. המדיניות לא נאכפת גם אם היא עדיין משויכת לזרימה. |
async |
FALSE | הוצא משימוש | המאפיין הזה הוצא משימוש. |
דוגמאות
בדוגמאות הבאות אפשר לראות כמה מהדרכים שבהן אפשר להשתמש במדיניות SpikeArrest:
דוגמה 1
בדוגמה הבאה, הקצב מוגדר לחמש בקשות בשנייה:
<SpikeArrest name="SA-Static-5ps"> <Rate>5ps</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>
מדיניות לדוגמה שמאפשרת עד 5 בקשות בשנייה. ההגבלה היא בקשה אחת לכל 200 מילישניות (1, 000/5) באמצעות החלקת נתונים.
דוגמה 2
בדוגמה הבאה, הקצב מוגדר ל-12 לדקה:
<SpikeArrest name="SA-Static-12pm"> <Rate>12pm</Rate> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
המדיניות לדוגמה הזו מאפשרת עד 12 בקשות בדקה, בקצב של בקשה אחת כל 5 שניות (60/12). אם יש יותר מבקשה אחת במרווח של 5 שניות, הבקשות האלה מותרות (ללא החלקה) בתנאי שמספר הבקשות נמוך ממגבלת הקצב שהוגדרה של 12 בקשות לדקה.
דוגמה 3
בדוגמה הבאה, הבקשות מוגבלות ל-12 בדקה (בקשה אחת מותרת כל חמש שניות, או 60/12):
<SpikeArrest name="SA-With-Dynamic-Weight-1"> <Rate>12pm</Rate> <Identifier ref="client_id" /> <MessageWeight ref="request_specific_weight" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
בנוסף, רכיב <MessageWeight> מקבל ערך מותאם אישית (הכותרת weight) שמשנה את משקלי ההודעות עבור אפליקציות או לקוחות ספציפיים. כך מקבלים שליטה נוספת על הגבלת הקצב של ישויות שמזוהות באמצעות הרכיב <Identifier>.
דוגמה 4
בדוגמה הבאה, המדיניות SpikeArrest מורה לחפש ערך של זמן ריצה שהוגדר באמצעות הבקשה שמועברת כמשתנה request.header.runtime_rate flow:
<SpikeArrest name="SA-From-Inbound-Header-1"> <Rate ref="request.header.runtime_rate" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
הערך של משתנה הזרימה צריך להיות בפורמט intpm או intps.
כדי לנסות את הדוגמה הזו, מריצים בקשה כמו הבקשה הבאה:
curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'
הפניה לרכיב צאצא
בקטע הזה מתוארים רכיבי הבן של <SpikeArrest>.
<DisplayName>
אפשר להשתמש במאפיין הזה בנוסף למאפיין name כדי לתת למדיניות שם אחר, שנשמע יותר טבעי, ב-UI של עורך ה-proxy לניהול.
הרכיב <DisplayName> משותף לכל סוגי המדיניות.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | זה שינוי אופציונלי. אם לא מציינים את <DisplayName>, המערכת משתמשת בערך של מאפיין name של המדיניות. |
| סוג | String |
| רכיב אב | <PolicyElement> |
| רכיבי צאצא | ללא |
רכיב <DisplayName> משתמש בתחביר הבא:
תחביר
<PolicyElement> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> ... </PolicyElement>
דוגמה
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.
<Identifier>
מאפשרת לכם לבחור איך לקבץ את הבקשות כדי שאפשר יהיה להחיל את מדיניות SpikeArrest על סמך הלקוח. לדוגמה, אפשר לקבץ בקשות לפי מזהה מפתח. במקרה כזה, הבקשות של כל מפתח ייספרו במסגרת המגבלה שלו למניעת עליות פתאומיות, ולא במסגרת כל הבקשות לשרת ה-proxy.
אפשר להשתמש בו בשילוב עם רכיב <MessageWeight> כדי לקבל שליטה פרטנית יותר על הגבלת קצב הבקשות.
אם משאירים את הרכיב <Identifier> ריק, מגבלת קצב אחת נאכפת על כל הבקשות ל-proxy ל-API הזה.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | אופציונלי |
| סוג | String |
| רכיב אב |
<SpikeArrest>
|
| רכיבי צאצא | ללא |
תחביר
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <Identifier ref="flow_variable"/> </SpikeArrest>
דוגמה 1
בדוגמה הבאה, מדיניות SpikeArrest מוחלת לפי מזהה מפתח:
<SpikeArrest name="Spike-Arrest-1"> <Identifier ref="developer.id"/> <Rate>42pm</Rate/> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
בטבלה הבאה מתוארים המאפיינים של <Identifier>:
| מאפיין | תיאור | ברירת מחדל | נוכחות |
|---|---|---|---|
ref |
מזהה את המשתנה שלפיו מדיניות SpikeArrest מקבצת בקשות נכנסות. אפשר להשתמש בכל משתנה של זרימת נתונים כדי לציין לקוח ייחודי, כמו המשתנים שזמינים עם מדיניות VerifyAPIKey. אפשר גם להגדיר משתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage. | לא רלוונטי | חובה |
האלמנט הזה מוסבר גם בפוסט הזה בקהילת Apigee.
<MessageWeight>
מציין את המשקל שהוגדר לכל הודעה. המשקל של ההודעה משנה את ההשפעה של בקשה יחידה על חישוב שיעור ההגנה מפני עלייה חדה בתנועה. המשקל של ההודעה יכול להיות כל משתנה של זרימת נתונים, כמו כותרת HTTP, פרמטר של שאילתה, פרמטר של טופס או תוכן של גוף ההודעה. אפשר גם להשתמש במשתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage.
אפשר להשתמש בו בשילוב עם <Identifier> כדי לווסת עוד יותר את הבקשות לפי לקוחות או אפליקציות ספציפיים.
לדוגמה, אם הערך של SpikeArrest <Rate> הוא 10pm, ואפליקציה שולחת בקשות במשקל 2, אז מותר לשלוח מהלקוח הזה רק חמש הודעות בדקה, כי כל בקשה נספרת כ-2.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | אופציונלי |
| סוג | מספר שלם |
| רכיב אב |
<SpikeArrest>
|
| רכיבי צאצא | ללא |
תחביר
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <MessageWeight ref="flow_variable"/> </SpikeArrest>
דוגמה 1
בדוגמה הבאה, הבקשות מוגבלות ל-12 בדקה (בקשה אחת מותרת כל חמש שניות, או 60/12):
<SpikeArrest name="SA-With-Dynamic-Weight-1"> <Rate>12pm</Rate> <Identifier ref="client_id" /> <MessageWeight ref="request_specific_weight" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
בדוגמה הזו, <MessageWeight> מקבל ערך מותאם אישית (הכותרת weight
בבקשה) שמשנה את המשקלים של ההודעות עבור לקוחות ספציפיים. כך מקבלים שליטה נוספת על הגבלת הקצב של ישויות שמזוהות באמצעות הרכיב <Identifier>.
בטבלה הבאה מתוארים המאפיינים של <MessageWeight>:
| מאפיין | תיאור | נוכחות | ברירת מחדל |
|---|---|---|---|
ref |
מזהה את משתנה הזרימה שמכיל את משקל ההודעה עבור הלקוח הספציפי. זה יכול להיות כל משתנה זרימה, כמו פרמטר של שאילתת HTTP, כותרת או תוכן של גוף ההודעה. מידע נוסף זמין במאמר בנושא משתני זרימה. אפשר גם להגדיר משתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage. | חובה | לא רלוונטי |
<Rate>
מציין את הקצב שבו מגבילים עליות חדות בתעבורת נתונים (או פרצי תעבורה) על ידי הגדרת מספר הבקשות שמותרות במרווחי זמן של דקה או שנייה. אפשר גם להשתמש ברכיב הזה בשילוב עם <Identifier> ועם <MessageWeight> כדי לווסת את תעבורת הנתונים בצורה חלקה בזמן הריצה על ידי קבלת ערכים מהלקוח. משתמשים ברכיב <UseEffectiveCount> כדי להגדיר את אלגוריתם הגבלת הקצב שבו נעשה שימוש במדיניות.
ב-SpikeArrest section of the Limits page מופיעות מגבלות הקצב המקסימליות שאפשר לציין.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | חובה |
| סוג | מספר שלם |
| רכיב אב |
<SpikeArrest>
|
| רכיבי צאצא | ללא |
תחביר
אפשר לציין מחירים באחת מהדרכים הבאות:
- שיעור סטטי שאתם מציינים כגוף של רכיב
<Rate> - ערך משתנה, שאפשר להעביר אותו על ידי הלקוח. צריך לציין את שם משתנה זרימה באמצעות המאפיין
ref.
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <Rate ref="flow_variable">rate[pm|ps]</Rate> </SpikeArrest>
ערכי שיעור תקפים (מוגדרים כערך משתנה או בגוף הרכיב) צריכים להיות בפורמט הבא:
-
intps(מספר הבקשות לשנייה, מוחלק למרווחי זמן של אלפיות שנייה) -
intpm(מספר הבקשות בדקה, מוחלק למרווחי שניות)
הערך של int חייב להיות מספר שלם חיובי שגדול מאפס.
דוגמה 1
בדוגמה הבאה, הקצב מוגדר לחמש בקשות לשנייה:
<SpikeArrest name="SA-Static-5ps"> <Rate>5ps</Rate> <UseEffectiveCount>false</UseEffectiveCount> </SpikeArrest>
המדיניות מאפשרת שליחה של בקשה אחת בכל 200 אלפיות השנייה (1,000/5).
דוגמה 2
בדוגמה הבאה, הקצב נקבע ל-12 בקשות בדקה:
<SpikeArrest name="SA-Static-12pm"> <Rate>12pm</Rate> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
המדיניות הזו מחליקה את הקצב כך שמתאפשרת בקשה אחת כל חמש שניות (60/12).
בטבלה הבאה מתוארים המאפיינים של <Rate>:
| מאפיין | תיאור | נוכחות | ברירת מחדל |
|---|---|---|---|
ref |
מזהה משתנה של תהליך עבודה שמציין את הקצב. המשתנה יכול להיות כל משתנה של זרימת נתונים, כמו פרמטר של שאילתת HTTP, כותרת או תוכן של גוף ההודעה, או ערך כמו KVM. מידע נוסף זמין במאמר חומר עזר בנושא משתני זרימה.
אפשר גם להשתמש במשתנים מותאמים אישית באמצעות מדיניות JavaScript או מדיניות AssignMessage. אם מגדירים גם את לדוגמה: <Rate ref="request.header.custom_rate">1pm</Rate> בדוגמה הזו, אם הלקוח לא מעביר כותרת אתם יכולים להשתמש ב- אם מציינים ערך למאפיין |
אופציונלי | לא רלוונטי |
Rate שקובעים את ההתנהגות של הגבלת התנועה:
| מאפיין | תיאור |
|---|---|
messagesPerPeriod |
מציין את מספר ההודעות שמותר לשלוח בפרק זמן מוגדר. לדוגמה, אם המדיניות מוגדרת ל-10ps (10 לשנייה), הערך של messagesPerPeriod יהיה 10. |
periodInMicroseconds |
הגדרת התקופה, במיקרו-שניות, שבה מחושב הערך של messagesPerPeriod. בהגדרה של '10ps', הערך הזה יהיה 1,000,000, ששווה לשנייה אחת. |
maxBurstMessageCount |
מייצג את המספר המקסימלי של בקשות שאפשר לאשר באופן מיידי או בפרק זמן קצר בתחילת מרווח חדש. |
<UseEffectiveCount>
באמצעות הרכיב הזה אפשר לבחור בין אלגוריתמים שונים לזיהוי קפיצות פתאומיות, על ידי הגדרת הערך ל-true או ל-false, כמו שמוסבר בהמשך:
TRUE
אם המדיניות מוגדרת ל-true, המדיניות SpikeArrest מופצת באזור. המשמעות היא שספירת הבקשות מסונכרנת בין מעבדי ההודעות (MP) באזור. בנוסף, נעשה שימוש באלגוריתם להגבלת קצב של 'חלון נע'. האלגוריתם הזה מספק התנהגות עקבית של הגבלת קצב הבקשות, ולא מבצע 'החלקה' של מספר הבקשות הנכנסות שאפשר לשלוח לשרת העורפי. אם נשלחות הרבה בקשות במרווח זמן קצר, הן יאושרו כל עוד הן לא חורגות ממגבלת הקצב שהוגדרה, כפי שמוגדר ברכיב <Rate>. לדוגמה:
<SpikeArrest name="Spike-Arrest-1"> <Rate>12pm</Rate> <Identifier ref="client_id" /> <MessageWeight ref="request.header.weight" /> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
false (ברירת מחדל)
אם המדיניות מוגדרת לערך false (ברירת המחדל),
היא משתמשת באלגוריתם token bucket כדי להחלק את העליות החדות בתנועה על ידי
חלוקת מגבלת הקצב שציינתם למרווחים קטנים יותר. החיסרון בגישה הזו הוא שאולי בקשות לגיטימיות רבות שמתקבלות בפרק זמן קצר יידחו.
לדוגמה, אם תזינו קצב של 30pm (30 בקשות לדקה). במהלך בדיקה, יכול להיות שתחשבו שאפשר לשלוח 30 בקשות בשנייה אחת, כל עוד הן נשלחו בתוך דקה. אבל זה לא האופן שבו המדיניות אוכפת את ההגדרה. אם חושבים על זה, 30 בקשות בתוך תקופה של שנייה אחת יכולות להיחשב כעלייה קטנה במספר הבקשות בסביבות מסוימות.
- שיעורים לדקה מוחלקים לבקשות מלאות שמותרות במרווחים של שניות.
לדוגמה, אם מגדירים 30pm, המערכת תבצע החלקה באופן הבא:
60 שניות (דקה אחת) חלקי 30pm = מרווחים של 2 שניות, או בקשה אחת מותרת כל 2 שניות. A בקשה שנייה בתוך 2 שניות תיכשל. בנוסף, בקשה 31 בתוך דקה תיכשל. - השיעורים לשנייה מוחלקים לבקשות מלאות שמותרות במרווחים של אלפיות השנייה.
לדוגמה, אם המגבלה היא 10ps, המערכת תבצע החלקה באופן הבא:
1,000 מילישניות (שנייה אחת) חלקי 10ps = מרווחים של 100 מילישניות, או בקשה אחת מותרת כל 100 מילישניות. בקשה שנייה בתוך 100 אלפיות השנייה תיכשל. בנוסף, בקשה 11 בתוך שנייה תיכשל.
| ערך ברירת המחדל | לא נכון |
| חובה? | אופציונלי |
| סוג | בוליאני |
| רכיב אב |
<SpikeArrest>
|
| רכיבי צאצא | ללא |
משתני זרימה
כשמדיניות SpikeArrest מופעלת, Apigee מאכלס קבוצה של משתני זרימה. אפשר להשתמש במשתני הזרימה האלה בזרימות מותנות, או לצורך מעקב וניתוח.
| משתנה | סוג | הרשאה | תיאור |
|---|---|---|---|
ratelimit.policy_name.available.count |
ארוכה | קריאה בלבד | הפונקציה מחזירה את מספר ההגנות מפני עליות פתאומיות בזמן שזמינות במרווח הזמן. |
ratelimit.policy_name.exceed.count |
ארוכה | קריאה בלבד | הפונקציה מחזירה 1 אם חרגתם מהמגבלה של SpikeArrest בחלון הזמן הנוכחי. |
ratelimit.policy_name.failed |
בוליאני | קריאה בלבד | המשתנה הזה הוא true אם אירעה שגיאת ביצוע פנימית במדיניות. אין להשתמש במשתנה הזה כדי לבדוק אם חרגתם ממגבלת הקצב.
יכול להיות שהיא מוגדרת ל-true בעומס גבוה בגלל העיצוב של המדיניות, שמאפשר גישה במקרה של כשל.
|
מידע נוסף זמין במאמר חומר עזר בנושא משתני זרימה.
הפניה לשגיאה
בקטע הזה מתוארים קודי התקלה והודעות השגיאה שמוחזרים ומשתני התקלה שמוגדרים על ידי Apigee כשמדיניות כזו מפעילה שגיאה. חשוב להכיר את המידע הזה אם מפתחים כללי תקלה לטיפול בתקלות. מידע נוסף זמין במאמרים מה שצריך לדעת על שגיאות במדיניות וטיפול בתקלות.
שגיאות זמן ריצה
השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.
| קוד תקלה | סטטוס HTTP | מטרה | תיקון |
|---|---|---|---|
policies.ratelimit.FailedToResolveSpikeArrestRate |
500 |
השגיאה הזו מתרחשת אם אי אפשר לפתור את ההפניה למשתנה שמכיל את הגדרת התעריף
בתוך הרכיב <Rate> לערך במדיניות SpikeArrest. הרכיב הזה הוא חובה ומשמש להגדרת קצב ההגבלה של העלייה הפתאומית בצורה של intpm או intps. |
build |
policies.ratelimit.InvalidMessageWeight |
500 |
השגיאה הזו מתרחשת אם הערך שצוין לרכיב <MessageWeight> באמצעות משתנה של זרימת נתונים לא תקין (ערך לא שלם). |
build |
policies.ratelimit.SpikeArrestViolation |
429 |
הייתה חריגה ממגבלת הקצב. |
שגיאות בהטמעה
השגיאות האלה יכולות להתרחש כשפורסים שרת proxy שמכיל את המדיניות הזו.
| שם השגיאה | מטרה | תיקון |
|---|---|---|
InvalidAllowedRate |
אם הערך של קצב עצירת העלייה הפתאומי שצוין ברכיב <Rate> של המדיניות SpikeArrest
אינו מספר שלם, או אם לערך של הקצב אין את הסיומת ps או pm, הפריסה של שרת ה-proxy של ה-API תיכשל. |
build |
משתני תקלות
המשתנים האלה מוגדרים כשמתרחשת שגיאת זמן ריצה. מידע נוסף על שגיאות שקשורות למדיניות
| משתנים | כאשר: | דוגמה |
|---|---|---|
fault.name="fault_name" |
fault_name הוא שם התקלה, כפי שמופיע בטבלה שגיאות בזמן ריצה שלמעלה. שם התקלה הוא החלק האחרון של קוד התקלה. | fault.name Matches "SpikeArrestViolation" |
ratelimit.policy_name.failed |
policy_name הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה. | ratelimit.SA-SpikeArrestPolicy.failed = true |
דוגמה לתגובת שגיאה
דוגמה לתגובה עם שגיאה:
{ "fault":{ "detail":{ "errorcode":"policies.ratelimit.SpikeArrestViolation" }, "faultstring":"Spike arrest violation. Allowed rate : 10ps" } }
דוגמה לכלל שגיאה
בדוגמה הבאה מוצג כלל לטיפול בשגיאות שנועד לטפל בשגיאת SpikeArrestViolation:
<FaultRules>
<FaultRule name="Spike Arrest Errors">
<Step>
<Name>Assign-Message-1</Name>
<Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
</Step>
<Condition>(ratelimit.Spike-Arrest-1.exceed.count > 0) or (ratelimit.Spike-Arrest-1.available.count < 1)</Condition>
</FaultRule>
</FaultRules>קוד הסטטוס הנוכחי של HTTP לחריגה ממגבלת קצב שהוגדרה על ידי מדיניות מכסה או SpikeArrest הוא 429 (יותר מדי בקשות).
סכימות
כל סוג מדיניות מוגדר על ידי סכימת XML (.xsd). סכימות מדיניות זמינות ב-GitHub.
נושאים קשורים
- מדיניות מכסה: מדיניות מכסה, כדי להגביל את התנועה בלקוחות ספציפיים
- הגבלת קצב של יצירת בקשות – סקירה כללית על הגבלת קצב של יצירת בקשות
- השוואה בין מכסה לבין מדיניות SpikeArrest