מכסת Google Sheets API היא 300 בקשות לדקה לפרויקט ו-60 לדקה למשתמש, לקריאה ולכתיבה בנפרד. למה אוטומציה חוצה אותן, ואיך מתקנים בלי לעזוב את הגיליון.
עיקרי הדברים
- המכסות המתועדות: 300 בקשות לדקה לפרויקט ו-60 לדקה למשתמש לכל פרויקט, בנפרד לקריאה ולכתיבה.
- החריגה מוחזרת כ-429, וההנחיה הרשמית היא נסיגה מעריכית. אחרי דקה אפשר להריץ בקשות שוב.
- המכסה למשתמש היא זו שנשברת ראשונה, כי כל האוטומציות רצות לרוב תחת אותו חשבון שירות.
- בקשה אחת שכותבת 500 שורות ובקשה אחת שכותבת שורה אחת עולות אותו דבר במכסה. זה כל הסיפור.
- גם בקשה תקינה נכשלת אם היא רצה יותר מ-180 שניות. זו מגבלת זמן נפרדת מהמכסה.
Google מפרסמת מכסות מפורשות ל-Sheets API: 300 בקשות קריאה לדקה לפרויקט ו-60 לדקה למשתמש בכל פרויקט, ובדיוק אותם מספרים לכתיבה, כמכסה נפרדת. חריגה מוחזרת כשגיאת 429 עם ההודעה Too many requests. אוטומציה חוצה את הסף הזה כי היא כותבת שורה-שורה במקום לאגד בקשות.
המספרים, ואיזה מהם באמת עוצר אתכם
| המכסה | הערך | למי היא נספרת |
|---|---|---|
| בקשות קריאה לדקה | 300 | לפרויקט |
| בקשות קריאה לדקה למשתמש | 60 | למשתמש בכל פרויקט |
| בקשות כתיבה לדקה | 300 | לפרויקט |
| בקשות כתיבה לדקה למשתמש | 60 | למשתמש בכל פרויקט |
| זמן ריצה מרבי לבקשה | 180 שניות | לבקשה בודדת |
השורה השנייה והרביעית הן אלה שכואבות. מכסה של 60 בקשות לדקה למשתמש פירושה בקשה אחת בשנייה בממוצע. תהליך שרץ בלולאה על 400 שורות ומעדכן כל אחת בנפרד חורג אחרי כדקה - גם אם הוא היחיד שרץ באותו רגע.
חשוב גם מה לא מופיע בטבלה: אין מכסה יומית מצטברת. כל עוד אתם בתוך המכסה לדקה, אין תקרה נוספת שתעצור אתכם בהמשך היום.
למה גיליון שעבד שנה מתחיל להיכשל עכשיו?
כי המכסה נספרת על קצב בקשות ולא על גודל נתונים, ולכן שלושה שינויים שנראים תמימים חוצים אותה בלי שאף אחד נגע בקוד:
- נוספה אוטומציה שנייה. שני תרחישים שרצים תחת אותו חשבון שירות מתחלקים במכסת ה-60 לדקה של אותו משתמש, ולא מקבלים אחת כל אחד.
- מספר השורות גדל. לולאה שרצה על 50 שורות מבצעת 50 בקשות; אותה לולאה על 300 שורות מבצעת 300, ואותו קוד בדיוק מתחיל להיכשל.
- הטריגר נעשה תכוף יותר. מעבר מהרצה כל שעה להרצה כל חמש דקות מכפיל את הצריכה פי שתים-עשרה בלי שום שינוי בלוגיקה.
הסימן המזהה: הכישלון אינו קבוע. חלק מהשורות נכתבות וחלק לא, וההרצה הבאה עוברת. גיליון שנכשל בצורה עקבית הוא בדרך כלל בעיית הרשאות; גיליון שנכשל באופן חלקי ומשתנה הוא כמעט תמיד מכסה.
שלוש הטעויות שמכפילות את מספר הבקשות
- קריאה בתוך לולאה. שליפת ערך לכל שורה בנפרד במקום קריאה אחת של הטווח כולו. 300 שורות הופכות ל-300 בקשות קריאה.
- כתיבה שורה-שורה. עדכון של תא אחד בכל פעם, בדרך כלל בגלל שהאוטומציה בנויה בתוך לולאת "לכל פריט".
- בדיקה חוזרת של אותו נתון קבוע. קריאת אותה שורת כותרות או אותו טווח הגדרות בכל איטרציה, במקום פעם אחת בתחילת ההרצה.
שלושתן נובעות מאותה תפיסה: התייחסות לגיליון כאל מסד נתונים שאפשר לשלוח אליו שאילתה קטנה מתי שרוצים. Sheets API אינו בנוי כך - הוא בנוי סביב טווחים.
איך מקטינים בקשות בלי לעזוב את הגיליון
- קראו את כל הטווח פעם אחת לתוך הזיכרון, עבדו בזיכרון, וכתבו בחזרה פעם אחת. זו הפעולה עם ההחזר הגבוה ביותר.
- אגדו מספר טווחים לבקשה אחת במקום בקשה נפרדת לכל טווח.
- הוסיפו שורות בקבוצה אחת בסוף ההרצה, ולא בכל איטרציה.
- הפרידו בין אוטומציות לפרויקטים או למשתמשים שונים, כדי שלא יתחלקו באותה מכסה לדקה.
- אחסנו ערכי הגדרה קבועים באוטומציה עצמה ולא בטאב שנקרא בכל סבב.
- הריצו את הסנכרון על שינויים בלבד - מה שהשתנה מאז החותמת האחרונה, לא הכול.
- אל תפצלו בקשה ענקית לאלף בקשות זעירות כדי "לא להיתקע". זה מחליף מגבלת זמן במגבלת מכסה.
איך נראית נסיגה נכונה אחרי 429
התיעוד של Google אינו משאיר את זה לפרשנות: בעת חריגה יש להשתמש באלגוריתם נסיגה מעריכית, וההמתנה בין ניסיונות מחושבת כמינימום בין תקרת נסיגה לבין שתיים בחזקת מספר הניסיון בתוספת רכיב אקראי במילישניות. הרכיב האקראי אינו קישוט - בלעדיו כל התהליכים שנכשלו יחד יחזרו לנסות באותה מילישנייה ויפילו את עצמם שוב.
- הגדירו תקרת נסיגה ואל תנסו שוב לנצח.
- הוסיפו רעש אקראי לכל השהיה.
- ספרו כמה ניסיונות חוזרים היו בכל הרצה. עלייה במספר הזה היא ההתרעה המוקדמת לפני שהתהליך מתחיל לאבד נתונים.
מתי הגיליון הוא הכלי הלא נכון?
כשמכסה חוזרת אחרי שכבר איגדתם בקשות. אם ההרצה כבר עושה קריאה אחת וכתיבה אחת ועדיין נתקעת, הבעיה אינה בקוד אלא בכך שהגיליון משמש מסד נתונים תפעולי. סימנים נוספים לאותה מסקנה: יותר ממשתמש אחד עורך בו-זמנית, נוסחאות שמחשבות מחדש בכל טעינה, וטאבים שקיימים רק כדי לשמור מצב של תהליך.
התשובה במקרה כזה אינה בהכרח מעבר מלא. לרוב מספיק להעביר את שכבת הכתיבה למסד נתונים ולהשאיר את הגיליון כתצוגה שמתרעננת פעם בפרק זמן קבוע - קריאה אחת במקום מאות.
איך מוודאים שזו באמת מכסה ולא בעיה אחרת
שלוש בעיות שונות מייצרות תחושה זהה של "הגיליון לא מתעדכן", והבידול ביניהן לוקח דקות ספורות:
- מכסה. הכישלון חלקי ומשתנה, מופיע בשיא הפעילות, וקוד הסטטוס הוא 429. הרצה חוזרת אחרי דקה עוברת.
- הרשאות. הכישלון עקבי לחלוטין ומופיע בכל הרצה, כולל הרצה ידנית. שינוי בשיתוף הקובץ או בגישת חשבון השירות הוא החשוד המיידי.
- מגבלת זמן. הבקשה עצמה גדולה מדי ורצה מעבר ל-180 שניות. כאן האטה לא תעזור, ודווקא פיצול לבקשות קטנות יותר הוא הפתרון - ההפך המדויק מהתיקון למכסה.
שווה גם להפריד בין שכבות: הרצה דרך Apps Script נמדדת במערכת מכסות משלה, נפרדת ממכסת ה-Sheets API של פרויקט ב-Google Cloud. תהליך שנכשל דרך אחת השכבות ועובד דרך השנייה מצביע על כך שהמגבלה שנשברה אינה זו שחשבתם.
- תעדו את קוד הסטטוס המלא ולא רק את הודעת הכלי שבו אתם עובדים.
- בדקו כמה בקשות יצאו בפועל בדקה, ולא כמה שורות עובדו.
- הריצו את אותה פעולה ידנית כשאין עומס. אם היא עוברת, זו מכסה.
קשור: איך לבצע אוטומציה של Google Sheets, ארכיטקטורה לגיליון עם 50,000 שורות, חיבור Google Sheets לשאר הכלים.
מקורות
שאלות נפוצות
מה בדיוק המכסה של Google Sheets API?
Google מתעדת 300 בקשות קריאה לדקה לפרויקט ו-60 בקשות קריאה לדקה למשתמש בכל פרויקט, ואותם ערכים בדיוק לכתיבה כמכסה נפרדת. אין מכסה יומית מצטברת כל עוד נשארים בתוך המכסה הדקתית.
כמה זמן צריך לחכות אחרי שגיאת מכסה?
לפי התיעוד של Google, אחרי דקה אפשר לבצע בקשות שוב, אך הדרך הנכונה היא נסיגה מעריכית עם רכיב אקראי ולא המתנה קבועה. המתנה קבועה גורמת לכל התהליכים שנכשלו לחזור יחד ולהיכשל שוב באותו רגע.
האם כתיבה של 1,000 שורות עולה יותר מכתיבה של שורה אחת?
לא במונחי מכסה. המכסה סופרת בקשות ולא שורות, ולכן בקשה אחת שכותבת 1,000 שורות שקולה לבקשה אחת שכותבת שורה אחת. זו הסיבה שאיגוד בקשות הוא התיקון היעיל ביותר לשגיאת מכסה.
האם חשבון שירות נפרד יפתור את הבעיה?
הוא יכול לעזור, כי מכסת ה-60 לדקה נספרת למשתמש בכל פרויקט, והפרדה בין אוטומציות למשתמשים שונים מונעת מהן להתחלק באותו תקציב. זה אינו פותר קוד שמבצע מאות בקשות מיותרות - זה רק מרחיב את התקרה.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.