שני אורחים מקליטים ברכה בדיוק באותו רגע: יש הגבלה אמיתית על רינדורים במקביל?

התשובה הקצרה: כן, יש הגבלה אמיתית — אבל היא לא מגיעה מטרנזקציה או נעילה במסד הנתונים, כמו שאפשר לחשוב. כל תמלול ורינדור של רילס רץ בתוך תור פנימי שמוגבל בכוונה ל-2 עבודות ffmpeg במקביל, בלי קשר לכמה ברכות מגיעות באותו רגע ממש. ברכה שלישית ורביעית לא נדחות — הן פשוט מחכות בתור.

מה קורה בקוד כששני אורחים מקליטים ברכה בדיוק באותו רגע?

כל ברכה היא קובץ נפרד עם מזהה (`greetingId`) נפרד, ולכן אין כאן שאלה של שתי בקשות שקוראות וכותבות על אותה שורה במסד הנתונים — כמו שקורה כששני אורחים מתחרים על המקום האחרון בתקרת 10 האורחים. רינדור הרילס נקרא דרך פונקציה שמסמנת את הברכה כ'מבוקשת' ואז מכניסה אותה לעבודה ממוקדת-מפתח — מפתח נפרד לכל ברכה, לא שיתוף של אותה עבודה בין שני אורחים.

יש הגבלה אמיתית על כמה תמלולים ורינדורים רצים במקביל, או שזה גם נשען על תהליך יחיד?

יש הגבלה אמיתית, ולא רק מזל ארכיטקטורה כמו בתקרת 10 האורחים. פונקציית שליטה בקוד הרינדור סופרת כמה עבודות ffmpeg רצות כרגע, וכל עבודה שמעל ל-2 מחכה בתור FIFO פשוט עד שמתפנה מקום. התמלול עצמו נקרא בתוך אותה עבודה בדיוק — לפני שה-ffmpeg מתחיל לעבוד — כך שגם בקשת תמלול ל-RunPod נכנסת לאותו תור, לא רק עבודת העריכה.

ההבדל בין שני המקרים — הצטרפות אורח חדש לתקרה, ותמלול/רינדור ברכה — הוא ההבדל בין הגנה שקרתה בטעות להגנה שתוכננה בכוונה:

מה קורה בפועל אם ברכה שלישית, רביעית וחמישית מגיעות באותו רגע ממש?

• שתי הברכות הראשונות מתחילות רינדור (כולל תמלול) באופן מיידי
• ברכה שלישית ואילך נכנסות לתור ומחכות — לא נדחות ולא נכשלות
• ברגע שאחת מהעבודות הפעילות מסתיימת, הברכה הבאה בתור מתחילה אוטומטית
• אין איבוד תמונה או ברכה כתוצאה מהתור — רק דחייה בזמן ההמתנה, לעולם לא אובדן תוצר

שתי ברכות בו-זמנית זו הגבלה בכוונה, לא תאונה — שלוש ברכות בו-זמנית זה תור, לא כישלון.

המדידה האמיתית על התקרה הזו בוצעה על אירוע עם 350 אורחים ו-162 ברכות קוליות, בול על תקרת 2 העבודות המקבילות: 88 דקות בממוצע לריקון מלא של התור, ועד 178 דקות במקרה הקיצוני שבו כל אורח מדבר את מלוא 45 השניות המותרות. פירטנו את המדידה המלאה ואת מה שקורה למועד המחיקה (7/30 יום) בכמה זמן יש לצפות ולהוריד רילס אחרי שהוא נוצר.

אפשר שברכה אחת 'תידחק' בתור לפני ברכה של אורח אחר?

לא בין שני אורחים שונים. יש בקוד מנגנון שמאפשר לעבודת רינדור להתחדש באמצע — למשל אם האורח מעלה עוד תמונה לרול שלו בזמן שהרילס שלו עדיין ברינדור, העבודה הישנה מפסיקה ומפנה מקום לעבודה המחודשת עם התמונה הנוספת — אבל זה חל רק כשהעבודה הממתינה היא עבור אותה ברכה בדיוק. בין שני אורחים שונים אין עדיפות: תור ההמתנה הראשי הוא תור הגעה פשוט — מי שהגיע קודם מתחיל קודם.

כל המנגנון הזה — התור, ההגבלה, התמלול — קורה ברקע בלי שום אינטראקציה מהאורח או מהזוג. RegaRoll היא מצלמה חד־פעמית דיגיטלית לאירועים — ₪299 לאירוע, בלי אפליקציה — וקיר הברכות עובד בדיוק באותה דרך במסלול החינמי ובתשלום: עד 10 האורחים הראשונים (או ללא הגבלה בתשלום) מקבלים את אותו תור, אותה הגבלת 2 עבודות מקבילות ואותם רילסים קולנועיים. פירטנו את המנגנון המלא בקיר הברכות הדיגיטלי, ואת השאלה המקבילה בצד ההצטרפות לאירוע בשני אורחים מצטרפים בדיוק באותו רגע בתקרת 10 האורחים.

ומי שתוהה למה בכלל יש תור ברינדור ולא פשוט 'כל ברכה מתחילה מיד' — התשובה היא שרילס אחד הוא עבודה כבדה (תמלול, עיבוד וידאו ואודיו), ובערב חשיפה שבו עשרות ברכות מוכנות בבת אחת הפעלת כולן במקביל הייתה פשוט קורסת את השרת. זה אותו היגיון שעומד מאחורי כל סיפור הסושיאל של RegaRoll: כל אורח הוא צוות סושיאל בפני עצמו, אבל השרת מטפל בכולם אחד-אחד כדי שכל רילס יוצא איכותי. המנגנון המלא של הפקת הרילסים מכל ברכה מתואר בהמדריך לצלם סושיאל ורילסים מהאורחים.