מדיניות בנושא מכסות

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

מה

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

• המוצר שמכיל את ה-proxy ל-API
• האפליקציה ששולחת את הבקשה ל-API
• מפַתח האפליקציה
• קריטריונים רבים אחרים

אל תשתמשו במכסת נפח כדי להתגונן מפני עליות חדות בנפח התנועה הכולל. לשם כך, משתמשים במדיניות Spike Arrest. מדיניות Spike Arrest

סרטונים

בסרטונים האלה מוצג ניהול מכסות באמצעות מדיניות המכסות:

דוגמאות

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

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

מידע על מדיניות המכסות

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

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

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

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

סוגים של כללי מדיניות בנושא מכסות

מדיניות המכסות תומכת בכמה סוגים שונים של מדיניות: ברירת מחדל, calendar,‏ flexi ו-rollingwindow. כל סוג מגדיר מתי מתחיל מונה המכסה ומתי הוא מתאפס, כמו שמוצג בטבלה הבאה:

עבור type="calendar", צריך לציין את הערך של <StartTime>.

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

לדוגמה, אתם מגדירים חלון של שעתיים שמאפשר 1,000 בקשות. בקשה חדשה מתקבלת בשעה 16:45.המדיניות מחשבת את מספר הבקשות בחלון של שעתיים אחורה, כלומר מספר הבקשות מאז השעה 14:45. אם לא חרגתם ממגבלת המכסה בחלון הזמן של שעתיים, הבקשה תאושר.

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

בסוג rollingwindow, הדלפק אף פעם לא מתאפס, אבל הוא מחושב מחדש בכל בקשה.

הסבר על מוניטורים של מכסות

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

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

• תהליך A מופעל -> מדיניות הקצאה MyQuotaPolicy מופעלת והמונה שלה = 1
• תהליך B מופעל -> מדיניות MyQuota מופעלת והמונה שלה = 2
• תהליך A מבוצע -> מדיניות MyQuota מבוצעת והמונה שלה = 3
• תהליך C מבוצע -> מדיניות המכסה שלי מבוצעת והמונה שלה = 4
• תהליך A מבוצע -> מדיניות המכסה שלי מבוצעת והמונה שלה = 5

הבקשה הבאה לאחד משלושת התהליכים נדחית כי מונה המכסה הגיע למגבלה שלו.

שימוש באותה מדיניות מכסה ביותר ממקום אחד בתהליך של proxy ל-API, שעלול לגרום למכסה להיגמר מהר יותר מהצפוי, הוא דפוס אנטי שמתואר בThe Book of Apigee Edge Antipatterns.

אפשרות אחרת היא להגדיר כמה מדיניות מכסה ב-proxy ל-API ולהשתמש במדיניות שונה בכל זרימה. לכל מדיניות מכסה יש מונה משלה, שמבוסס על מאפיין name של המדיניות.

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

סימון זמן

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

הפורמט של מכסת הזמן הוא פורמט התאריך הבינלאומי שמוגדר בתקן הבינלאומי ISO 8601.

התאריכים מוגדרים כשנה, חודש ויום, בפורמט הבא: YYYY-MM-DD. לדוגמה, 2015-02-04 מייצג את 4 בפברואר 2015.

השעה ביום מוגדרת כשעות, דקות ושניות בפורמט הבא: hours:minutes:seconds. לדוגמה, 23:59:59 מייצג את השעה שנייה אחת לפני חצות.

שימו לב שיש שני סימונים, 00:00:00 ו-24:00:00, כדי להבחין בין שתי חצות שיכולות להיות משויכות לתאריך אחד. לכן, 2015-02-04 24:00:00 הוא אותו תאריך ושעה כמו 2015-02-05 00:00:00. בדרך כלל עדיף להשתמש בסימון השני.

קבלת הגדרות מכסה מהגדרות מוצר ה-API

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

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

מידע נוסף על שימוש בהגדרות מכסה ממוצר API מופיע בדוגמה 'מכסה דינמית' שבהמשך המאמר.

מידע על הגדרת מוצרי API עם מכסות זמין במאמר יצירת מוצרי API.

הפניה לרכיב

בהמשך מפורטים רכיבים ומאפיינים שאפשר להגדיר במדיניות הזו. חשוב לדעת שחלק מהשילובים של רכיבים הם בלעדיים או לא נדרשים. דוגמאות לשימוש ספציפי המשתנים verifyapikey.VerifyAPIKey.apiproduct.* שבהמשך זמינים כברירת מחדל כשמשתמשים במדיניות Verify API Key (אימות מפתח API) שנקראת VerifyAPIKey כדי לבדוק את מפתח ה-API של האפליקציה בבקשה. ערכי המשתנים מגיעים מהגדרות המכסה במוצר ה-API שאליו משויך המפתח, כפי שמתואר במאמר קבלת הגדרות המכסה מהגדרת מוצר ה-API.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
</Quota>

מאפייני <Quota>

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

המאפיינים הבאים ספציפיים למדיניות הזו.

בטבלה הבאה מתוארים מאפיינים שמשותפים לכל רכיבי ההורה של המדיניות:

&lt;DisplayName&gt; רכיב

צריך להשתמש בנוסף למאפיין name כדי להוסיף תווית למדיניות עורך proxy של ממשק משתמש לניהול עם שם אחר בשפה טבעית.

<DisplayName>Policy Display Name</DisplayName>

אלמנט <Allow>

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

בהמשך מוצגות שלוש דרכים להגדיר את הרכיב <Allow>:

<Allow count="2000"/>

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

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

