מפו לפני העברה
איסוף עשוי להישאר בדפדפן, להמשיך לשרת ואז ליעדים. Consent Mode מעביר מצבים ומתאים התנהגות; אינו מספק לבדו ממשק בחירה או אימות משפטי.
| שלב | בקרה | ראיה מבוקשת |
|---|---|---|
| דפדפן או יישום | שדות ובחירות שנאספו. | בקשות שנשלחו בפועל. |
| שרת איסוף | אימות, סינון וגישה. | אירועים שאושרו או נדחו. |
| יעד | מידע שהועבר בפועל. | תוכן וכללי הסכמה. |
| תפעול | שמירה, הרשאות ושחזור. | בדיקות מחיקה, כשל וגישה. |
בדקו מה נשלח בפועל
- הגדירו שדות ונמענים מותרים לכל מטרה. בדקו כתובות, פרמטרים, מזהים ויומנים לפני שליחה; אל תניחו סינון כברירת מחדל.
- בדקו קבלה, סירוב ושינוי בחירה לאורך כל השרשרת. ודאו התנהגות בדפדפן, במכל השרת ובכל יעד.
- התאימו אירועים שהתקבלו, אושרו והועברו. בדקו כפילויות, אובדן, כשל ושחזור, ואז עלות ועומס שרת.
העריכו יתרונות וחובות בנפרד
בדקו ביצועים במסלולים דומים; איסוף ראשוני בדפדפן עשוי להישאר נחוץ. דומיין צד ראשון אינו פטור. בצרפת פטור לכלי מדידת קהל מסוימים הוא מותנה ואינו מכסה אוטומטית תיוג פרסומי.
מקורות ראשוניים
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
תיוג בצד השרת עדיין זקוק לבדיקת זרימה.
העברת תגים לשרת אינה הופכת אוטומטית את המדידה לתואמת או מינימלית. בדיקת בקשות שנפלטו, נמענים, מזהים והתנהגות לאחר סירוב בפריסה בפועל.
- מיפוי דפדפן, שרת איסוף, ספקים ושדות מועברים.
- בדיקה לפני בחירה, לאחר סירוב ולאחר ביטול הסכמה.
- השווה הגדרות עם מטרות מוצהרות ותנאי CNIL רלוונטיים.
מקור ראשוני: CNIL — Outils de mesure d’audience et traceurs. שיטה קשורה: קריאת המדריך המעשי.
מכסות ומגבלות API
המגבלות משפיעות על קיבולת, ניסיונות וחלוקה בין לקוחות.
- תעדו אם המכסה חלה על חשבון, מפתח או משאב וכמה פעולות מקבילות הלקוח מאפשר. תור ללא גבול יכול להעמיס על השירות גם בקצב ממוצע נמוך.
- בתשובת 429 פרשו Retry-After אם קיים והמתינו לפני בקשה נוספת. שלבו המתנה גדלה ופיזור בין לקוחות עם מספר ניסיונות מרבי ומועד סיום כולל.
- כשחסרה תשובת כתיבה, בדקו מצב לפני חזרה. בבדיקה מדומה שלבו מכסות, תשובות מאוחרות וביטול; התור צריך להסתיים ללא השפעות כפולות.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}החלטה צפויה
המתינו 30 שניות, פזרו ניסיונות של 20 עובדים והגבילו את מספר החזרות.
עשרים לקוחות: לפזר ולספור ניסיונות
דוגמה בדויה: 20 עובדים מקבלים בזמן +0 s תגובת 429 עם Retry-After: 30. הזמנים מציגים פיזור אפשרי ואינם מבטיחים קיבולת שרת. לכל עובד 3 ניסיונות חוזרים בנוסף לבקשה הראשונה.
| מדיניות | חישוב או תזמון | השפעה |
|---|---|---|
| ניסיון חוזר בו־זמני | 20 × 1 = 20 @ +30 s | המתנה של 30 שניות מכבדת את ההשהיה, אך כל 20 הבקשות חוזרות יחד והעומס עלול לחזור. |
| ניסיון חוזר מפוזר | 4 × 5 = 20 @ +30…+34 s | ארבע בקשות בשנייה במשך חמש שניות מפזרות 20 ניסיונות בלי להפחית את מספרם. לוח הזמנים להמחשה אינו מחליף מדיניות השהיה גדלה עם שונות אקראית. |
| מועד סיום אחרי 25 שניות | 25 s < 30 s → 0 | אם הזמן שנותר קצר מ־30 השניות הנדרשות, עצרו או דחו בהתאם לחוזה. אל תקצרו את ההמתנה כדי לעמוד במועד. |
| תקציב מרבי | 20 × (1 + 3) = 80 | ניצול כל הניסיונות נותן 20 בקשות ראשונות ועוד 60 חזרות: 80 בקשות. התקרה אינה מבטיחה הצלחה או חזרה בטוחה. |
נוהל בדיקה
- תעדו תחום מכסה ותקציב ניסיונות.
- מצו מכסה רק בבדיקה מורשית.
- שמרו 429, Retry-After ורצף מוגבל. הבחינו בין הגבלה טכנית לתוצאה עסקית: מכסה שנוצלה אינה אמורה להפוך לתשובה המדווחת על מלאי אפס.
- דמו בלי עומס חיצוני ארבע שכבות עם שלוש קריאות כוללות לכל אחת וספרו ניסיונות.
- העבירו משימה בדיונית בתור מעבר למועד ובדקו שלא מתחילה פעולה חדשה.
- השיבו עבודה מורשית בהדרגה אחרי תקלה מדומה ושמרו קריאות, מועדים ותוצאות ייחודיות.
האם 429 מוכיח שכתיבה קודמת לא בוצעה?
לא. הפעולה ללא תשובה דורשת התאמה נפרדת; תשובה לניסיון אחר אינה מוכיחה את מצבה.
מקור ראשוני: IETF — RFC 6585, HTTP 429. שיטה קשורה: קריאת המדריך המעשי.
גבולות מדידת פחמן
השוואה דורשת גבולות ויחידה תפקודית משותפים.
- רשמו רכיבים, אזור, תקופה ויחידה תפקודית, למשל פעולה שהושלמה. השוו תרחישים המספקים אותה רמת שירות.
- רשמו אנרגיה, מקדם פליטות וחלק חומרה שהוקצה. הפרידו מדידה ואומדן; תעדו החרגות בלי להניח השפעה אפסית.
- דוגמה בדיונית: (12 + 3) gCO2e / 5 פעולות = 3 gCO2e לפעולה. שנו הנחות לא ודאיות והשוו גם פליטות כוללות.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}החלטה צפויה
(2 × 100 + 50)/100 = 2.5 gCO2e למשימה, רק בגבולות שהוצהרו.
נוהל בדיקה
- הגדירו גבולות, יחידה תפקודית ומקדמים.
- הפרידו אנרגיה, פליטות מגולמות ותוצאות.
- שמרו מקור וחישוב בלי קיזוז מובלע.
מקור ראשוני: Green Software Foundation — Software Carbon Intensity. שיטה קשורה: קריאת המדריך המעשי.
API: למנוע ניסיונות מוכפלים בין שכבות
יישום, SDK, פרוקסי ושירות יכולים לחזור על אותה קריאה. ארבע שכבות בדיוניות עם שלושה ניסיונות כוללים לכל אחת יוצרות עד 81 קריאות לתלות שנכשלה. הוסיפו תקציב משותף ומועד שימושי לבקרת מכסות.
- מפו ניסיונות אוטומטיים ביישום, SDK, פרוקסי ותלות. בחרו שכבה אחראית ובטלו או תאמו ניסיונות נוספים לפי חוזה. ספרו גם את הניסיון הראשון בתקציב. שמרו מזהה פעולה ובדקו השפעות לא ודאיות לפני חזרה לא אידמפוטנטית.
- הגדירו מועד כולל להמתנה, חיבור ועיבוד לפי מגבלות הלקוח. דחו משימות שפג זמנן לפני כניסה לתור. ביטול מקומי אינו מוכיח עצירת שרת: התאימו מצב. השיבו תעבורה בהדרגה בלי להפעיל כל התורים יחד.
האם שלושה ניסיונות לשכבה הם שלושה בסך הכול?
לא. ארבע שכבות בדיוניות עם שלושה ניסיונות כוללים נותנות עד 3⁴ = 81 קריאות אחרונות.
האם פקיעת משימה מבטלת השפעה מרוחקת?
לא בהכרח. היא מונעת עבודה חדשה לא נחוצה; פעולה שהחלה דורשת בדיקת מצב ופיצוי אם אפשר.
מקור ראשוני: AWS — Timeouts, retries, and backoff with jitter. שיטה קשורה: קריאת המדריך המעשי.