Rate limiting ב-Bitrix24: מדוע אינטגרציות נופלות
הפורטל סופר קריאות REST לפי מספר מונים בו-זמנית: תדירות כלליות של פניות מהאפליקציה, עומס על מתודות בודדות ומקביליות של בקשות.
ברגע שאינטגרציה עם מערכות חיצוניות מנצלת את המכסה שלה, בתגובה מתקבלת שגיאה של חריגה ממגבלת הבקשות — לרוב QUERY_LIMIT_EXCEEDED, לפעמים תגובה ריקה ללא גוף ונתונים. מבחוץ זה נראה כמו חילוף מקולקל: עסקאות ומשימות מפסיקות להתעדכן, למרות ששתי המערכות חיות וזמינות.
המחיר של שגיאת חילוף כזו אינו בקריאה בודדת שנכשלה. משימות רקע אינן מבחינות בין «המכסה נגמרה» לבין «הנתונים לא השתנו», ולכן מחזירות את הבקשה כולה; בשליחה חוזרת ללא מפתח אידמפוטנטיות חלק מהפעולות משוכפלות, וחלק אובדות באמצע החבילה.
לנתח את העקבות בדיעבד כמעט בלתי אפשרי — ביומן נראה רק עובדת הסירוב, בלי לציין מה בדיוק הספיק להתבצע.
לאחר מכן מופעל אפקט מצטבר. המערכת החיצונית מייצרת אירועים מהר יותר מהפורטל שמקבל אותם, תור משימות הרקע גדל מהר יותר מאשר מתפנה, וניסיונות חוזרים ללא השהיה מוסיפים עומס ומקרבים בעצמם את הסירוב הבא.
ייבוא המוני מאיץ זאת פי כמה: הם צורכים את המכסה אחרת מקריאות בודדות, ודוחקים החוצה חילוף שעבד עד כה כשורה.
אנו מפרטים כיצד זה נסגר בפועל: תחת rate limiting ב-Bitrix24 בונים מתזמן קריאות משלהם, מפזרים את העומס לאורך זמן והופכים את החזרות לבטוחות — כדי שהחילוף יגיע בשלמותו, ותור המשימות לא יגדל מהר יותר מאשר מטפלים בו.
מה משתנה לאחר הגדרת מגבלות בקשות
תדירות פניות מבוקרת (rate limiting) משנה את התנהגות האינטגרציה מיד. במקום מטח של קריאות מקבילות שנתקע ב-QUERY_LIMIT_EXCEEDED ומאבד חלק מהפעולות, מופיע תור חילוף: הבקשות יוצאות במנות, עם הפסקות וחזרות לאלה שחזרו עם שגיאה.
המגבלות ב-Bitrix24 נספרות בנפרד עבור האפליקציה ועבור המשתמש, ולכן התור נבנה לפי שני המונים, ולא לפי מספר הקריאות הכולל.
החלקת העומס ניכרת במטריקות. זמן החילוף מפסיק להיות תלוי בנפח של ייצוא חד-פעמי: במקום שבו סנכרון ספרים ועסקאות נפסק באמצע והתחיל מחדש מאפס, העבודה עוברת במעבר ראשון. שיעור הכשלים בחילוף יורד מאחוזים לפניות בודדות, והסנכרון הלילי נכנס לחלון שהוקצה לו.
חלונות שיא — מקרה נפרד. פרץ פעילות בבוקר, ייבוא המוני של פריטים, תפוצה ללידים: בעבר כל פרץ כזה התחרה עם האינטגרציה על אותה מגבלה, כעת תור הרקע מפנה מקום לבקשות אינטראקטיביות וממתין לתורו.
ליציבות האינטגרציה חשובה לא רק ההפסקה, אלא גם הצפויות של החזרות: אי-שינוי הפעולות בשליחה חוזרת, שמירת מצב התור בין אתחולים, יומן סירובים. תיעוד של מגבלות הפניות קובע ספים, אך אינו מחליף מדידות על פרופיל עומס אמיתי — אנו מבצעים אותן לפני ואחרי ההגדרה ומראים את ההבדל בכל מטריקה.
מגבלות Bitrix24: אפשרויות פנייה ל-API
REST של Bitrix24 מחזיר שגיאת QUERY_LIMIT_EXCEEDED לא כאשר «השרת עמוס», אלא כאשר האפליקציה חרגה מתדירות הקריאות המוסכמת. הסימפטום אחד — סירוב בתגובה, הסיבות שונות: לולאה על רשימה ללא הפסקות, סנכרון ספר ישירות, סקר שינויים כל דקה.
את שיטת הפנייה יש לבחור לפני כתיבת הקוד: לשנות את לוגיקת החילוף בדיעבד יקר יותר מאשר להטמיע מלכתחילה מתזמן משימות או מודל אירועים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תור בצד הלקוח עם חזרות | 2-3 תרחישי חילוף, זרם הקריאות קטן וצפוי | בעת פרץ, החזרות אוכלות את אותה מכסה; יש צורך בהגדלת ההשהיה בין ניסיונות ומונה כללי |
| עיבוד באצווה לפי לוח זמנים | סנכרון ספרים, דוחות, חילוף פעם בשעה או לעיתים רחוקות יותר | הנתונים מפגרים; יש לפזר את חלונות ההרצה, אחרת משימות חופפות זו לזו |
| מתווך בין מערכות | כמה מקורות וצרכנים, נדרש יומן אחיד ושליחה חוזרת | שירות נפרד: מתחזקים, מנטרים ומעדכנים אותו |
| מודל אירועים במקום סקר | תגובה לשינוי בישויות נדרשת מיד | תלוי בשלמות האירועים; חלק מהנתונים בכל זאת משלימים בקריאות ממוקדות |
| נהלים ידניים | ייצוא חד-פעמי, התאמות נדירות | גורם אנושי, אין אידמפוטנטיות, חזרה יוצרת כפילויות |
מה עושים בפועל
לרוב זה שילוב: מודל אירועים מכסה תגובה בזמן אמת, המתזמן משלים את מה שהוחמץ, והגבלת תדירות הקריאות מוציאה לשכבה נפרדת תוך התחשבות במכסה. בהמשך נפרט כיצד שכבה כזו בנויה.
כיצד אנו בונים הגבלת תדירות בקשות
לפני שינוי קוד האינטגרציות, אנו מחשבים את העומס האמיתי: כמה פניות בדקה יוצאות ל-Bitrix24, אילו תרחישים יוצרים שיאים ובאיזה רגע הפורטל מחזיר QUERY_LIMIT_EXCEEDED.
ללא מדידות אלה, כל הגדרה של rate limiting הופכת לניחוש עיוור — המגבלות או חותכות בקשות שימושיות, או שאינן מצילות מסירובים גורפים. להלן העבודה מתבצעת בשלבים.
- ביקורת אינטגרציות. אוספים את כל נקודות החילוף — מטפלי אירועים, חילוף עם 1C, שירותים חיצוניים, משימות רקע — ומתעדים את תדירות השיא ואת שיעור השגיאות בכל אחת.
- סכמת חילוף. ממיינים את הפניות לפי עדיפויות: פעולות קריטיות (עסקאות, חשבוניות, סטטוסי הזמנות) עוברות בזרם נפרד, סנכרונים המוניים — בזרם נפרד. מפרידים ביניהם כדי שייצוא באצווה לא יחסום קריאות דחופות.
- הגדרת תורים. מכניסים חוצץ לפני הפורטל עם מגבלה לאפליקציה ולמתודה, מאזנים שיאים ומחליקים פרצים מ-webhooks.
- כללי חזרות. מגדירים חזרה עם השהיה גדלה, מתחשבים בכותרת
Retry-After, הופכים פעולות לאידמפוטנטיות — חזרה אינה יוצרת כפילויות. - מתאר בדיקה. מריצים תרחישים עם שיא מלאכותי גבוה פי כמה מהעבודה, בודקים כיצד התור מתנהג והאם החילוף משתקם לאחר סדרת סירובים.
- הפעלה. מפעילים את המגבלות בהדרגה, תוך מעקב אחר שיעור הסירובים, עומק התור והשהיית העיבוד.
- העברה לתחזוקה. מעבירים לצוות התחזוקה את נהלי המגבלות, לוח מחוונים וספי התראות, כדי שהכללים לא יתפזרו עם גידול העומס.
בסופו של דבר, החילוף מפסיק להיתקע במגבלות הפורטל, וההתנהגות תחת עומס הופכת לצפויה.
תצורות, נהלים ותיעוד בסיום
הגדרת מגבלות אינה תיקון אחד בקוד, אלא אוסף חפצים שנשארים במאגר של הלקוח. הם מספיקים כדי שמהנדס חדש יבין את החילוף עם Bitrix24 בתוך יומיים יוכל לשנות את עצימות הקריאות בלי לקרוא מחדש את כל הקוד. להלן מה בדיוק אנו מעבירים.
- סכמת חילוף: אילו מתודות נקראות, באיזו תדירות, מי היוזם — הפורטל או המערכת החיצונית, היכן נקודות החזרה וכיצד מתפרס פרופיל העומס היומי.
- הגדרות תורים ולוחות זמנים: גודל החבילה, מרווח הסקר, עדיפויות תרחישים, חלונות לייצוא כבד שהוצאו משעות השיא.
- כללי חזרות: השהיה גדלה בין ניסיונות, תקרת מספר הניסיונות, הפרדת שגיאות לזמניות וקבועות, סדר טיפול בשארית שלא עובדה.
- טיפול בסירובים: התנהגות בעת תגובה עם חריגה מהמגבלה, רגע איפוס המונה, סכמת דרדור — הקריאה עוברת לתור במקום בקשה ישירה.
- יומני תצפית: שיעור התגובות עם סירוב עקב מגבלה, עומק התור, זמן מעבר חבילה, פאנלים מוכנים וספים שבהם מופעלת התראה.
- נהלי תחזוקה: מי ובאיזו תדירות בודק את היומנים, מה עושה בעת פרץ, באיזה סדר מתאמים שינויים במגבלות.
- תיעוד האינטגרציה: מפת המתודות בשימוש, המגבלות הפעילות, דוגמאות תצורה ורשימת בדיקה לחיבור תרחיש חילוף חדש.
כל סעיף מגובה בקונפיג עובד, ולא בתיאור «איך צריך». זה מה שמאפשר לתחזק את האינטגרציה בכוחות הצוות שלך — בלי לחזור אלינו לכל שינוי בעצימות.
מקרה בוחן: חילוף עם 1C הפסיק ליפול בגלל מגבלות
בפרויקט לדוגמה, החילוף בין 1C לפורטל התנהל בחבילות של כמה מאות פריטי מלאי. בחלונות שיא — סגירת חודש, עדכון מחירים המוני — מונה הפניות נתקע במגבלת המתודה, חלק מהקריאות החזירו QUERY_LIMIT_EXCEEDED, והחילוף נעצר באמצע החבילה.
התמונה לפני התיקונים: שיעור הפעולות הכושלות עמד על כ-18%, חילוף מלא ארך 4–5 שעות וחצה את חלון הלילה, וההרצה בבוקר קלט מחדש חבילות שלא הושלמו. טיפול בצברויות עלה לצוות 6–8 תיקונים ידניים בשבוע.
מה עשינו
הוצאנו את הקריאות לתור עם הגבלת תדירות בקשות (rate limiting) מתחת לסף המתודה, הוספנו השהיה עם גידול המרווח בין חזרות ומפתחות אידמפוטנטיות לפעולות כתיבה — החזרה הפסיקה ליצור כפילות. פיצלנו חבילות לפי זמן ביצוע, ולא לפי מספר רשומות: פרץ בספר אחד אינו חוסם יותר את האחרים.
מה השתנה
שיעור הפעולות הכושלות ירד מ-18% לשברי אחוז, חילוף מלא נכנס ל-1.5–2 שעות, תיקונים ידניים בשבוע — 6–8 → 0–1. זמן ההתאוששות לאחר תקלה הצטמצם מכמה שעות של טיפול ידני לאתחול חוזר של התור.
סוג הסירובים תחת עומס שיא בוטל: המגבלה אינה עוצרת יותר את החילוף — התור פשוט נמתח לאורך זמן, ופעולות שלא הושלמו מסתיימות במעבר הבא. הניטור רואה את מילוי התור ואת מספר החזרות, ולכן אנו לומדים על דרדור לפני שהנהלת החשבונות שואלת עליו.
מה לעשות אם החילוף כבר עובד ללא מגבלות
אינטגרציה פעילה כמעט אף פעם אינה «נקייה»: מטפלים מקבילים, קריאות חוזרות בלולאות, ייצוא ידני בזרם הכללי.
לכן תדירות פניות מבוקרת מוכנסת לא במקום הסכמה הנוכחית, אלא מעליה: מגביל שמים על קריאות יוצאות — תחילה במצב תצפית, שבו הוא רק סופר פניות לפי מתודות, מפרס אותן לפי שניות ומראה היכן תרחישים נתקעים ב-QUERY_LIMIT_EXCEEDED, בלי לחסום דבר.
לאחר מכן — הטמעה הדרגתית: תחילה סף רך, שבו חריגה אינה נדחית בשגיאה, אלא עוברת לתור עם השהיה; אחר כך סף קשיח; ורק לאחר מכן עדיפויות תרחישים וניקוי רשומות שנצברו. תאימות לאחור נשמרת בכך שהתרחיש עדיין מקבל תגובה — רק לא באופן מיידי, והחוזים ופורמטי הנתונים לא משתנים.
ללא עצירת החילוף משתנים הספים, ההשהיות, הרכב המתודות, עדיפויות התורים והזמנים הקצובים: זו תצורה שהמטפל קורא מחדש תוך כדי תנועה. חלון השהיה הכרחי במקום שבו משתנה הסמנטיקה — פורמט המשימה בתור, העברת חלק מהתרחישים למטפל נפרד, סדר הקריאות התלויות. בפועל מספיקה השהיה לשחרור התור ואתחול אחד.
הסיכון העיקרי בשינויים — מתודה «רועשת»: ייצוא המוני גוזל את תקציב הפניות ומאט תרחישים אחרים. עוזרים תורים נפרדים ומכסה לתרחיש. הסיכון השני — חזרות כתיבה לא אידמפוטנטיות: לאחר פסק זמן הקריאה יוצאת שוב, לכן המשימה מסומנת במפתח, והחזרה אינה יוצרת כפילויות.
ספקות טכניים לגבי מגבלות בקשות
מגבלות פניות ב-Bitrix24 לעיתים רחוקות שוברות חילוף סתם כך — תקלות מתחילות בשיא, כאשר ייצוא רקע חופף לפעולות עובדים. אספנו שאלות שנשאלות לרוב לפני תחילת העבודה.
מה לעשות אם העומס חל על שעות העבודה?
הבקשות מסודרות בתור עם עדיפויות: פעולות העובדים עוברות ראשונות, חילוף ספרים — ברקע. השיא נמרח לאורך זמן, המכסה אינה מנוצלת במלואה, ולכן פרצים קצרים אינם גורמים לסירובים.
האם יש לשלוח מחדש פעולות שכבר נדחו?
כן, אבל ממוקד. הפעולה מקבלת ביומן סימן אישור, החזרה מתבצעת רק עבור אלה שאינן מאושרות ועם השהיה גדלה. שליחה חוזרת היא אידמפוטנטית — מסמכים כפולים בחשבונאות לא מופיעים.
האם יידרש מתווך נפרד בין המערכות?
בדרך כלל לא: התור וחשבון החזרות חיים בתוך שירות האינטגרציה. מתווך נפרד נדרש כאשר הזרם מפוזר על פני כמה אתרים וצריך לתאם אותו באופן ריכוזי.
האם החילוף ייעצר במהלך ההטמעה?
העבודה מתבצעת במתאר בדיקה — עותק של הפורטל עם נתונים אנונימיים. ההחלפה נכנסת לחלון התקנון, והמצב הקודם נשאר כגיבוי למקרה של אי-התאמות.
האם מהירות הסנכרון תיפול?
סביר להניח שתעלה: כעת הזמן הולך על המתנה לאחר סירובים והפעלות ידניות מחדש. עיבוד באצווה וזרמים מקבילים בגבולות המכסה מקצרים את חלון החילוף, וחלק מהייצוא עובר לשעות שאינן שיא.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, אנו זקוקים לתמונה שלך של החילוף. תאר אילו מערכות מחוברות לפורטל Bitrix24 — מערכת חשבונאית, מחסן, שירותים חיצוניים — היכן מתרחשים סירובים ובאילו שעות העומס עולה מעל הרגיל.
חשובים הנפחים: כמה רשומות יוצאות ביממה ובאילו מנות, איזה חילוף קריטי ואיזה מועבר לחלון הלילה. הוסף מי מצדך מתחזק את האינטגרציות ואילו הרשאות מוכן לספק.
לאחר מכן נאסוף את הרכב העבודות — מאבחון ועד מסירה לתפעול:
- מפת אינטגרציות ופרופיל עומס: אילו מתודות נקראות, באיזו תדירות, באילו חלונות;
- סכמת הגבלת תדירות בקשות (rate limiting): מגבלות כלליות ואישיות, תור, עדיפות לתרחישים קריטיים;
- טיפול בסירובים: חזרה עם השהיה גדלה, תור נפרד לייצוא כבד, ניתוח שגיאות מגבלות;
- מטמון לספרים ולשאילתות חוזרות — חלק מהבקשות לא מגיעות לשירות;
- ניטור: שיעור סירובים, אורך התור, זמן המתנה — עם התראה לפני שהחילוף נעצר;
- נהלים ותיעוד: מגבלות, חלונות חילוף, כללים לשליחה ידנית של רשומות שאבדו;
- לוחות זמנים לשלבים כאבני דרך נפרדות ותמיכה לאחר ההטמעה: תיקוני מגבלות עם גידול נפחים, ניתוח אירועים.
ההערכה והתוכנית מגיעות עם פירוט לפי הרכב העבודות ולוחות הזמנים של השלבים, בלי ניסוחים כלליים. נדון במשימה ונתחיל בקטע שמסיר את הסירובים מהר ביותר.