מאפיינים

אלמנט <Allow>/<Class>

רכיב <Class> מאפשר להגדיר תנאי לערך של רכיב <Allow> על סמך הערך של משתנה זרימה. לכל תג צאצא <Allow>שונה של <Class>, המדיניות שומרת על מונה שונה.

כדי להשתמש ברכיב <Class>, מציינים משתנה של זרימת נתונים באמצעות המאפיין ref בתג <Class>. לאחר מכן, Edge משתמש בערך של משתנה הזרימה כדי לבחור אחד מתגי הצאצא <Allow> כדי לקבוע את המספר המותר של המדיניות. ‫Edge מתאים את הערך של משתנה הזרימה למאפיין class של התג <Allow>, כמו שמוצג בהמשך:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

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

מאפיינים

‫<Allow>/<Class>/<Allow> element

הרכיב <Allow> מציין את המגבלה של מונה מכסת השימוש שהוגדר על ידי הרכיב <Class>. לכל תג צאצא שונה של <Allow> <Class>, המדיניות שומרת על מונה שונה.

לדוגמה:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

בדוגמה הזו, מדיניות הקצאה לשירות שומרת על שני מוני מכסות בשמות peak_time ו-off_peak_time.

מאפיינים

אלמנט <Interval>

המאפיין הזה משמש לציון מספר שלם (לדוגמה, 1, 2, 5, 60 וכן הלאה) שיוצמד לערך של TimeUnit שתציינו (minute,‏ hour,‏ day,‏ week או month) כדי לקבוע את תקופת הזמן שבמהלכה Edge יחשב את השימוש במכסה.

לדוגמה, אם Interval הוא 24 ו-TimeUnit הוא hour, המכסה תחושב במהלך 24 שעות.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

מאפיינים

אלמנט <TimeUnit>

התג הזה משמש לציון יחידת הזמן שרלוונטית למכסת השימוש.

לדוגמה, אם Interval הוא 24 ו-TimeUnit הוא hour, המכסה תחושב במהלך 24 שעות.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

מאפיינים

אלמנט <StartTime>

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

לדוגמה:

<StartTime>2017-7-16 12:00:00</StartTime>

רכיב <Distributed>

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

אם משתמשים בערך ברירת המחדל false, יכול להיות שתחרגו מהמכסה כי המונה של כל מעבד הודעות לא משותף:

<Distributed>true</Distributed>

כדי להבטיח שהמונים מסונכרנים ומעודכנים בכל בקשה, צריך להגדיר את <Distributed> ואת <Synchronous> כ-true:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

אלמנט <Synchronous>

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

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

ברירת המחדל של מרווח העדכון האסינכרוני היא 10 שניות. כדי להגדיר את ההתנהגות האסינכרונית הזו, משתמשים ברכיב AsynchronousConfiguration.

<Synchronous>false</Synchronous>

אלמנט <AsynchronousConfiguration>

המדיניות הזו מגדירה את מרווח הזמן בין הסנכרונים של מוני מכסות מבוזרים, כשרכיב ההגדרה של המדיניות <Synchronous> לא קיים או קיים ומוגדר לערך false.

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

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

או

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

אלמנט <AsynchronousConfiguration>/<SyncIntervalInSeconds>

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

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

מרווח הסנכרון צריך להיות גדול מ-10 שניות או שווה לו, כפי שמתואר בנושא מגבלות.

אלמנט <AsynchronousConfiguration>/<SyncMessageCount>

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

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

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

אלמנט <Identifier>

משתמשים ברכיב <Identifier> כדי להגדיר את המדיניות ליצירת מוני נתונים ייחודיים על סמך משתנה של זרימת נתונים.

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

האלמנט הזה מתואר גם בפוסט הבא בקהילת Apigee: Quota identifier across different policies.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

מאפיינים

אלמנט <MessageWeight>

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

לדוגמה, אם רוצים לספור הודעות POST כהודעות 'כבדות' או יקרות פי שניים מהודעות GET. לכן, מגדירים את MessageWeight לערך 2 עבור POST ולערך 1 עבור GET. אפשר אפילו להגדיר את MessageWeight ל-0 כדי שהבקשה לא תשפיע על המונה. בדוגמה הזו, אם המכסה היא 10 הודעות בדקה והערך של MessageWeight לבקשות POST הוא 2, המכסה מאפשרת 5 בקשות POST בכל מרווח של 10 דקות. כל בקשה נוספת, POST או GET, לפני איפוס המונה נדחית.

צריך לציין ערך שמייצג את MessageWeight באמצעות משתנה של זרימת נתונים. אפשר לחלץ את הערך מכותרות HTTP, מפרמטרים של שאילתה, ממטען ייעודי (payload) של בקשת XML או JSON או מכל משתנה אחר של זרימת נתונים. לדוגמה, הגדרתם אותו בכותרת בשם weight:

<MessageWeight ref="message_weight"/>

משתני זרימה

משתני ה-Flow המוגדרים מראש הבאים מאוכלסים באופן אוטומטי כשמדיניות מכסת השימוש מופעלת. מידע נוסף על משתני Flow זמין במאמר חומר עזר בנושא משתנים.

הפניה לשגיאה

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

שגיאות זמן ריצה

השגיאות האלה עשויות להתרחש כשהמדיניות מופעלת.

שגיאות פריסה

משתני כשל

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

דוגמה לתגובת שגיאה

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

דוגמה לכלל שגוי

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

סכימות

נושאים קשורים

מדיניות ResetQuota

מדיניות SpikeArrest

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