חשב את קצב ההעברה השימושי שחלון המסירה שלך דורש, ואז מדוד את הנתיב המלא. קיבולת פורט, זמן הלוך-חזור, התנהגות TCP, אחסון ועיבוד יישום משפיעים כולם על התוצאה. השתמש בבדיקות מבוקרות עם מקביליות מציאותית וחזור עליהן דרך היישום בפועל לפני בחירת שכבת רשת.
הפוך את חלון המסירה לקצב
התחל בכמות נתוני יישום שימושיים ובזמן הזמין למסור אותם. בשימוש ביחידות עשרוניות, העברת 2 TB בשעתיים דורשת בערך 278 MB לשנייה של מטען, או 2.22 Gbps, לפני התחשבות בתקורת פרוטוקול ובהפרעות. החשבון הוא דוגמת תכנון, לא תוצאת שירות נמדדת.
כלול את ההעברות החופפות. ייצוא מתוזמן, הורדות לקוחות והעלאות גיבוי יכולים לחלוק משאבים גם אם הסכומים החודשיים שלהם נראים צנועים. כתוב מודל של תקופת עומס, לא רק ממוצע חודשי. ציין איזה כיוון חשוב והאם העברה שנכשלה חייבת להתחיל מחדש או יכולה להמשיך; התנהגות זו משפיעה על כמות העבודה שהמערכת מבצעת.
הפרד קיבולת פורט מתפוקה שימושית
פורט שרת מתאר קיבולת קישור. תפוקה שימושית מתארת את הנתונים שהיישום שלך מספק במהלך מרווח נצפה. הצפנה, מסגור פרוטוקול, שידור חוזר, פעילות אחסון ועבודה בצד המקבל תופסים חלקים מאותו נתיב. לכן פורט 10 Gbps רשום אינו מבסס שהיישום יספק ברציפות 10 Gbps של מטען.
IETF RFC 6349 מבחין במפורש בין בדיקת נתיב הרשת לבין בחינת ביצועי TCP. השתמש בהפרדה זו באבחון שלך. תחילה אשר שנקודות הקצה והנתיב מתאימים, ואז חקור את התעבורה והיישום. הגדלת הפורט הנרכש אינה מתקנת מקבל שכותב נתונים לאט או יישום שמעבד בקשה אחת בכל פעם.
הבן מדוע זמן הלוך-חזור חשוב
TCP שולט בכמה נתונים יכולים להישאר בדרך לפני שאישורים חוזרים. מכפלת רוחב פס-השהיה נותנת קנה מידה שימושי לכך: קצב כפול זמן הלוך-חזור. נתיב היפותטי של 10 Gbps עם 40 אלפיות שנייה של השהיית הלוך-חזור מייצג כ-50 MB בדרך. חישוב זה מסביר מדוע השהיה והתנהגות תעבורה שייכות לתכנון במהירות גבוהה.
התוצאה אינה הוראה להחיל הגדרת socket שרירותית. מערכות הפעלה, בקרת עומס, חלונות מנוהלים והנתיב בפועל משפיעים על ההתנהגות. אמת תיעוד תוכנה עדכני ובדוק מדידות לפני כוונון. חיבורים מקבילים רבים יותר עשויים לשפר תפוקה מצטברת בנסיבות מסוימות, אך הם יכולים גם להסתיר את ההתנהגות של ההעברה הבודדת שהיישום שלך תלוי בה.
בנה מטריצת בדיקה מבוקרת
השתמש רק בנקודות קצה שבבעלותך או שאתה מורשה לבדוק. הסכם את חלון הבדיקה והקצב כך שהתרגיל לא ישבש שירות רגיל. כלים כגון iperf3 מספקים כיוון, משך וזרמים מקבילים הניתנים להגדרה; התיעוד הרשמי מגדיר אמצעי בקרה אלה. תעד את הגרסה, נקודות הקצה, הקשר הנתיב וההגדרות עם התוצאה כך שמפעיל אחר יוכל לשחזר אותה.
התחל בזרימה אחת, ואז הוסף מקביליות מייצגת. הרץ את שני הכיוונים אם היישום תלוי בשניהם. מטריצה להמחשה זו מפרידה בין שאלות שתוצאת כותרת אחת תערבב יחד. שמור תוצאות גולמיות באופן פרטי כאשר הן חושפות כתובות פנימיות או פרטים תפעוליים, ופרסם רק את המדידות הנדרשות להחלטה.
| בדיקה | מה היא חוקרת | מה היא אינה מוכיחה |
|---|---|---|
| זרימת תעבורה אחת | התנהגות נתיב בזרימה בודדת | מסירת יישום מצטברת |
| מספר זרמים מקבילים | מקביליות ומגבלות מצטברות | קצב ההעברה של לקוח אחד |
| העברת יישום | אחסון, פרוטוקול ותוכנה יחד | ביצועים לכל מערך נתונים |
| חזרה בתקופת עומס | שונות תחת פעילות מציאותית | הבטחת תפוקה קבועה |
בחן את נקודות הקצה במהלך הבדיקה
תעד שימוש ב-CPU, לחץ זיכרון, פעילות אחסון ומוני שגיאות בשני הקצוות. תוצאת העברה ללא תצפיות בנקודות הקצה עשויה להשאיר את המגבלה האמיתית בלתי נראית. בדוק אם תהליך אחד או CPU רווי בעוד אחרים בטלים. הימנע משינוי מספר הגדרות בבת אחת, כי זה מקשה לזהות איזו התאמה עזרה.
הפרד בדיקה מגובה בזיכרון מבדיקה שקוראת וכותבת נתונים אמיתיים. הראשונה יכולה לעזור לחקור את נתיב התעבורה; השנייה משקפת יותר מעבודת היישום. אם התוצאות שונות בחדות, בדוק אחסון ועיבוד במקום להתייחס לנתון המגובה בזיכרון כהבטחת מסירה. שתי המדידות יכולות להיות שימושיות כאשר היקפן ברור.
בדוק את היישום עם עומסים מציאותיים
לייצוא HTTP, לזרם שכפול מוצפן ולסשן העברת קבצים יש דפוסי עיבוד שונים. השתמש בגדלי קבצים, קצבי בקשות והגדרות הצפנה מייצגים. כלול את הזמן המושקע בהכנת נתונים לפני שליחת הבית הראשון כאשר המשתמש ממתין לשלב זה. הבחן בין השהיית התגובה הראשונה לזמן ההשלמה במקום לדווח על אחד כעל השני.
חזור על הבדיקה במרווחים מספיקים כדי לראות שונות, ושמור קו בסיס לפני שינוי התצורה. עבור ייצוא 2 TB ההיפותטי, השווה את זמן ההשלמה בפועל לחלון של שעתיים והשאר מרווח להפרעות. בחר שיפור כנגד הצוואר האמיתי שנצפה במקום להכפיל את קיבולת הפורט ללא סיבה.
השתמש בתוצאה כדי לבחור תצורה
הפלט השימושי הוא דרישת משאבים עם ראיות: קצב מטען נמדד, זמן השלמה מקובל, מקביליות צפויה ושלב מגביל ידוע. השווה גרסאות רשת SwissOctet כנגד דרישה זו, כולל מכסת תעבורה ומפרטי CPU ואחסון. המיקום לבדו אינו קובע את הנתיב או השהיה מקצה לקצה לכל מקבל.
שמור את נוהל הבדיקה לאחר הפריסה. השתמש בו מחדש כאשר מערכי נתונים גדלים, תוכנה משתנה או משתמשים עוברים לרשתות אחרות. קו בסיס ניתן לחזרה מקל על אבחון תקרית ביצועים ומספק סיבה מבוססת יותר לשינוי תצורה מאשר בדיקת מהירות מבודדת או מקסימום מפורסם.
רשימת הבדיקה המעשית שלך.
- חשב קצב מטען מנפח ומועד אחרון.
- מדל העברות חופפות וכיוון.
- הסכם נקודות קצה ומגבלות בדיקה מאושרות.
- השווה זרימה אחת, מקביליות ובדיקות יישום.
- צפה בשתי נקודות הקצה במהלך הבדיקה.
- שמור קו בסיס ניתן לחזרה ומרווח שימושי.
הפרטים שחשובים.
האם חלון TCP גדול יותר תמיד מתקן העברה איטית?+
לא. אבחן תחילה את הנתיב ונקודות הקצה. אחסון, CPU, אובדן והתנהגות יישום יכולים לשלוט, וכוונון תעבורה חייב להתאים למערכת בפועל.
מדוע לבדוק זרימה אחת ומספר זרמים?+
הם עונים על שאלות שונות. קיבולת מצטברת יכולה להיות גבוהה מקצב העברה אחת; המקביליות של היישום קובעת איזו תוצאה חשובה.
האם אני יכול להריץ בדיקת קיבולת כנגד כל שרת ציבורי?+
השתמש בנקודות קצה שאתה שולט בהן או שיש לך רשות לבדוק. הסכם משך, קצב ותזמון כך שהמדידה לא תשבש שירותים לא קשורים.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- IETF RFC 6349: מסגרת לבדיקת תפוקת TCP datatracker.ietf.org
- ESnet: Invoking iperf3 software.es.net
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.