מדיניות מכסה

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

מה

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

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

אל תשתמשו במכסת נפח כדי להתגונן מפני עליות פתאומיות בתנועה הכוללת. לשם כך, משתמשים במדיניות 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, הדלפק אף פעם לא מתאפס, אבל הוא מחושב מחדש בכל בקשה.

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

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

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

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

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

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

אפשרות אחרת היא להגדיר כמה מדיניות מכסה ב-API Proxy ולהשתמש במדיניות שונה בכל זרימה. לכל מדיניות מכסת שימוש יש מונה משלה, שמבוסס על מאפיין 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> על סמך הערך של משתנה זרימה. לכל תג צאצא שונה של <Class>, המדיניות שומרת על מונה שונה.<Allow>

כדי להשתמש ברכיב <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> element

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

הפניה לשגיאה

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

Fault variables

These variables are set when this policy triggers an error. For more information, see What you need to know about policy errors.

Example error response

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

Example fault rule

<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

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