הסברים · שניים
הורדה שעוברת בשלמות היא המקרה הקל, וכל לקוח מטפל בה כראוי. ההבדלים המעניינים מופיעים כשחלק מהפרסום חסר, וזה קורה הרבה יותר מכפי שהמקרה הנקי מרמז. הנה מה שקורה באמת, ולמה זה עולה כל כך הרבה זמן.
צורת הבעיה
פרסום ב-Usenet אינו קובץ אחד. הוא אלפי מאמרות קטנות, כל אחת מאוחסנת בנפרד בשרתים של כל ספק, וקובץ ה-NZB שאתה מוריד הוא רשימת שמותיהן. גרסה של 6.5 GB היא בערך 9,000 מהן.
מאמרות נעלמות מסיבות רגילות. הספקים שומרים אותן לתקופת שמירה קבועה ואז מוחקים אותן. חלק מהספקים מעולם לא קיבלו מאמרה מסוימת מלכתחילה, כי ההפצה בין שרתים אינה מושלמת. מדי פעם העלאה הייתה חלקית כשפורסמה, וחלק ממנה מעולם לא היה קיים בשום מקום. תהיה הסיבה אשר תהיה, התוצאה זהה: הלקוח שלך מבקש מאמרה, והתשובה היא סירוב במקום נתונים.
זה נפוץ מספיק כדי שהאנשים שמפרסמים ב-Usenet יערכו לכך. כמעט כל גרסה מגיעה בליווי נתוני זוגיות, בדרך כלל קובצי PAR2, כלומר מידע עודף נוסף שחושב מתוך המקור. אם חלק מהתוכן חסר, הזוגיות יכולה לשחזר אותו, בתנאי שיש לך מספיק ממנה. פרסום טיפוסי נושא כ-10% זוגיות, כך שפרסום יכול לאבד נתח לא קטן מעצמו ועדיין להיות בר-שחזור לחלוטין.
לכן פרסום פגום אינו בדרך כלל הורדה שבורה. הוא הורדה שדורשת קצת חשבון לפני שהיא שלמה. השאלה היחידה היא כמה זמן לוקח ללקוח להבין זאת, ושם הם נבדלים בפי שניים או יותר.
החלק היקר
כששרת אינו מחזיק מאמרה הוא מחזיר סירוב, והלקוח מנסה אז את השרת הבא ברשימה שלך. זה הדבר הנכון לעשות, כי לספק השני לעיתים קרובות מאוד יש אותה. המחיר מופיע כשלאף אחד אין אותה.
במקרה כזה הלקוח עובר על כל רשימת הספקים שלך, שרת אחר שרת, ונדחה על ידי כל אחד מהם לפני שהוא יכול להסיק שהמאמרה אכן נעלמה. המעבר הוא טורי, והסירובים איטיים יותר משמניחים. מדדנו אותם ישירות, על קו במנוחה, בלי שום תוכן בתנועה:
| ספק | זמן מענה לבקשה רגילה | זמן סירוב למאמרה חסרה |
|---|---|---|
| ספק A | 77.5 ms | 78.8 ms |
| ספק B | 10.5 ms | 454 ms |
| ספק C | 10.8 ms | 871 ms |
| ספק D | 9.9 ms | 1,227 ms |
| ספק E | 10.6 ms | 2,239 ms |
שני דברים בולטים. ראשית, הפיזור עצום: סירוב עולה איפשהו בין 79 ms ל-2.2 שניות תלוי איזה ספק עונה, הפרש של כמעט פי שלושים. שנית, ספק אחד מסרב בערך בזמן שלוקח לשאול, בעוד אחר לוקח יותר מפי מאתיים מזמן התגובה הרגיל שלו כדי לומר לא. זו אינה השהיית רשת, זו עבודה שמתרחשת בצד שלהם, ולשאול בפחות הלוך ושוב כמעט אינו עוזר.
חברו את הכול: מעבר מלא על חמישה ספקים, עבור מאמרה יחידה שכבר אינה קיימת, עולה בערך 5 שניות. עכשיו קחו בחשבון שלפרסום פגום יש מאמרות רבות כאלה, ושלקוח שמטפל בהן ברצף משלם את המחיר הזה שוב ושוב בזמן שהחיבור שלכם יושב בטל. ההורדה אינה איטית משום שהנתונים מגיעים לאט. הם חדלו להגיע כליל, והלקוח ממתין שיאמרו לו את מה שכבר יש בידיו די מידע כדי להסיק.
הפתרון
התובנה אינה להאיץ את הסירובים, כי איננו שולטים בספקים. היא להבחין מתי התשובה כבר אינה משנה.
בכל רגע במהלך הורדה הלקוח יודע שני דברים: כמה חלקים עדיין חסרים, וכמה נתוני זוגיות כבר יש בידיו. אם הזוגיות שבידיו מספיקה כדי לבנות מחדש את כל מה שנותר, אז התשובה לשאלה אם למישהו יש את המאמרה הזאת כבר אינה יכולה לשנות את התוצאה. בין אם זה כן איטי ובין אם לא איטי, הקובץ ייבנה מחדש כך או כך. המשך המעבר אינו קונה דבר מלבד עיכוב.
לכן הגרסה הנוכחית מפסיקה לשאול בנקודה הזאת ועוברת ישר לתיקון. השחזור עצמו מהיר ותמיד היה: כ-2.3 שניות על פרסום של 6.5 GB, והנתון הזה זהה בכל גרסה שמדדנו. הזמן שנחסך הוא כולו ההמתנה שכבר אינה מתרחשת.
| פרסום של 6.5 GB, 60 מאמרות חסרות | זמן עד קובץ מאומת |
|---|---|
| להמתין לסירוב של כל ספק | 23 s |
| לעצור ברגע שהזוגיות מכסה את הפער | 13 s |
| מתוכן, חשבון התיקון עצמו | 2.3 s |
אותו שינוי אינו עושה דבר בפרסום שאינו פגום, וזו ההוכחה הברורה ביותר שהוא עושה את מה שאנחנו חושבים: בלי מאמרות חסרות אין מעבר לקצר, ושתי הגרסאות מסיימות משימה נקייה של 6.5 GB ב-7 שניות זהות.
זו עסקה, לא רווח חינם. תיקון מוקדם פירושו להחזיק את נתוני הזוגיות בזיכרון במקום להשליך אותם ולהביא עוד אחר כך, כך ששיא הזיכרון (RSS) בפרסום פגום קשות עולה מכ-0.8 GB לכ-1.3 GB, ואנחנו מושכים בערך 400 MB יותר מהספקים. בפרסום שאינו פגום הזיכרון אינו משתנה ועומד על 0.24 GB. אנחנו סבורים שזו העסקה הנכונה לרוב האנשים, שכן הזיכרון מוצא רק במקרה שבו הוא קונה לכם עשר שניות, אבל זה מחיר אמיתי ויש לכך הגדרה.
שמות הספקים נמנעים בטבלת הסירובים במכוון. הנתונים הם תכונה של מדידה אחת בערב אחד ממקום אחד, וספק שמאנדקס אחרת, או שנקלענו אליו בערב גרוע, אינו צריך להיות מתויג כאיטי על סמך סבב יחיד. מה שחשוב לטיעון הוא הצורה: הסירובים משתנים עד מאוד, והסכום גדול מספיק כדי לשלוט בהורדה פגומה. הנתונים לכל ספק ופלט הבדיקה הגולמי נמצאים ברישום הפנימי שלנו, והמספרים מקצה לקצה שהם מסבירים נמצאים בעמוד בדיקות הביצועים.