ההורדה שלכם מהירה, אז למה כל לחיצה מרגישה איטית?

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

קובץ מהיר, לחיצה איטית: שני מספרים שונים

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

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

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

מדדו את התלונה, לא את החיבור

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

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

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

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

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

השהיה תחת עומס היא בעיית תור

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

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

הפקודה הראשונה דוגמת השהיה ברקע בזמן שהשנייה מרווה את הכיוון ההפוך. אם זמני ה-ping קופצים במהלך ההעברה ומתאוששים אחר כך, שחזרתם bufferbloat ולא גיליתם תקלת ניתוב. התיקון הוא בדרך כלל הגדרת ניהול תור, קצב רקע נמוך יותר או העברת ההעברה הגדולה מהנתיב האינטראקטיבי.

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

שנו דבר אחד והשוו דומה לדומה

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

רשמו מה מדדתם, מול איזה יעד, באיזו שעה ובאילו הגדרות. השוואה בלי ארבע העובדות האלה אינה ניתנת לחזרה, והאדם הבא יתחיל מאפס.

ואז התאימו את הכלי לטענה שבפנייה. "אינטרנט איטי" אינו מדידה; "הבית הראשון לקח 900 ms אל המארח הזה בזמן שהתפוקה הייתה טובה" היא מדידה, והיא מצביעה ישירות על השהיה ולא על קיבולת.