התשובה הקצרה: לא, כל אירוע לא מקבל תור נפרד. ההגבלה של 2 עבודות ffmpeg במקביל שסופרת כל רינדור רילס (`lib/blessing-video.ts`) היא משתנה גלובלי אחד לכל תהליך השרת, ולא ממופתחת לפי `eventId`. ביום שיא שבו כמה חתונות נחשפות באותו בוקר, כולן חולקות בדיוק את אותם 2 סלוטים — התוצאה היא זמן המתנה ארוך יותר לכל האירועים, לא כישלון רינדור לאף אחד מהם.
למה זה בכלל רלוונטי — אירועים באמת נחשפים באותו בוקר?
ברירת המחדל של RegaRoll היא חשיפה 'בבוקר שאחרי', ולא ברגע שהאירוע נגמר — ומאחר שרוב החתונות בישראל מתקיימות בימי חמישי בערב, ברירת המחדל הזו מרכזת באופן טבעי חלק ניכר מהחשיפות לאותו חלון של בוקר יום שישי. אפשר לבחור מועד חשיפה אחר לכל אירוע, אבל ברירת המחדל עצמה כבר יוצרת נטייה לצבירה — בלי שום תיאום מכוון בין הזוגות.
מה קורה בקוד בפועל כששני אירועים שונים מבקשים רינדור באותו הרגע?
בתוך `lib/blessing-video.ts` יש פונקציית `withSlot` שמגבילה כל רינדור רילס (כולל התמלול שקורא לו) ל-2 עבודות ffmpeg במקביל: `let active = 0` ותור המתנה `waiters` מוגדרים ברמת המודול, פעם אחת בעלייה של השרת — לא לכל אירוע ולא לכל קריאה. שום פרמטר `eventId` לא נכנס לפונקציה הזו בכלל. ברכה של אירוע א' ובקשת רינדור של אירוע ב' נכנסות לאותו `active` ולאותו `waiters` בדיוק כמו שתי ברכות של אותו אירוע — השרת לא מבדיל בין המקרים.
זה ממשיך בדיוק מאותה מסגרת שבדקנו במאמר על ההגבלה על רינדורים במקביל כששני אורחים מהאירוע שלכם מקליטים ברכה בדיוק באותו רגע: שם הראינו שהתקרה היא 2 עבודות במכוון, לא תאונה. ההבדל היחיד כאן הוא מי עומד בתור — לא רק אורחי האירוע שלכם, אלא כל לקוח שמריץ רינדור על אותו שרת באותה דקה.
אירוע אחד עם הרבה ברכות, מול כמה אירועים קטנים בבוקר אחד — מה שונה בפועל?
| מה בודקים | אירוע אחד, הרבה ברכות | כמה אירועים, אותו בוקר |
|---|---|---|
| מי מתחרה על שני הסלוטים | אורחי האירוע שלכם בלבד | כל האירועים שנחשפים באותה דקה |
| סדר התור | FIFO לפי מי שהקליט קודם | FIFO לפי מי שבקשת הרינדור הגיעה קודם — בלי קשר לאירוע |
| יש עדיפות למסלול בתשלום? | לא — אין שום בדיקת תוכנית בקוד הזה | לא — אותה תקרה בדיוק, חינם ובתשלום |
| מה שמשתנה בפועל | זמן המתנה כולל לאירוע שלכם | זמן המתנה כולל, מחולק בין יותר אירועים |
| מה לא קורה בשום מקרה | אובדן ברכה או כישלון רינדור | אובדן ברכה או כישלון רינדור |
האם אירוע שלי יכול 'להיתקע' בתור בגלל אירוע של זוג אחר?
במובן הטכני — כן, זה אפשרי: אם עוד אירוע מגיש בקשות רינדור בדיוק באותם רגעים, הברכות שלכם עומדות בתור FIFO יחד עם שלו, בלי יחס מיוחד למי מהם 'הגיע ראשון' בקנה מידה גדול יותר. אבל זה לא שקול לחסימה: התור מתרוקן ברצף, סלוט מתפנה בכל סיום עבודה, וברכה שממתינה היום לא נדחית לשבוע הבא — היא פשוט מחכה דקות ארוכות יותר לפני שהרינדור שלה מתחיל.
- אירוע יחיד עם 350 אורחים ו-162 ברכות נמדד בפועל על 88 דקות בממוצע לריקון מלא של התור, ועד 178 דקות בקיצון
- שני אירועים באותו גודל שנחשפים בדיוק באותה דקה חולקים את אותם 2 סלוטים — כל אחד מהם היה מחכה בממוצע כפול, בערך 176 דקות, לא 88
- במציאות אירועים לא נחשפים בדיוק בשנייה אחת — פיזור של כמה דקות בין חשיפות מקטין את ההתנגשות בפועל הרבה מעבר לתרחיש המעבדה הזה
- ברכה שמחכה בתור עדיין מוצגת בדשבורד כ'בהכנה', לא כשגיאה — פירטנו את מה שהזוג רואה בפועל במאמר מה קורה בדשבורד כשרילס עדיין בתור
תקרה גלובלית לא ייחודית לרגע החשיפה שלכם — היא בדיוק הסיבה שהיא גלובלית: שרת אחד מטפל בכל הלקוחות שלו באותו רגע, לא רק בלקוח אחד.
RegaRoll היא מצלמה חד־פעמית דיגיטלית לאירועים — ₪299 לאירוע, בלי אפליקציה — וקיר הברכות עובד באותו תור בדיוק במסלול החינמי ובתשלום: אין תוכנית שמקבלת סלוט מהיר יותר. מי שרוצה את המנגנון המלא של קיר הברכות לפני שבודקים את מקרי הקצה שלו, יכול לקרוא בקיר הברכות הדיגיטלי, ואת המדידה המלאה של זמני הרינדור על אירוע בודד — בכמה זמן יש לצפות ולהוריד רילס אחרי שהוא נוצר.